
- •Понятие программного обеспечения, классификация программного обеспечения
- •Жизненный цикл по и его стандартизация, процессы жц по, группы процессов жц по
- •Процесс разработки по: основные действия и их содержание
- •Анализ требований к по
- •Проектирование архитектуры по
- •Кодирование и тестирование по
- •Сертификация процессов разработки по, модель cmm
- •Стратегии жизненного цикла по: понятие, виды и их сравнительная характеристика
- •Каскадная модель жизненного цикла по: описание, преимущества и недостатки, критерии применения
- •Процесс макетирования по: его содержание, преимущества и недостатки, критерии применения
- •Недостатки:
- •Инкрементная модель жизненного цикла по: описание, преимущества и недостатки, критерии применения
- •Спиральная модель жизненного цикла по: описание, преимущества и недостатки, критерии применения
- •Rad модель жизненного цикла по: описание, преимущества и недостатки, критерии применения
- •Структурный подход к разработке по: основные принципы и методы
- •Методология idef0: назначение, icom-модель, правила построения диаграммы
- •Методология idef0: назначение, правила построения иерархии диаграмм, критерии завершения и стратегии декомпозиции
- •Методология dfd: назначение, элементы диаграммы и их назначение, правила построения диаграммы
- •Методология dfd: правила построения иерархии диаграмм, спецификации и их содержание
- •Модификация dfd п. Варда и с. Меллора
- •Модификация dfd д. Хетли и и. Пирбхаи
- •Методология idef1x: назначение, сущности и связи: понятие и их обозначения
- •Методология idef1x: назначение, виды и уровни моделей, порядок построения
- •21 Методология idef3: назначение, единица работы, связи и их виды, соединения и их виды
- •Типы связей idef3
- •Типы соединений
- •Виды указателей idef3
- •22 Основные этапы проектирования программных систем и их содержание
- •Информационные потоки процесса синтеза программной системы
- •23 Структурирование программной системы: цели и модели
- •Широковещательная модель
- •Модель, управляемая прерываниями
- •Модульность программной системы: понятие и свойства модуля, цели модульной декомпозиции
- •Затраты на модульность
- •26 Связность модуля: понятие, виды связности и их описание
- •Характеристика связностей модуля
- •27 Сцепление модулей: понятие, виды сцепления и их описание
- •28 Сложность программной системы, основные подходы к ее оценке
- •29 Структурные карты Констайнтайна
- •Элементы структурных карт: а) – модуль; б) – вызов модуля; в) – связь по данным; г) – связь по управлению
- •Типы вызовов модулей
- •30 Метод анализа и проектирования Джексона
- •Соединения между физическими процессами и их моделями
- •31.Объектно-ориентированный подход к разработке по: основные понятия и принципы
- •32.Язык uml: причины появления и история развития языка, структура языка
- •33.Канонические диаграммы языка uml: их виды и типы, рекомендации построения
- •34.Механизмы расширения uml: виды, примеры использования
- •35.Диаграмма вариантов использования: назначение, принципы построения
- •36.Диаграмма классов: назначение, классы, обозначение классов, их атрибутов и операций
- •37.Диаграмма классов: назначение, отношения между классами и их применение
- •38.Диаграмма композитной структуры: композитные классы и их части, принципы построения
- •39.Диаграмма композитной структуры: кооперации и их использование
- •40. Диаграмма пакетов: назначение, пакеты и отношения между ними
- •41.Диаграмма объектов, назначение, объекты и отношения между ними
- •42.Диаграмма последовательности: назначение, линии жизни, прием и передача сообщений между линиями жизни
- •43.Диаграмма последовательности: назначение, комбинированные фрагменты, их виды и использование
- •44.Диаграмма деятельности: назначение, понятие, семантика и обозначение деятельности, действия и дуг
- •45.Диаграмма деятельности: узлы управления, их виды и применение
- •46. Дополнительные элементы диаграммы деятельности: действия приема и передачи сигналов, центральный буфер и хранилище данных
- •Дополнительные элементы диаграммы деятельности: разбиения, регион прерываемой деятельности, обработчик исключений
- •Диаграмма коммуникации: назначение, принципы построения
- •Диаграмма обзора взаимодействия: назначение, принципы построения
- •Когда применяются диаграммы обзора взаимодействия
- •50. Временные диаграммы: назначение, принципы построения
- •51. Диаграмма конечного автомата: назначение, простое и композитное состояния
- •52. Диаграмма конечного автомата: простые и составные переходы, правила срабатывания переходов
- •6.3. Переход
- •6.6. Сложные переходы
- •53. Диаграмма конечного автомата: псевдосостояния, их виды и применение
- •54. Протокольные конечный автомат: назначение, элементы и принципы построения
- •55. Диаграмма компонентов: назначение, компоненты, интерфейсы и порты, соединения и их виды
- •56. Диаграмма развертывания: назначение, узлы, артефакты, соединения и их виды
- •57. Объектно-ориентированные метрики: назначение, связь с принципами ооп
- •58. Объектно-ориентированные метрики: связность по данным
- •59. Объектно-ориентированные метрики: связность по методам
- •60. Объектно-ориентированные метрики: сцепление объектов и локальность данных
- •61. Объектно-ориентированные метрики: набор метрик Чидамбера и Кемерера
- •62. Объектно-ориентированные метрики: набор метрик Лоренца и Кидда
- •63. Объектно-ориентированные метрики: набор метрик Фернандо Аббреу
33.Канонические диаграммы языка uml: их виды и типы, рекомендации построения
В языке UML все представления о модели сложной системы фиксируются виде специальных графических конструкций – диаграмм. В терминах языка UML определены следующие типы диаграмм:
диаграммы структуры;
диаграммы поведения;
диаграммы взаимодействия (являются подмножеством диаграмм поведения).
Диаграммы структуры (или структурные диаграммы) предназначены для представления статической структуры элементов в модели системы. На них изображаются те элементы модели и отношения, которые не зависят от времени.
Диаграммы поведения изображают динамическое поведение объектов в системе, включая кооперации, деятельности, вызовы методов объектов и изменение их состояний.
В каждой из перечисленных групп диаграмм содержится набор канонических диаграмм.
К структурным диаграммам относят:
диаграмма классов;
диаграмма композитной структуры;
диаграмма пакетов;
диаграмма объектов
диаграмма компонентов;
диаграмма развертывания
К диаграммам поведения относят:
диаграмма вариантов использования;
диаграмма деятельности;
диаграмма конечного автомата.
К диаграммам взаимодействия относят:
диаграмма последовательности;
диаграмма коммуникации;
диаграмма обзора взаимодействия;
временная диаграмма.
В общем случае при построении диаграмм на языке UML необходимо придерживаться следующих основных рекомендаций и требований:
Каждая диаграмма должна служить законченным представлением соответствующего фрагмента моделируемой предметной области.
Все сущности на диаграмме модели должны быть одного концептуального уровня.
Вся информация о сущностях должна быть явно представлена на диаграммах.
Диаграммы не должны содержать противоречивой информации.
Диаграммы не следует перегружать текстовой информацией.
Каждая диаграмма должна быть самодостаточной для правильной интерпретации всех ее элементов и понимания семантики всех используемых графических символов.
Количество диаграмм различных типов для модели конкретного приложения не является строго фиксированным.
Любая из моделей системы должна содержать только те элементы, которые определены в нотации языка UML.
Каждая диаграмма в нотации языка UML имеет область содержания для изображения графических узлов и путей между ними, которые представляют собой собственно элементы модели в нотации UML.
34.Механизмы расширения uml: виды, примеры использования
Хотя язык UML обладает довольно большим набором понятий и графических символов для моделирования программных систем, на практике может потребоваться включение в модель дополнительных свойств или элементов, которые в явном виде в языке UML не определены. Для реализации этой потребности в язык UML включены механизмы расширения, которые в общем случае предназначены для выполнения следующих задач:
уточнения или спецификации общих элементов метамодели;
определения таких расширений языка UML, которые зависят от специфики моделируемого процесса или от языка реализации программного кода;
присоединения произвольной семантической или несемантической информации к элементам модели.
В языке UML реализованы три механизма расширения: стереотип, ограничение и помеченное значение.
Стереотип – это элемент модели, который расширяет семантику базового элемента метамодели языка UML. В моделях языка UML стереотипы могут быть представлены следующими способами:
в форме текста, заключенного в двойные угловые кавычки (знаки «меньше» и «больше») и размещенного выше или перед именем элемента модели;
в форме графической пиктограммы, которая заменяет текст имени соответствующего стереотипа;
в форме прямоугольника класса с уменьшенной пиктограммой стереотипа внутри этого прямоугольника, расположенной, как правило, в верхнем правом углу.
Стереотипы обеспечивают применение специальной терминологии предметной области в дополнение или вместо терминологии используемой для расширяемого элемента. В метамодели языка UML. В язык UML уже заложено большое количество стереотипов, в дополнение к которым разработчики CASE-средств также могут добавлять свои стереотипы.
Ограничение – логическое условие, выраженное текстом на естественном языке или на языке, который может быть прочитан некоторой машиной, с целью декларирования семантики некоторого элемента модели. Ограничение является утверждением, которое указывает на то, что при правильном проектировании системы должно быть удовлетворено некоторое дополнительное условие.
Имя ограничения, как правило, не указывается, так как большинство ограничений являются безымянными. Логическое выражение может быть представлено в форме текста на естественном языке, не некотором языке программирования или на специально разработанном для этой цели языке – языке объектных ограничений (Object Constraint Language – OCL). Каждое ограничение может относиться или ссылается на один или несколько элементов модели, графически это обозначается пунктирной линией без направления, соединяющей элемент и ограничение.
Помеченное значение – явное определение некоторого свойства объекта в форме пары «имя = значение». В помеченном значении имя также называется тегом. Отдельные теги предопределены в языке UML, другие могут быть определены самим разработчиком. Помеченное значение в языке UML представляется только в форме текста, заключенного в фигурные скобки и размещенного ниже или после имени элемента модели. Помеченное значение также может быть изображено в форме примечания, присоединенного к соответствующему элементу модели.