обеспечение, могут включать в себя повторное использование, гибкость и ремонтопригодность.
По мере того, как дизайн детализируется и создается реализация, требуемое качество должно проверяться с помощью таких методов, как пересмотры и тесты.
Кроме того, некоторые качества могут быть проверены с помощью обратной связью конечных пользователей.
При разработке программного обеспечения отправной точкой является то, что ваша программная структура должна соответствовать балансу желаемых качеств.
В частности, существует общий компромисс между производительностью и ремонтопригодностью.
Высокопроизводительный код может быть менее понятным и менее модульным, что делает его менее удобным.
Другим компромиссом является безопасность и производительность.
И дополнительные накладные расходы для высокой безопасности могут снизить производительность. И также дополнительный код для обратной совместимости может ухудшить производительность и ремонтопригодность.
При планировании какого-либо выступления часто используются карточки заметок.
Карточки заметок помогают вам двигаться логически из одной точки разговора в другую.
Было бы неплохо, если бы у нас было что-то похожее, чтобы логически составлять структуру программного обеспечения при формировании его дизайна.
Вы определяете компоненты, соединения и обязанности по некоторым требованиям при формировании концептуального дизайна. Здесь вы формируете свои первоначальные мысли о том, как вы можете удовлетворить требования.
В техническом дизайне эти компоненты и соединения дополнительно уточняются, чтобы придать им технические детали. Это упрощает их реализацию.
Хотя идентификация компонентов, их обязанностей и связей является хорошим первым шагом в разработке программного обеспечения, мы пока не продемонстрировали способ их представления.
И такой метод есть – это использование карточек CRC, где CRC обозначает класс, ответственность, сотрудничество.
Карты CRC помогают организовывать компоненты в классы, определять их обязанности и определять, как они будут сотрудничать друг с другом.
Рассмотрим, например, банкомат.
Вы вставляете свою банковскую карточку в банкомат, и банкомат просит вас ввести PIN-код, удостоверяющий личность для доступа.
После этого вы можете выбрать положить или снять деньги, или проверить свои остатки.
Этот сценарий определяет основные требования к системе.
Это неполный набор требований, но это хороший старт.
Помните, что требования часто являются неполными и дополняются при дальнейшем взаимодействии с вашим клиентом и конечными пользователями.
Следующим шагом будет разработка банкомата.
Но так как мы формируем концептуальный дизайн, ограничиваясь
