- •Парадигмы программирования предпосылки появления, обзор существующих парадигм программирования.
- •3.2. Процедурная парадигма
- •3.2.1. История возникновения парадигмы
- •3.2.2. Языки, поддерживающие парадигму
- •3.2.3. Представление программ и реализация вычислений
- •Основные принципы объектно-ориентированной парадигмы.
- •Наследование и агрегация как реализации принципа иерархии в ооАиП.
- •Анализ и проектирование программного обеспечения: .Цели, классификация.
- •Структурный анализ программных систем: основные принципы, существующие методологии.
- •Диаграммы переходов состояний (std): назначение, нотация, примеры реализации.
- •Объектно-ориентированный анализ: базовые принципы, методология.
- •Язык uml: назначение, структура, нотация.
- •Сущности uml: типы, нотация, примеры описания.
- •Отношения uml: типы, нотация, примеры применения.
- •Диаграммы прецедентов uml: назначение, .Используемые элементы, примеры построения.
- •Диаграммы классов uml: назначение, используемые элементы, примеры построения.
- •Диаграммы взаимодействия uml: назначение, используемые элементы, примеры построения.
- •.Метрики качества структурного и объектно-ориентированного анализа и проектирования.
- •Понятие объекта и класса в объектно-ориентированном программировании. Члены-данные и члены функции.
- •2. Объект - как базовое понятие в объектно-ориентированном программировании
- •17.Конструкотр и деструктор.
- •18. Реализация принципа инкапсуляции ограничением области видимости компонент.
- •19. Аксессоры доступа к закрытым компонентам класса.
- •20. Статические компоненты класса: назначение, особенности и примеры использования.
- •Перегрузка стандартных операций: назначение, синтаксические особенности, примеры реализации.
- •Исключительные ситуации и способы их обработки. Блоки обработки и блоки завершения. Структурная обработка исключительных ситуаций.
- •Реализация принципа наследования в объектно-ориентированных языках программирования. Виды наследования.
- •Объявление наследования. Порядок определения новых и переопределения унаследованных компонент класса. Модификация области видимости компонент класса при наследовании.
- •Множественное наследование: объявление, примеры реализации, недостатки. Виртуальное наследование.
- •Виртуальные функции и полиморфизм – назначение, примеры практического использования.
- •Абстрактные классы: определение, назначение, примеры использования.
- •Интерфейс: назначение, синтаксис определения, примеры использования.
- •Основные принципы обобщенного программирования, его достоинства и недостатки.
- •Обобщение функций и методов: синтаксис определения, инстанцирование, особенности использования.
- •Обобщенные классы: синтаксис определения, примеры объявления и конкретизации.
- •Коллекции с#: реализация интерфейсов для сортировки элементов.
- •Делегаты c# как основной тип функторов.
- •Шаблоны проектирования: определение, классификация, назначение, достоинства и недостатки.
- •Шаблон Одиночка (Singleton): описание и пример программной реализации.
- •Шаблон Адаптер: назначение, структура, пример программной реализации.
- •Шаблон Наблюдатель (Observer): структура, пример реализации на языке c# с использованием событий (Events)
- •Архитектурный шаблон mvc: назначение, возможные структурные решения, примеры практической реализации
Диаграммы прецедентов uml: назначение, .Используемые элементы, примеры построения.
Диаграмма прецедентов.
Диаграммы прецедентов позволяют определить и задокументировать функциональные требования к системе. Смысл выделения прецедентов заключается в описании типичных взаимодействий между пользователями системы и самой системой и предоставлении описания процесса ее функционирования. Основные сущности, используемы в диаграммах этого типа – актёры и прецеденты (варианты использования). Прецедент представляет на Use Case диаграммах множество сценариев, объединенных некоторой общей целью пользователя. На рис. 6 представлена диаграмма использования для электронной системы бронирования билетов.
Рисунок 6. Use Case диаграмма для системы удаленного бронирования билетов в кинотеатре
Диаграмма иллюстрирует не только факт использования тем или иным актёром некоторого прецедента (Гость может просмотреть список сеансов и зарегистрироваться, Зритель может заказать и оплатить билет), но и позволяет отобразить отношения между и прецедентами. Отношение типа «расширение» («extend») применяют, когда один вариант использования подобен другому, но несет несколько другую нагрузку и, в связи с этим, необходимо описать изменение в обычном поведении системы. В частности, прецедент Оплатить билет является частным случаем прецедента Оплаты через банк, т.е. он расширяет этот прецедент на некоторую конкретную функциональность. Отношение типа «использование» («include», «uses» ) применяется в тех случаях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования и нет смысла копировать его описание. В рассмотренной диаграмме чтобы заказать билет необходимо использовать прецеденты Просмотр сеансов и Выбор места в кинозале.
Рассмотрим еще одну диаграмму использования. Она построена для системы синхронизации содержимого локального диска с сетевым хранилищем (рис.7). В системе присутствуют три актера – Гость, Пользователь и Внешнее сетевое хранилище, выступающие в качестве внешних по отношению к рассматриваемой системе сущностей.
Актер Гость может действовать в рамках трех прецедентов Просмотра публичных файлов, т.е. файлов, к которым в сетевом хранилище владелец предоставил доступ всем желающим, Входа в систему, чтобы перейти в статус пользователя, а также прецедента Регистрации, после которого будет авторизован в системе.
.
Каждый прецедент на диаграмме требует описания. Описание должно включать в себя имя прецедента, подробное описание его цели, область действия прецедента, основное действующее лицо в рамках прецедента, перечень других участников и их интересы, предусловие, описывающее действия, обязательно выполняемые системой перед тем, как она разрешит начать работу прецедента, гарантию, описывающую обязательные действия системы по окончании работы шаблона ответа, триггер, который определяет событие, инициирующее выполнение прецедента, основной сценарий достижения цели прецедента.
Прецеденты представляют собой ценный инструмент для понимания функциональных требований к системе. Начальный вариант диаграммы прецедентов обычно составляется на ранней стадии выполнения проекта. По мере развития проекта и выявления деталей каждый прецедент описывается всё более подробно на укрупненных диаграммах..
