
- •Информационные системы. Классификация. Предметная направленность. Корпоративные информационные системы. Стадия проектирования, разработки, внедрения, поддержки.
- •Типы документов для представления проектных решений.
- •Основные схемы декомпозиции действий и данных функциональной модели.
- •Понятие и иерархия моделей данных. Уровни представления моделей данных.Виды концептуальных моделей данных.
- •Нормализация концептуальной модели данных и целостность данных.
- •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) Понятие требования. Классификация требований. Свойства требований
Язык uml (Unificed Moeling Language). Основные модели uml (схема). Виды диаграмм.
UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.
Концептуальная модель (conceptual model). На диаграммы такой модели будут смотреть, их будут обдумывать, но с самой моделью ничего делать не будут. Это не означает, что модель не нужна — это означает, что модель используется только для облегчения понимания концепции системы. Поэтому мы называем такие модели концептуальными. Такой тип использования моделей один из самых важных, например, потому что так используются модели, которые получаются в результате анализа предметной области. Концептуальные модели довольно стабильны: если не меняется предметная область, то нет нужды менять и модель. Главное требования к модели предметной области: концептуальная целостность (consistency).
Модель проектирования (design model). Модель проектирования представляет собой высокоуровневое (на уровне подсистем) и низкоуровневое (на уровне классов, если речь идет об использовании объектно-ориентированного подхода) описание программной системы. Модель проектирования предназначена для того, чтобы, руководствуясь ею, разработать программный код приложения. Как правило, архитектура (высокоуровневое описание) и код разрабатываются итеративно, и разработчикам в процессе разработки необходимо часто вносить изменения в модель проектирования, чтобы она всегда оставалась актуальной. Главное требование к модели проектирования: понятность (usability). Действительно, разработчики должны полностью понимать модель проектирования, чтобы вести разработку.
Модель реализации (implementation model). Модель реализации предназначена для автоматического преобразования, возможно многократного, в существенно другой вид, например, в исполнимый код. Модель реализации модифицируется постоянно все время разработки, она должна быть в равной степени понятна как разработчику, так и компьютеру. Такое предназначение требует указания необходимых деталей реализации в модели, поскольку самостоятельно компьютер их добавить не сможет. Главное требование к моделям реализации: полнота (completeness).
Рассмотрим простой пример (рис 1): отношения между авторами (Author) и книгой (Book). С концептуальной точки зрения книга (1) — это тип издания, который имеет авторов (2), причем соавторов у книги может быть несколько и каждый может быть автором нескольких книг. Важно учесть, что в создание книги каждый соавтор внес определенный вклад (3). В модели проектирования необходимо уточнить, что абстрактный творческий вклад измеряется в конкретных процентах (4), а в модели реализации добавить, что необходимо реализовать проверку ограничения (5), состоящего в том, что для каждой книги сумма вкладов всех ее авторов должна быть равна 100%. Эти ограничения значений вклада каждого автора в работу над книгой, измеряемого в процентах, представлены в модели реализации в виде комментариев.
Рисунок 1. Концептуальная модель, модель проектирования и модель реализации
Как мы видим, виды моделей UML различаются количеством представленной на них информации и точкой зрения на систему: в каждой них внимание фокусируется на определенных артефактах процесса разработки. Некоторые модели могут включать в свой состав дополнительные поясняющие диаграммы.
Например, в качестве дополнения к модели реализации можно привести поясняющую диаграмму объектов, где указать конкретную книгу (1), конкретных авторов (2) и конкретный вклад каждого из авторов (3).
Рисунок 2. Поясняющая диаграмма объектов
Структурные диаграммы:
Диаграмма классов
Диаграмма компонентов
Композитной/составной структуры
Диаграмма кооперации (UML2.0)
Диаграмма развёртывания
Диаграмма объектов
Диаграмма пакетов
Диаграмма профилей (UML2.2)
Диаграммы поведения:
Диаграмма деятельности
Диаграмма состояний
Диаграмма прецедентов
Диаграммы взаимодействия:
Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
Диаграмма обзора взаимодействия (UML2.0)
Диаграмма последовательности
Диаграмма синхронизации (UML2.0)