- •Базы данных: основные понятия и определения. Требования, предъявляемые к базам данных
- •Выбор хранимых данных
- •Реляционная модель данных
- •Реляционная алгебра
- •Операция выборка
- •Операция проекция
- •Операция естественное соединение
- •Операция соединение по условию (θ – соединение)
- •Операция деления
- •Методология проектирования баз данных. Основные задачи проектирования баз данных
- •Основные этапы проектирования баз данных
- •Концептуальное (инфологическое) проектирование бд
- •Логическое (даталогическое) проектирование бд
- •Принципы и средства структурного подхода к разработке по
- •Методология структурного анализа и проектирования sadt
- •Диаграммы потоков данных: внешние сущности, системы и подсистемы, процессы, хранилища данных, потоки данных. Нотация Гейна – Сарсона
- •Сравнительный анализ sadt-моделей и диаграмм потоков данных
- •Функциональные модели, используемые на стадии проектирования
- •14. Методология моделирования idef3: составные элементы, объекты ссылок, перекрестки.
- •15. Подходы к моделированию в базах данных
- •16. Анализ предметной области. Описание объектов и их свойств. Связи между элементами моделей данных. Описание сложных объектов
- •17. Проблема целостности базы данных
- •18. Даталогическое проектирование. Нотация Питера Чена. Нотация idef 1х
- •Нотация Питера Чена.
- •Нотация idef 1x
- •19. Проектирование реляционных баз данных на основе принципов нормализации. Правила технической нормализации
- •20. Алгоритм процесса нормализации схем отношений
- •21. Нормализация. Функциональная зависимость. Первая, вторая, нормальные формы
- •22. Нормализация. Функциональная зависимость. Третья нормальная форма
- •23. Нормализация. Функциональная зависимость. Нормальная форма Бойса – Кодда
- •24. Разработка реляционных баз данных на основе принципов нормализации
- •25. Основные аксиомы Армстронга. Замыкание
- •26. Нормальные формы высших порядков
- •27. Методологии проектирования
- •28. Инфологическое моделирование данных: модель «сущность-связь»
- •29. Принципы поддержки целостности в реляционной модели данных
- •30. Моделирование данных. Метод Баркера
- •31. Моделирование данных. Метод idef1x
- •32. Case-средство для концептуального моделирования данных на стадии формирования требований к ис – Silverrun
- •33. Нормализация. Функциональная зависимость. Первая, вторая, третья нормальные формы. Нормальная форма Бойса – Кодда
- •34. Инструментальные средства моделирования. Проектирование баз данных с использованием са erWin Data Modeler (erWin)
- •35. Алгоритм перехода от er – модели к реляционной схеме данных
- •36. Основные принципы объектно-ориентированного моделирования
- •37. Сущность методологии объектно-ориентированного анализа и проектирования
- •38. Язык объектного моделирования uml. Виды диаграмм uml. Последовательность построения диаграмм
- •Диаграмма состояний
- •Диаграмма последовательностей
- •Диаграмма активности
- •39. Модель прецедентов (вариантов использования, use-cases)
- •40. Моделирование статической структуры системы с помощью диаграммы классов: стереотипы классов
- •41. Моделирование статической структуры системы с помощью диаграммы классов: механизм пакетов
- •42. Моделирование статической структуры системы с помощью диаграммы классов: атрибуты
- •43. Моделирование статической структуры системы с помощью диаграммы классов: основные и вспомогательные операции
- •44. Моделирование статической структуры системы с помощью диаграммы классов: типы связей
- •45. Инкапсуляция, наследование, полиморфизм
- •46. Моделирование поведения системы
- •47. Использование диаграммы последовательностей для упорядочивания сообщений во времени
- •48. Использование диаграммы кооперации для описания структурной организации объектов
- •49. Моделирование физических аспектов функционирования системы с помощью диаграмм развертывания
- •50. Особенности построения физической модели базы данных
- •51. Ограничения ссылочной целостности
- •52. Моделирование процессов обработки данных
- •53. Индексирование
- •54. Методы совместного доступа к базам данных
- •55. Транзакции и блокировки
- •56. Типы параллелизма
- •57. Свойства транзакций. Способы завершения транзакций
- •58. Проблемы параллельного выполнения транзакций
- •59. Методы сериализации транзакций. Механизм блокировок. Типы конфликтов
- •60. Правила совместимости захватов. Проблема тупиковых ситуаций и ее решение
- •61. Уровни изолированности пользователей
- •62. Гранулированные синхронизационные захваты
- •63. Метод временных меток
- •64. Предикатные синхронизационные захваты
41. Моделирование статической структуры системы с помощью диаграммы классов: механизм пакетов
Один из подходов к решению проблемы сложности систем ПО заключается в группировке классов в компоненты более высокого уровня. Эта идея проявляется во многих объектно-ориентированных методах. В UML такой способ группировки носит название механизма пакетов (package).
Пакеты применяют, чтобы сгруппировать классы, обладающие некоторой общностью. Существует несколько наиболее распространенных подходов к группировке. Во-первых, можно группировать их по стереотипу. В таком случае получается один пакет с классами-сущностями, один с граничными классами, один с управляющими классами и т.д. Этот подход может быть полезен с точки зрения размещения готовой системы, поскольку все находящиеся на клиентских машинах пограничные классы уже оказываются в одном пакете.
Другой подход заключается в объединении классов по их функциональности. Например, в пакете Security (безопасность) содержатся все классы, отвечающие за безопасность приложения. В таком случае другие пакеты могут называться Employee Maintenance (Работа с сотрудниками), Reporting (Подготовка отчетов) и Error Handling (Обработка ошибок). Преимущество этого подхода заключается в возможности повторного использования.
Механизм пакетов применим к любым элементам модели, а не только к классам. Если для группировки классов не использовать некоторые эвристики, то она становится произвольной. Одна из них, которая в основном используется в UML, – это зависимость. Зависимость между двумя пакетами существует в том случае, если между любыми двумя классами в пакетах существует любая зависимость. Таким образом, диаграмма пакетов (рис.) представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов, то есть диаграмма пакетов – это форма диаграммы классов.
Зависимость между двумя элементами имеет место в том случае, если изменения в определении одного элемента могут повлечь за собой изменения в другом. Что касается классов, то причины для зависимостей могут быть самыми разными:
· один класс посылает сообщение другому;
· один класс включает часть данных другого класса;
· один класс использует другой в качестве параметра операции.
Если класс меняет свой интерфейс, то любое сообщение, которое он посылает, может утратить свою силу. Пакеты не дают ответа на вопрос, каким образом можно уменьшить количество зависимостей в вашей системе, однако они помогают выделить эти зависимости, а после того, как они все окажутся на виду, остается только поработать над снижением их количества. Диаграммы пакетов можно считать основным средством управления общей структурой системы.
42. Моделирование статической структуры системы с помощью диаграммы классов: атрибуты
Атрибут (свойство) – это именованное свойство класса, описывающее диапазон значений, которые может принимать экземпляр атрибута. Класс может иметь любое число атрибутов или не иметь ни одного. В последнем случае блок атрибутов оставляют пустым.
Атрибут представляет некоторое свойство моделируемой сущности, которым обладают все объекты данного класса. Имя атрибута, как и имя класса, может представлять собой текст. На практике для именования атрибута используются одно или несколько коротких существительных, выражающих некое свойство класса, к которому относится атрибут.
Можно уточнить спецификацию атрибута, указав его тип, кратность (если атрибут представляет собой массив некоторых значений) и начальное значение по умолчанию.
Статические атрибуты класса обозначаются подчеркиванием.
