- •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
24. Обязанности объектов. Разложение системы на объекты. Crc-карты.
Обязанностями объекта называются атрибуты, объектные связи и методы. При этом объектная связь представляет собой обязанность знать другой объект; атрибут – обязанность знания чего-либо; метод – обязанность выполнения (кого я знаю? что я знаю? что я делаю?). Каждый объект в системе имеет уникальное имя, необязательно понятное человеку; каждая обязанность внутри объекта также имеет уникальное имя.
Самая трудная задача в объектно-ориентированной методологии (ООМ) – правильно разложить систему на объекты и классы. Рекомендуется определять объекты по кругу выполняемых ими обязанностей.
CRC-карточки (Class-responsibility-collaboration card) – метод мозгового штурма, предназначенный для проектирования объектно-ориентированного программного обеспечения. CRC-карты были предложены Уордом Каннингемом и Кентом Беком. Как правило, CRC-карты используются в тех случаях, когда сначала в процессе проектирования ПО определяются классы и способы их взаимодействий.
Вверху карточки пишется название класса, в левой половине – за что он отвечает, в правой – с кем сотрудничает. Проходя по техническому заданию или любому другому документу описывающему задачу, на каждую нужную сущность заводиться класс, имя которого записывается в шапке карточки.
Слева в карточке записывается ответственность класса – что класс должен делать? Выделенные ответственности будут в будущем методами класса. После анализа ответственности класса, возможно, часть ответственностей с одного большого класса передадутся другому классу, или выделятся новые, более детальные классы.
Часто существительные технического задания выделяют в классы, а глаголы в ответственности класса.
Справа карточки отмечается связи класса – что другие классы делают при взаимодействии с ними? Связи определяет область сотрудничества этого класса. Карточки можно раскладывать так, чтобы представить формы сотрудничества объектов.
С точки зрения динамики моделируемой задачи, расположение карточек показывает поток сообщений между объектами, с точки зрения статики они представляют иерархии классов.
Для этого метода анализа есть специальные бумажные карточки, размера 3х5, иногда разноцветные – для большей наглядности.
Имя класса |
|
Ответственность |
Взаимодействие |
Пример карточки
25. Инкапсуляция. Связность внутри классов и зацепление между классами.
В языках программирования инкапсуляция имеет одно из следующих значений, либо их комбинацию:
языковой механизм ограничения доступа к определённым компонентам объекта;
языковая конструкция, способствующая объединению данных с методами (или другими функциями), обрабатывающими этими данные.
Инкапсуляция — один из четырёх важнейших механизмов объектно-ориентированного программирования (наряду с абстракцией, полиморфизмом и наследованием).
В то же время, в языках поддерживающих замыкания, инкапсуляция рассматривается как понятие не присущее исключительно объектно-ориентированному программированию. Также, реализации абстрактных типов данных (например, модули) предлагают схожую модель инкапсуляции.
Инкапсуляция (encapsulation) - это механизм, который объединяет данные и код, манипулирующий этими данными, а также защищает и то, и другое от внешнего вмешательства или неправильного использования.
Зацепление – это степень глубины связей между отдельными модулями, классами и объектами. Систему с сильной зависимостью между модулями гораздо сложнее воспринимать и модифицировать. Сложность системы может быть уменьшена путем уменьшения зацепления между отдельными модулями. Существует определенное противоречие между явлениями зацепления и наследования. С одной стороны, желательно избегать сильного зацепления классов; с другой стороны, механизм наследования, тесно связывающий подклассы с суперклассами, помогает выгодно использовать сходство абстракций.
Связность – это степень взаимодействия между элементами отдельного модуля, класса или объекта, характеристика его насыщенности. Наименее желательной является связность по случайному принципу, когда в одном классе или модуле собираются совершенно независимые абстракции. Наиболее желательной является функциональная связность, при которой все элементы класса или модуля тесно взаимодействуют в достижении определенной цели.