Responsibility-Driven-Design (RDD) Проектирование на основе обязанностей Борисоглебский индустриальный техникум 2204 «Техобслуживание СВТ и КС» Объектно-ориентированное программирование
1. Определение обязанностей и поведения системы На первом этапе определяется поведение системы, ее обязанности и спектр задач решаемых с ее помощью Поведение и обязанности — это нечто, что может быть описано в момент возникновения идеи программы и (в отличие от формальной спецификации системы) выражено в терминах, имеющих значение как для программиста, так и для клиента.
1. 1 Уточнение спецификаций Заказчик уточненная спецификаци я несколько итераций представление исполнителя ( «посмотри и почувствуй» ) Все должно документироваться! Исполнитель уточнения исходная спецификация для разработки
1. 2 Определение компонент Компонента— это просто абстрактная единица, которая может выполнять определенную работу (то есть иметь определенные обязанности). На этом этапе неважно как задается компонента или как она будет выполнять свою работу Компонента I Система Компонента III
Что нужно делать? Кто будет делать? Компонента Действия приписываются компоненте в качестве ее обязанностей. Состав обязанностей выбирается с соблюдением правил: q компонента должна иметь небольшой набор четко определенных обязанностей; q компонента должна взаимодействовать с другими компонентами настолько слабо, насколько это возможно.
Средство описания компонент – CRC карта <название> <сотрудничающие компоненты> <список обязанностей компоненты> Главное меню Отображение логотипа; Вызов таблицы рекордов; Выбор уровня сложности; Запуск игры; Настройки графики; Настройки звука; Завершение работы; Ядро Таблица рекордов Хранилище конфигурации
1. 3 Анализ связей При определении структуры системы нужно добиться как можно меньшего числа связей между компонентами. Для анализа статических связей может использоваться диаграмма связей Таблица рекордов Информационная панель Главное меню Ядро Поле Хранилище конфигурации
1. 3 Анализ взаимодействия Для анализа динамического взаимодействия удобно использовать диаграммы взаимодействия Время Таблица рекордов Главное меню Информационная панель Ядро Хранилище конфигурации Поле Сохранение конф. Запуск игры. Запрос конфигурации Возврат конфигурации Передача игровой сит. Параметры хода Игровая информация Данные о выигрыше Вызов
2. 1 Подробный анализ компонент Компонента характеризуется поведением и состоянием Поведение (что делает) Компонента Состояние (данные) У компоненты может быть только поведение или только состояние
Классы Компоненты с похожим поведением описывают как один класс компонент. Класс окон Окно приложения Окно открытия документа Окно сообщения Конкретный представители класса называются экземплярами. Все экземпляры класса понимают одинаковые команды и одинаково на них реагируют
Интерфейсы компонент. Принципы Парнаса Программист знает, как использовать компоненту, разработанную другим программистом, и при этом ему нет необходимости знать, как она реализована. Подробности работы компоненты скрываются за интерфейсом. Иначе говоря инкапсулируются команда результат данные Разработчик программы или компоненты должен предоставить пользователю всю информацию, которая нужна для эффективного использования приложения, и ничего кроме этого. Разработчик программного обеспечения должен знать только требуемое поведение компоненты и ничего кроме этого.
2. 2 Формализация интерфейса Для каждой компоненты определяется будет она функцией или классом. Классом обычно становятся компоненты с несколькими функциями. Каждой обязанности дается имя. Определяются аргументы, передаваемые функциям компоненты Описываются поля с информацией в компоненте
Правила именования q Используйте имена, которые можно произнести вслух. q Применяйте заглавные буквы или символы подчеркивания для того, чтобы отметить начало нового слова в составном имени: Card. Reader или Card_reader q Тщательно проверяйте сокращения. Сокращение, ясное для одного человека, может быть загадочным для другого. q Избегайте многозначности имен. q Не используйте цифры в именах. Их легко спутать с буквами (0 как O, 1 как l, 2 как Z, 5 как S). q Присваивайте функциям, которые возвращают логические (булевские) значения, такие имена, чтобы было ясно, как интерпретировать true и false. Например, Printer. Is. Ready q Дайте дорогостоящим (с точки зрения компьютерных ресурсов) и редкоиспользуемым операциям уникальные, четко выделяемые имена.
Скачать презентацию Responsibility-Driven-Design (RDD) Проектирование на основе обязанностей Борисоглебский индустриальный
project.ppt