- •1. Технология разработки программного обеспечения. Определение. Основные этапы на примере классического жизненного цикла.
- •2. Два взгляда на по: научная разработка, программное изделие. Свободное по.
- •3. Парадигмы проектирования программных систем. Макетирование.
- •4.Парадигмы проектирования пс. Инкрементная модель.
- •5. Парадигмы проектирования программных систем. Быстрая разработка приложений.
- •6. Парадигмы проектирования программных систем. Спиральная модель.
- •7. Парадигмы проектирования программных систем. Компонентно-ориентированная модель.
- •8. Парадигмы проектирования программных систем. Унифицированный процесс. Rup.
- •1. Начало
- •2. Уточнение
- •3. Построение (Конструирование)
- •4. Внедрение
- •9. Парадигмы проектирования программных систем. Экстремальное программирование.
- •10. Спецификация требований. Виды требований.
- •1) Пользовательские требования
- •2) Системные требования
- •3) Проектная системная спецификация.
- •11. Функциональные требования.
- •12. Нефункциональные требования.
- •13. Требования предметной области.
- •14. Пользовательские требования.
- •15. Системные требования.
- •16. Описание технического задания по гост.
- •17. Прецеденты. Определение. Актеры. Сценарии.
- •18. Задачи и рамки прецедентов.
- •19. Степень формализации прецедентов. Сжатый, свободный и развёрнутый формат описания.
- •20. Пояснения к прецедентам. Предусловия и постусловия. Альтернативные сценарии.
- •22. Объектно-ориентированные анализ и проектирование программных систем. Основные определения.
- •23. Основные принципы объектно-ориентированной разработки программ.
- •24. Обязанности объектов. Разложение системы на объекты. Crc-карты.
- •25. Инкапсуляция. Связность внутри классов и зацепление между классами.
- •26. Композиция и наследование. Абстрактные классы. Интерфейс класса. Рекомендации.
- •27. Методы, операции, сообщения. Разделение команд и запросов.
- •28. Проектирование по контракту. Предусловия и постусловия в методах. Инварианты.
- •29. Паттерны проектирования. Определение. Формат описания.
- •30. Виды паттернов по уровню абстракции и по цели. Примеры.
- •36. Минимальное грубое тестирование
- •37. Автоматизированные тесты. Основные определения. XUnit
- •38. Разработка через тестирование
- •39. Особенности командной разработки по
- •40. Оценка стоимости по. Модели и методики. Модель cocomo
29. Паттерны проектирования. Определение. Формат описания.
В 1979 году вышла книга «The Timeless Way of Building». Книга была посвящена архитектуре.
Автор книги сформулировал для себя следующие вопросы:
что есть такого в хорошем проекте, что отличает его от плохого проекта?
Что именно отличает проект низкого качества от проекта высокого качества?
В результате исследований он увидел, что хорошие проекты имеют между собой много общего.
Шаблон (паттерн) – решение определенной задачи в конкретном контексте. Так как решение предполагается использовать многократно, то есть необходимость в создании «каталога готовых решений, описанных должным образом».
Каждый элемент каталога содержит следующие элементы:
- имя паттерна
- задача – описывает назначение паттерна и описание задачи, которую он может решить. Также следует описать контекст, в котором возникает задача.
- решение – описывается способ решения поставленной задачи
- результаты – следствие применения паттерна и разного рода компромиссы
Паттерны делят на 3 категории:
архитектурные паттерны
паттерны проектирования – описание взаимодействия объектов и классов, адаптированных для решения общих задач проектирования в конкретном контексте.
идеомы – зависят от конкретного языка программирования, учитывают его специфику
Выделяют 3 цели:
- порождение
- структурирование
- описание поведения
Выделяют 2 уровня:
- уровень класса
- уровень объекта
Даже появилась методика разработки ПО на основе паттернов. Сила паттернов проявляется тогда, когда они используются вместе и согласованно.
30. Виды паттернов по уровню абстракции и по цели. Примеры.
Выделяют 3 цели:
- порождение
- структурирование
- описание поведения
Выделяют 2 уровня:
- уровень класса
- уровень объекта
Структурирование – паттерн Фасад
Проблема: Как обеспечить унифицированный интерфейс с набором разрозненных реализаций или интерфейсов, например, с подсистемой, если нежелательно высокое связывание с этой подсистемой или реализация подсистемы может измениться?
Решение: Определить одну точку взаимодействия с подсистемой - фасадный объект, обеспечивающий общий интерфейс с подсистемой и возложить на него обязанность по взаимодействию с ее компонентами. Фасад - это внешний объект, обеспечивающий единственную точку входа для служб подсистемы. Реализация других компонентов подсистемы закрыта и не видна внешним компонентам.
Шаблон Facade (Фасад) — Шаблон проектирования, позволяющий скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы.
Описание поведения – паттерн Итератор
Проблема: Составной объект, например, список, должен предоставлять доступ к своим элементам (объектам), не раскрывая их внутреннюю структуру, причем перебирать список требуется по-разному в зависимости от задачи.
Решение: Создается класс "Итератор", который определяет интерфейс для доступа и перебора элементов, "КонкретныйИтератор" реализует интерфейс класса "Итератор" и следит за текущей позицией при обходе "Агрегата". "Агрегат" определяет интерфейс для создания объекта - итератора. "КонкретныйАгрегат" реализует интерфейс создания итератора и возвращает экземпляр класса "КонкретныйИтератор", "КонкретныйИтератор" отслеживает текущий объект в агрегате и может вычислить следующий объект при переборе.
Преимущества: Поддерживает различные способы перебора агрегата, одновременно могут быть активны несколько переборов
Порождение – паттерн Одиночка (Singleton)
Проблема: Какой специальный класс должен создавать "Абстрактную фабрику", см. 3.3.1 и как получить к ней доступ? Необходим лишь один экземпляр специального класса, различные объекты должны обращаться к этому экземпляру через единственную точку доступа.
Решение: Создать класс и определить статический метод класса, возвращающий этот единственный объект.
Рекомендации: Разумнее создавать именно статический экземпляр специального класса, а не объявить требуемые методы статическими, поскольку при использовании методов экземпляра можно применить механизм наследования и создавать подклассы. Статические методы в языках программирования не полиморфны и не допускают перекрытия в производных классах.
Решение на основе создания экземпляра является более гибким, поскольку впоследствии может потребоваться уже не единственный экземпляр объекта, а несколько.