
- •Информационные системы. Классификация. Предметная направленность. Корпоративные информационные системы. Стадия проектирования, разработки, внедрения, поддержки.
- •Типы документов для представления проектных решений.
- •Основные схемы декомпозиции действий и данных функциональной модели.
- •Понятие и иерархия моделей данных. Уровни представления моделей данных.Виды концептуальных моделей данных.
- •Нормализация концептуальной модели данных и целостность данных.
- •Bcnf - нормальная форма Бойса-Кодда вводит дополнительное ограничение в сравнении с 3нф.
- •Анализ информационной связности действий и систем.
- •Анализ функциональной связности данных и систем.
- •Анализ производительности ис
- •Психологические аспекты принятия решений в процессе проектирования.
- •Организационные формы управления проектами
- •Архитектура корпоративных информационных систем (кис)
- •Mrp/erp системы. Современная структура модели mrp/erp
- •Тестирование. Методы тестирования. Категории тестов и оценок системы. Планирование тестирования и оценки системы.
- •Тестирование программного обеспечения
- •Уровни тестирования
- •Верификация и валидация – цели и задачи. V – модель как основа организации процесса верификации.
- •Основные принципы
- •Достоинства
- •Ограничения
- •Аутсорсинг и определение поставщиков.
- •Язык uml (Unificed Moeling Language). Основные модели uml (схема). Виды диаграмм.
- •Диаграмма вариантов использования. Виды отношений между актерами и вариантами использования. Отношения ассоциации, расширения, включения, обобщения
- •Диаграмма классов
- •Диаграмма состояний
- •Диаграмма деятельности. Диаграммы взаимодействия
- •Диаграмма последовательности. Диаграмма кооперации
- •Диаграмма компонентов. Диаграмма развертывания
- •23) Языки и среды моделирования архитектуры предприятия. Языки моделирования предприятий. Idеf, dfd- технология, aris, bpml.
- •24) Структурный (функциональный) и процессный подходы к разработке информационных систем
- •25) Управление требованиями к информационной системе. ГосТы и методология rup.
- •Принципы
- •Жизненный цикл разработки
- •1. Начало (Inception)
- •2. Уточнение (Elaboration)
- •3. Построение (Construction)
- •4. Внедрение (Transition)
- •Автоматизированное создание документов серии гост 34 и 19 с помощью инструментальных средств фирмы ibm Rational
- •26) Моделирование потоков данных. Основные компоненты диаграмм
- •1. Внешние сущности
- •2. Системы и подсистемы
- •3. Процессы
- •4. Накопители данных
- •5. Потоки данных
- •6. Построение иерархии диаграмм потоков данных
- •27) Диаграмма «сущность–связь» (erd). Сущность (Entity). Связь (Relationship). Атрибут. Виды идентификации. Подтипы и супертипы
- •28) Стадии разработки информационных систем. Модели представления для описания проектных решений. Уровни детализации, регламентирующие методики проектирования. Этапы создания информационных систем
- •29) Модели жизненного цикла программного продукта. Виды и особенности. Процессы жизненного цикла систем по iso 15288:2002
- •V модель (разработка через тестирование)
- •Iso / iec 15288 - Инженерные системы стандартных охватывающих процессы и этапы жизненного цикла.
- •30) Понятие требования. Классификация требований. Свойства требований
Диаграмма вариантов использования. Виды отношений между актерами и вариантами использования. Отношения ассоциации, расширения, включения, обобщения
Диаграмма прецедентов (англ. use case diagram, диаграмма вариантов использования) в UML — диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне.
Прецедент — возможность моделируемой системы (часть её функциональности), благодаря которой пользователь может получить конкретный, измеримый и нужный ему результат. Прецедент соответствует отдельному сервису системы, определяет один из вариантов её использования и описывает типичный способ взаимодействия пользователя с системой. Варианты использования обычно применяются для спецификации внешних требований к системе
Назначение
Основное назначение диаграммы — описание функциональности и поведения, позволяющее заказчику, конечному пользователю и разработчику совместно обсуждать проектируемую или существующую систему.
При моделировании системы с помощью диаграммы прецедентов системный аналитик стремится:
чётко отделить систему от её окружения;
определить действующих лиц (актёров), их взаимодействие с системой и ожидаемый функционал системы;
определить в глоссарии предметной области понятия, относящиеся к детальному описанию функционала системы (то есть, прецедентов).
Работа над диаграммой может начаться с текстового описания, полученного при работе с заказчиком. При этом нефункциональные требования (например, конкретный язык или система программирования) при составлении модели прецедентов опускаются (для них составляется другой документ).
Элементы
Для отражения модели прецедентов на диаграмме используются[1]:
рамки системы (англ. system boundary) — прямоугольник с названием в верхней части и эллипсами (прецедентами) внутри. Часто может быть опущен без потери полезной информации,
актёр («эктор») — стилизованный человечек, обозначающий набор ролей пользователя (понимается в широком смысле: человек, внешняя сущность, класс, другая система), взаимодействующего с некоторой сущностью (системой, подсистемой, классом). Актёры не могут быть связаны друг с другом (за исключением отношений генерализации/наследования),
прецедент — эллипс с надписью, обозначающий выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам. Надпись может быть именем или описанием (с точки зрения актёров) того, «что» делает система (а не «как»). Имя прецедента связано с непрерываемым (атомарным) сценарием — конкретной последовательностью действий, иллюстрирующей поведение[2]. В ходе сценария актёры обмениваются с системой сообщениями. Сценарий может быть приведён на диаграмме прецедентов в виде UML-комментария. С одним прецедентом может быть связано несколько различных сценариев.
Отношения между прецедентами
Часть дублирующейся информации в модели прецедентов можно устранить указанием связей между прецедентами:
обобщение прецедента — стрелка с незакрашенным треугольником (треугольник ставится у более общего прецедента),
включение прецедента — пунктирная стрелка со стереотипом «include»,
расширение прецедента — пунктирная стрелка со стереотипом «extend» (стрелка входит в расширяемый прецедент, в дополнительном разделе которого может быть указана точка расширения и, возможно в виде комментария, условие расширения)
Правила
При работе с вариантами использования важно помнить несколько простых правил:
каждый прецедент относится как минимум к одному действующему лицу;
каждый прецедент имеет инициатора;
каждый прецедент приводит к соответствующему результату.