И карты CRC используются для записи, упорядочивания и улучшения компонентов в дизайне.
Карта CRC состоит из трех разделов.
В верхней части карты есть имя класса.
Слева обязанности класса, а справа список коллабораторов.
Коллабораторы это другие классы, с которыми класс взаимодействует, чтобы выполнять свои обязанности.
Чтобы отслеживать каждый компонент и его обязанности с помощью CRC-карты, вы помещаете имя компонента в раздел имени класса и обязанности в разделе обязанностей.
До сих пор это довольно просто.
Но как насчет связей?
В разделе «Коллабораторы» вы перечисляете другие компоненты, к которым ваш текущий компонент подключается или взаимодействует, чтобы выполнять свои обязанности.
И карты CRC сами по себе небольшие, поэтому вы не можете много писать в них.
Это заставляет вас продолжать разбивать каждый компонент на более мелкие компоненты и, в конечном итоге, классы, которые достаточно малы для индивидуального описания.
Теперь, когда мы узнали о CRC-картах, давайте использовать их для разработки нашей банковской системы.
Начнем с базового пользовательского компонента.
В этом примере нашим основным пользователем будет клиент банка.
Мы размещаем клиентов банка в разделе имени класса.
Обязанности банковского клиента включают ввод банковской карточки или выбор операции, такой как депозит, снятие или проверка остатка на счете.
Перечислим их в разделе ответственности CRC-карты.
И мы поместим банкомат в разделе Коллабораторы.
Тоже самое мы можем сделать для банкомата.
И с нашими картами CRC мы можем объединить вместе компоненты для совместной работы.
Например, положите карту клиента CRC слева и карточку CRC банкомата справа.
Когда карты CRC организованы, вы можете имитировать прототип системы.
Теперь, вы можете заметь, что сам банкомат содержит несколько разных компонентов, которые могут быть отдельными классами для программирования.
Например, есть кард-ридер, клавиатура, дисплей и так далее.
Каждый из этих классов, их обязанности и коллабораторы могут быть описаны на их собственных картах.
При встрече с командой разработчиков программного обеспечения вы можете разложить все карты на столе и обсуждать моделирование того, как эти классы работают с другими классами для выполнения своих обязанностей.
И эти симуляции могут выявлять недостатки в дизайне, и вы можете экспериментировать с альтернативами, вводя соответствующие карты.
Вопросы
Вопрос 1
Что из следующего является желательными характеристиками дизайна программного обеспечения?
Тесная связь
Ремонтопригодность +
Повторное использование +
Гибкость +
Вопрос 2
Определите два результата процесса проектирования.
Концептуальный дизайн +
Реализация кода
Технический дизайн +
План проектирования
Вопрос 3
Вы пишете CRC-карту для компонента банкомата. В каком разделе вы должны поместить «Отслеживание оставшихся денежных средств».
Риски
Класс
Коллабораторы
Обязанности +
Вопрос 4
Что из этого, вероятно, будет частью концептуального дизайна?
Карты CRC +
Абстрактные типы данных
Методы
Макеты +
Вопрос 5
Когда в процессе проектирования вы, скорее всего, будете создавать карты CRC?
Встречи с клиентами
Концептуальный дизайн +
После выпуска программного обеспечения
Технический дизайн
Вопрос 6
Что из следующего является примером нефункциональных требований?
Производительность +
Доступность +
Предназначение
Безопасность +
Вопрос 7
Выберите категории объектов, которые обычно присутствуют в объектно-ориентированном программном обеспечении.
Entity +
Boundary +
tool
Сontrol +
Вопрос 8
Объект, который отвечает за отображение данных пользователю, может быть рассмотрен в какой категории объекта?
representation
boundary +
entity
control
Вопрос 9
Вы планируете класс профессора как часть своего программного обеспечения. Что из следующего вы считаете collaborator?
Отслеживать статус работника
Курс
Студент +
Учебный курс +
Вопрос 10
Что является способом выражения требования в этой форме? «Как ____, я хочу ____, так что ____».
Курс
Студент +
Учебный курс +
Вопрос 10
Что является способом выражения требования в этой форме? «Как ____, я хочу ____, так что ____».
История пользователя +
Концептуальный макет
Абстракция объекта
Ключевое понятие
Задание
Как только возникает требование, оно должно быть выражено в той или иной форме.
Один из способов выражения требования называется историей пользователя.
Пользовательская история это просто требование, часто с точки зрения конечного пользователя, которое указано на естественном языке.
История пользователя выглядит так:
Как ______, я хочу ______, чтобы ______.
Поместите роль пользователя в первый пробел.
Во втором пробеле укажите цель, которую должна достичь пользовательская роль.
Это приведет к некоторой функции, которую вы хотите реализовать.
После этого укажите причину, по которой пользовательская роль хочет эту цель.
После заполнения пользовательской истории вы можете применить объектно-ориентированное мышление к ней, чтобы обнаружить объекты и, возможно, дополнительные требования!
Вопрос 11
Вы программист, создающий программное обеспечение для банкомата. В какой раздел CRC-карты для компонента банкомата будет включен «Пользователь»?
Коллабораторы +
Обязанности
Объект
Класс
Вопрос 12
Во время концептуального дизайна вы будете говорить о :
Компромиссах +
Требованиях +
Технических диаграммах
Макетах +
Основные понятия
Объектно-ориентированный подход зародился в программировании в середине прошлого века.
Первым объектно-ориентированным языком был Simula (Simulation of real systems моделирование реальных систем), разработанный в 1960 году исследователями Норвежского вычислительного центра.
В 1970 году Алан Кей и его исследовательская группа в Xerox PARK создали персональный компьютер Dynabook и первый чистый объектно-ориентированный язык программирования Smalltalk для программирования Dynabook.
В 1980-х годах Грэди Буч опубликовал документ под названием «Объектно-ориентированный дизайн», в котором в основном был представлен дизайн для языка программирования Ada. В последующих изданиях он расширил свои идеи до полного объектно-ориентированного метода проектирования.
В 1990-х годах Coad включил поведенческие идеи в объектно-ориентированные методы.
Другими значительными нововведениями были методы моделирования объектов Object Modelling Techniques (OMT) Джеймса Рамбо и объектно-ориентированная программная инженерия Object-Oriented Software Engineering (OOSE) Ивара Джекобсона.
С появлением первых компьютеров появились языки программирования низкого уровня.
Языки программирования, ориентированные на конкретный тип процессора, и, операторы которых были близки к машинному коду.
Дальнейшая эволюция языков программирования привела к появлению языков высокого уровня, что позволило отвлечься от системы команд конкретного типа процессора.
При этом происходило смещение от программирования деталей к программированию компонентов, развитие инструментов программирования и возрастание сложности программных систем.
Также развивался подход или стиль написания программ.
В начале использовалось процеду́рное программи́рование, при котором последовательно выполняемые операторы собирались в подпрограммы.
При этом данные и процедуры для их обработки формально не были связаны.
Как следствие возрастания сложности программного обеспечения появилось структу́рное программи́рование методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков.
И наконец появилось объектно-ориентированное программирование методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования.
Событи́йно-ориенти́рованное программи́рование парадигма программирования, в которой выполнение программы определяется событиями действиями пользователя, сообщениями других программ и потоков, и событиями операционной системы.
Компонентно-ориентированное программирование парадигма программирования, опирающаяся на понятие компонента независимого модуля исходного кода программы, предназначенного для повторного использования и развёртывания, и реализующегося в виде множества языковых конструкций.