- •Понятие программного обеспечения, классификация программного обеспечения
- •Жизненный цикл по и его стандартизация, процессы жц по, группы процессов жц по
- •Процесс разработки по: основные действия и их содержание
- •Анализ требований к по
- •Проектирование архитектуры по
- •Кодирование и тестирование по
- •Сертификация процессов разработки по, модель 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. Объектно-ориентированные метрики: набор метрик Фернандо Аббреу
40. Диаграмма пакетов: назначение, пакеты и отношения между ними
Диаграмма пакетов предназначена для представления размещения элементов модели в пакетах и спецификации зависимостей между пакетами и их элементами. Как правило, основными предметами языка UML, изображаемыми на этой диаграмме, являются классы и пакеты.
Пакет – элемент модели, используемый для группировки других элементов модели. Элементы модели, входящие в состав некоторого пакета, называются его членами. Элементами пакета называются элементы модели, которые входят в пространство имен этого пакета. К элементам пакета относят как члены этого пакета, так и члены других импортируемых пакетов.
Рисунок 11 – Графическое изображение пакета
Изображение вложенности пакетов: а) – внутри пакета, б) – с помощью отношения вложенности
Дополнительно каждый элемент пакета может иметь видимость, которая в общем случае может быть общедоступной (public), частной (private) или пакетной (packaged).
Импорт пакета – направленное отношение между пакетами, при котором члены одного пакета могут быть добавлены в пространство имен другого пакета. Импорт пакета обозначается с помощью отношения зависимости, направленного от импортирующего пакета к импортируемому пакету, со стереотипом <<import>> – для общедоступного импорта пакета или <<access>> – для закрытого импорта пакета.
Помимо импорта пакетов в языке UML присутствует импорт элемента, который означает направленное отношение между импортирующим пространством имен и отдельным элементом пакета, которое позволяет ссылаться на этот элемент с использованием неквалифицированного имени. Также как и в случае импорта пакетов возможен общедоступный (стереотип <<import>>) и закрытый (стереотип <<access>>) импорт элемента.
Слияние пакетов – направленное отношение между двумя пакетами, один из которых расширяет свое содержание посредством добавления содержимого другого пакета. Отношение слияния пакетов является специализацией отношения зависимости, указываемой со стереотипом <<merge>>.
41.Диаграмма объектов, назначение, объекты и отношения между ними
Диаграмма объектов предназначена для спецификации объектов и связей между ними для фиксированного момента времени. Данная диаграмма как каноническая диаграмма языка UML появилась только в стандарте 2.0.
Объект является отдельным экземпляром класса, который создается на этапе реализации модели или выполнения программы. Графически объект в языке UML изображается в виде классификатора, внутри которого записывается имя объекта и значения его атрибутов. Имя объекта представляет собой строку текста, записанную согласно следующей нотации БНФ:
<имя> ::= [<собственное-имя>] | [‘:’ <имя-класса> [‘,’ <имя-класса>]* ]
В записи имени объекта собственное имя и имя класса не могут отсутствовать одновременно, а сама запись имени подчеркивается. Возможны следующие варианты записей имен объектов:
o: C – для объекта специфицировано собственное имя объекта и имя класса;
o – для объекта специфицировано только собственное имя объекта;
:C – для объекта специфицировано только имя класса (анонимный объект).
На рисунке 19 приведены несколько примеров изображения объектов с различными вариантами их именования.
Рисунок 19 – Примеры изображения объектов а) – полная спецификация имени объекта; б) – имя класса отсутствует; в) – отсутствует имя объекта
На диаграмме объекты между собой могут соединяться между собой бинарной ассоциацией, которая, как и на диаграмме классов, может иметь имя, роли концов и стрелки навигации. Имя ассоциации может быть подчеркнуто, для обозначения связи между объектами. На рисунке 20 приведен пример отношения между двумя объектами:
Рисунок 20 – Пример связи между объектами
Для объекта могут быть указаны значения его структурных характеристик (атрибутов). Прямоугольник, изображающий объект, может быть разделен на две части: в верхней части указывается имя объекта, а в нижней – список атрибутов объекта. В некоторых CASE-средствах такое деление может отсутствовать, тогда характеристики объекта указываются под его именем. Описание характеристики объекта имеет следующий формат (в нотации БНФ):
<характеристика> ::= <имя> [‘:’ <тип> ] ‘=’ <значение>
Характеристика, специфицирующая объект, может быть непосредственной или наследуемой структурной характеристикой класса, экземпляром которого является описываемый объект. На рисунке 21 приведен пример анонимного объекта класса Человек с указанием его характеристик.
Рисунок 21 – Пример изображения объекта с указанием его характеристик
Изображение объекта с указанием значений его характеристик в некоторой литературе называют спецификацией экземпляра и выделяют в виде отдельного элемента диаграммы. Спецификация экземпляра имеет такую же графическую нотацию, как и объект. Основным предназначением спецификации экземпляра является указание только общей информации об объектах соответствующих классов без описания особенности времени выполнения.
Как уже было отмечено, диаграмма объектов представляет некоторый статический вид системы с точки зрения проектирования или процесса (снимок в определенный момент времени). Ни одна отдельно взятая диаграмма объектов не в состоянии передать всю заключенную в этих видах информацию. Следовательно, диаграммы объектов должны отражать только некоторые конкретные объекты или прототипы, входящие в состав работающей системы.