
- •Информационные системы. Классификация. Предметная направленность. Корпоративные информационные системы. Стадия проектирования, разработки, внедрения, поддержки.
- •Типы документов для представления проектных решений.
- •Основные схемы декомпозиции действий и данных функциональной модели.
- •Понятие и иерархия моделей данных. Уровни представления моделей данных.Виды концептуальных моделей данных.
- •Нормализация концептуальной модели данных и целостность данных.
- •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 диаграмма классов является типом диаграммы статической структуры. Она описывает структуру системы, показывая её классы, их атрибуты и операторы, а также взаимосвязи этих классов.
Взаимосвязи
Взаимосвязь — это особый тип логических отношений между сущностями, показанных на диаграммах классов и объектов. В UML’е представлены следующие виды отношений:
Ассоциации
Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности.
Существует пять различных типов ассоциации. Наиболее распространёнными являются двунаправленная и однонаправленная. Например, классы «рейс» и «самолёт» связаны двунаправленной ассоциацией, а классы «человек» и «кофейный автомат» связаны однонаправленной.
Двойные ассоциации (с двумя концами) представляются линией, соединяющей два классовых блока. Ассоциации более высокой степени имеют более двух концов и представляются линиями, один конец которых идет к классовому блоку, а другой к общему ромбику. В представлении однонаправленной ассоциации добавляется стрелка, указывающая на направление ассоциации.
Ассоциация может быть именованной, и тогда на концах представляющей её линии будут подписаны роли, принадлежности, индикаторы, мультипликаторы, видимости или другие свойства.
Агрегация
Диаграмма классов, показывающая Агрегацию между двумя классами
Агрегация — это разновидность ассоциации при отношении между целым и его частями. Как тип ассоциации агрегация может быть именованной. Одно отношение агрегации не может включать более двух классов (контейнер и содержимое).
Агрегация встречается, когда один класс является коллекцией или контейнером других. Причём по умолчанию, агрегацией называют агрегацию по ссылке, то есть когда время существования содержащихся классов не зависит от времени существования содержащего их класса. Если контейнер будет уничтожен, то его содержимое — нет.
Графически агрегация представляется пустым ромбиком на блоке класса и линией, идущей от этого ромбика к содержащемуся классу.
Композиция
Композиция — более строгий вариант агрегации. Известна также как агрегация по значению.
Композиция имеет жёсткую зависимость времени существования экземпляров класса контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено.
Графически представляется как и агрегация, но с закрашенным ромбиком.
Различия между композицией и агрегацией
Целое композиции должно иметь мультипликатор 0..1 или 1, что показывает, что часть является частью только одного целого. В агрегации же может быть любой мультипликатор.
Приведём наглядный пример. Комната является частью квартиры, следовательно здесь подходит композиция, потому что комната без квартиры существовать не может. А, например, мебель не является неотъемлемой частью квартиры, но в то же время, квартира содержит мебель, поэтому следует использовать агрегацию.
Обобщение (наследование)
Диаграмма классов, показывающая наследование двух подклассов от одного суперкласса
Обобщение (Generalization) показывает, что один из двух связанных классов (подтип) является частной формой другого (надтипа), который называется обобщением первого. На практике это означает, что любой экземпляр подтипа является также экземпляром надтипа. Например: животные — супертип млекопитающих, которые, в свою очередь, — супертип приматов, и так далее. Эта взаимосвязь легче всего описывается фразой «А — это Б» (приматы — это млекопитающие, млекопитающие — это животные).
Графически обобщение представляется линией с пустым треугольником у супертипа.
Обобщение также известно как наследование или «is a» взаимосвязь.
Реализация
Реализация — отношение между двумя элементами модели, в котором один элемент (клиент) реализует поведение, заданное другим (поставщиком). Реализация — отношение целое-часть. Графически реализация представляется так же, как и наследование, но с пунктирной линией.
Зависимость
Зависимость (dependency) — это слабая форма отношения использования, при котором изменение в спецификации одного влечёт за собой изменение другого, причем обратное не обязательно. Возникает когда объект выступает например в форме параметра или локальной переменной.
Графически представляется пунктирной стрелкой, идущей от зависимого элемента к тому, от которого он зависит.
Существует несколько именованных вариантов.
Зависимость может быть между экземплярами, классами или экземпляром и классом.
Уточнения отношений
Уточнение имеет отношение к уровню детализации. Один пакет уточняет другой, если в нём содержатся те же самые элементы, но в более подробном представлении. Например, при написании книги вы наверняка начнете с формулировки предложения, в котором кратко будет представлено содержание каждой главы. Предположим, что резюме к каждой главе в качестве отдельного элемента входит в пакет «Предложение». Допустим также, что «Завершённая книга» — это пакет, элементами которого являются законченные главы. В этом контексте пакет «Завершённая книга» является уточнением пакета «Предложение».
Мощность отношений (Кратность)
Мощность отношения (мультипликатор) означает число связей между каждым экземпляром класса (объектом) в начале линии с экземпляром класса в её конце. Различают следующие типичные случаи:нотация объяснение пример
0..1 Ноль или один экземпляр кошка имеет или не имеет хозяина
1 Обязательно один экземпляр у кошки одна мать
0..* или * Ноль или более экземпляров у кошки может быть, а может и не быть котят
1..* Один или более экземпляров у кошки есть хотя бы одно место, где она спит