Страница 2 из 10
Рассмотрим следующий сценарий.
Вас наняли, чтобы спроектировать дом.
Прежде чем приступить к закладке фундамента, вы должны сначала понять, чего хочет домовладелец.
Эта отправная точка известна как выявление требований.
Домовладелец хочет иметь тренажерный зал, санузел, три спальни и гостиную.
Выявление требований подразумевает не только выслушивание того, что говорит вам клиент, но и задавание вопросов для выяснения того, что клиент вам не сказал.
Например, это показалось вам странным, что в этом доме нет кухни?
Это было бы естественным вопросом.
Или все комнаты должны быть одинакового размера?
Насколько большой должен быть дом в целом?
И так далее.
После ответа на эти вопросы у вас теперь есть первоначальный набор требований, позволяющий начать думать о возможных проектах.
Проектная деятельность предполагает принятие требований и определение решения.
Эта деятельность включает в себя создание концептуального дизайна, а затем технического дизайна, что приводит к двум соответствующим видам артефактов, концептуальным макетам и техническим схемам.
Концептуальные макеты представляют то, как будут удовлетворены требования в целом.
На этом этапе вы фокусируетесь на дизайне дома, определяя основные компоненты и их соединения и откладывая технические детали.
И чем яснее концептуальный дизайн, тем лучше будут технические проекты.
После того, как концептуальные макеты завершены, настало время определить технические детали решения.
Из концептуального дизайна вы знаете все основные компоненты и их соединения и обязанности компонентов.
Описание того, как выполняются эти обязанности, является целью технического проектирования.
В техническом дизайне вы начинаете указывать технические детали каждого компонента.
Это делается путем разделения компонентов на более мелкие компоненты, которые достаточно специфичны для детального проектирования.
Например, компонент тренажерного зала потребует дополнительных компонентов, таких как пол.
Пол будет отвечать за поддержание большого веса.
Домовладелец тренируется как олимпийский атлет.
Разбивая компоненты все больше и больше на дополнительные компоненты, каждый из которых несет определенные обязанности, вы доходите до уровня, где вы можете сделать детальный дизайн конкретного компонента, например, описать, как укрепить пол.
Технические диаграммы выражают, как решать конкретные проблемы, подобные этой.
И при создании приемлемого решения могут возникнуть компромиссы.
Что делать, если укрепление пола в спортзале требует помещения колонн или балок в подвал под тренажерный зал?
И что, если домовладелец также хочет иметь широкое открытое пространство в подвале с хорошей комнатой отдыха?
Иногда могут возникать такие конфликты.
Вам и домовладельцу необходимо будет выработать компромисс в решении.
Если компоненты, их соединения и их обязанности в вашем концептуальном дизайне оказались невозможными в техническом дизайне, или не в состоянии удовлетворить требованиям, вам нужно будет вернуться к вашему концептуальному дизайну и переделать его.
Затем технические диаграммы становятся основой для построения предполагаемого решения.
Компоненты, когда они достаточно проработаны, превращаются в коллекции функций, классов или других компонентов.
Эти части представляют собой гораздо более простую проблему, которую разработчики могут реализовывать индивидуально.
Когда вы разделяете объекты на более мелкие объекты, вы можете обнаружить, что вы будете идентифицировать разные типы объектов.
И обычно определяют три категории объектов.
Во-первых, это Entity объекты.
Entity объекты наиболее знакомы, потому что они соответствуют некоторому реальному объекту.
Если у вас есть объект, представляющий стул в вашем программном обеспечении, то это Entity объект.
Если у вас есть объект, представляющий здание или клиента, это все Entity объекты или сущности.
Как правило, эти объекты знают свои атрибуты.
Они также смогут модифицировать себя и иметь для этого некоторые правила.
Когда вы идентифицируете объекты для включения в ваше программное обеспечение и разбиваете эти объекты на более мелкие объекты, вы сначала получаете Entity объекты.
Другие категории объектов приходят позже, когда вы начнете думать о техническом дизайне программного обеспечения.
Далее, это Boundary объекты.
Граничные объекты Boundary – это объекты, которые находятся на границе между системами.
Это может быть объект, который соприкасается с другой программной системой, например, объект, который получает информацию из Интернета.
Он также может быть объектом, который несет ответственность за отображение информации пользователю и получение его ввода.
Если вы программируете пользовательский интерфейс – визуальный аспект программного обеспечения – вы, в основном, работаете с граничными объектами.
Любой объект, который имеет дело с другой системой – пользователем, другой программной системой, Интернетом, – можно считать граничным объектом.
Далее, это объекты управления Control.
Control объектами являются объекты, которые отвечают за координацию.
Вы обнаружите объекты управления при попытке деления большого объекта и обнаружите, что было бы полезно иметь объект, который управляет другими объектами.
Организация программного обеспечения с помощью объектов сущностей, граничных объектов и объектов управления позволяет коду быть более гибким, многоразовым и поддерживаемым.
Для программного обеспечения существуют два типа требований.
Это функциональные требования, которые описывают, что система или приложение должны делать.
Например, мультимедийное приложение имеет функциональное требование о возможности загрузки полноразмерного фильма.
Естественно, что разработка программного обеспечения должна четко определять решение для удовлетворения таких требований.
Кроме функциональных требований, есть также нефункциональные требования, которые определяют, насколько хорошо система или приложение делают то, что она делает.
Такие требования могут описывать, насколько хорошо программное обеспечение работает в определенных ситуациях.
Например, мультимедийное приложение может иметь нефункциональные требования для загрузки полноразмерного фильма с определенной скоростью и для воспроизведения такого фильма в пределах определенного размера памяти.
И для решения важны как функциональные, так и нефункциональные требования.
Другой тип нефункциональных требований касается того, насколько хорошо может развиваться код программного обеспечения.
Например, части реализации, возможно, придется поддерживать использование в других подобных программных продуктах.
Кроме того, реализация может потребовать изменения в будущем.
Таким образом, другие качества, которым должно удовлетворять программное обеспечение, могут включать в себя повторное использование, гибкость и ремонтопригодность.
По мере того, как дизайн детализируется и создается реализация, требуемое качество должно проверяться с помощью таких методов, как пересмотры и тесты.
Кроме того, некоторые качества могут быть проверены с помощью обратной связью конечных пользователей.
При разработке программного обеспечения отправной точкой является то, что ваша программная структура должна соответствовать балансу желаемых качеств.
В частности, существует общий компромисс между производительностью и ремонтопригодностью.
Высокопроизводительный код может быть менее понятным и менее модульным, что делает его менее удобным.
Другим компромиссом является безопасность и производительность.
И дополнительные накладные расходы для высокой безопасности могут снизить производительность. И также дополнительный код для обратной совместимости может ухудшить производительность и ремонтопригодность.