
- •2 Жизненный цикл программного обеспечения. Дать краткую характеристику каждого этапа.
- •3 Почему программные системы сложны. Привести пять признаков сложной системы.
- •4 Техническое задание. Перечислить и охарактеризовать разделы, входящие в техническое задание.
- •5 Унифицированный процесс разработки программного обеспечения. Основные принципы унифицированного процесса.
- •6 Жизненный цикл унифицированного процесса. Цели каждого из этапов.
- •7 Работа с кадрами. Перечислить роли разработчиков и дать характеристику каждой из них.
- •8 Использование языка uml при проектировании сложных программных систем. Какие диаграммы используются в uml для создания моделей программной системы.
- •9 Диаграмма вариантов использования, ее назначение. Рассказать о варианте использования и действующем лице. Правила построения диаграммы вариантов использования.
- •10 Что такое классификация с точки зрения объектно-ориентированного проектирования программных систем. Теории классификации.
- •11 Методы классификации.
- •12 Диаграммы взаимодействия. Основное назначение.
- •13 Диаграмма классов. Ее назначение. Что она включает. Рассказать об основных видах связей между классами.
- •14 Дать определение тестированию и отладке. Особенности и объекты тестирования. Автономное и комплексное тестирование.
- •15 Дать определение тестированию и отладке. Направления тестирования. Стратегия тестирования. Контрольный лист тестирования модуля.
- •16 Дать определение тестированию и отладке. Локализация ошибок. Классификация ошибок.
- •17 Документирование. Состав и содержание документов прилагаемых к программной системе.
- •18 Оценка качества ПрогОбесп. Методы оценки свойств ПрогОбес.
- •19 Уровни зрелости организации с точки зрения cmm.
- •20 Понятие стандарта. Что включает в себя стандарт.
- •21 Сертификация. Схемы сертификации.
- •22 Психологич факторы проектирования интерфейса пользователя.
- •23 Правила построения удобного интерфейса пользователя.
- •24 Принципы построения интерфейса пользователя.
- •25 Проектирование, ориентированное на использование.
9 Диаграмма вариантов использования, ее назначение. Рассказать о варианте использования и действующем лице. Правила построения диаграммы вариантов использования.
Use case diagram (диаграммы сценариев)
Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций.
Диаграммы вариантов использования используются для отображения ролей пользователей проектируемой системы и набора возможностей программы, которые может использовать тот или иной пользователь. Пользователями системы могут являться люди, либо внешние материальные объекты (например, устройства ввода-вывода, обработки информации и т.д.) Для построения удачной системы надо знать требования пользователей (кто-либо или/и что-либо, что взаимодействует с разрабатываемой системой). Такое взаимодействие называется вариантом использования. Варианты использования направляют в проектирование, реализацию и тестирование системы, т.о., они направляют процесс разработки.
На диаграммах вариантов использования изображаются актеры и варианты использования, между которыми существуют отношения. Диаграммы ВИ применяются при бизнес-анализе для моделирования видов работ, выполняемых организацией, и для моделирования функциональных требований к ПС при ее проектировании и разработке. Построение модели требований при необходимости дополняется их текстовым описанием. При этом иерархическая организация требований представляется с помощью пакетов usecases.
Актером будем называть внешнюю по отношению к ПС сущность, которая может взаимодействовать с системой. Актерами могут быть как люди, так и внешние системы или устройства. Следует всегда помнить, что актер – это не конкретный человек или устройство, а роль (должностная обязанность), в которой он выступает по отношению к программной системе. Нахождение актеров – один из первых шагов в определении использования любой системы. Каждый источник внешних событий, с которыми должна взаимодействовать система, представляется как актер. На диаграммах ВИ актер изображается в виде стилизованной человеческой фигурки.
При взаимодействии актера с системой последняя выполняет ряд работ, которые образуют вариант использования системы (usecase). Каждый актер может использовать систему по разному, то есть инициировать выполнение разных ВИ. Таким образом, каждый ВИ, по существу, есть некоторое функциональное требование к системе. ВИ не представляет собой конструкцию, напрямую реализуемую в программном коде. Все его поведение реализуется в виде классов и компонент.ВИ описывает, что делает ПС, но не как она это делает. Лучший путь к нахождению ВИ – рассмотреть, что требует каждый актер от системы. На диаграммах ВИ изображается в виде овала.
Отношения
Ассоциация – единственно возможная связь между актером и ВИ. Она показывает, что актер и ВИ общаются друг с другом, посылая и получая сообщения.
Если два или более ВИ имеют сходство в структуре и поведении, то целесообразно выделить общий фрагмент и построить новый, родительский ВИ. Исходные ВИ будут являться дочерними по отношению к родительскому. Дочерний ВИ наследует все поведение, описанное в родительском варианте. Отношение обобщения между двумя ВИ означает, что когда осуществляется дочерний ВИ, необходимо исполнение и родительского (см. рис.2б).
Отношение включения, означает, что для полного осуществления основного (базового) ВИ необходимо выполнение и включаемого варианта. В общем случае выделение включаемых ВИ будет целесообразным в тех случаях, когда такой вариант включается в несколько базовых. Включение показывается пунктирной стрелкой, направленной от базового ВИ к включаемому (см. рис.2б).
Правила построения диаграммы вариантов:
нельзя моделировать связь между действующими лицами.
действующим лицом является личность или система, непосредственно работающая с программным комплексом.
каждый вариант использования д.б. инициирован действующим лицо (есть исключения).
нельзя моделировать связь между двумя вариантами использования за исключением отношений расширения и включения.
думать о БД как надстройке, находящейся под диаграммой вариантов использования.
Рис.
2а. Пример диаграммы ВИ
Рис.
2б. Пример диаграммы ВИ