1.12 Анализ и проектирование

Объектно-ориентированные паттерны представляют собой совершенно новое и совершенно другое подход к программированию, поэтому многие люди впервые сталкиваются с трудностями при попытках понять, как правильно организовать проект. На самом деле, мы можем создать "эффективный" дизайн, который полностью использует все преимущества объектно-ориентированного программирования.Книги по анализу и проектированию объектно-ориентированных систем обычно недостаточно хороши. Большинство этих книг полны нелогичных заявлений, запутанного изложения и множества важных на вид, но часто бессмысленных утверждений (примечание 9). Я считаю, что такие книги лучше всего ограничить одной главой или максимум одним коротким томом. Железная ирония заключается в том, что те, кто особенно сосредоточены на управлении сложностью, зачастую затрачивают много усилий на написание простых и доступных книг! Если вы не можете объяснить просто и прямо, то мало кто будет читать это. В конце концов, цель объектно-ориентированного программирования — сделать процесс разработки программного обеспечения более легким. Хотя это может повлиять на жизнь тех, кто любит решать сложные проблемы, почему бы сразу же не сделать всё проще? Поэтому я надеюсь, что смогу начать с хорошей основы и максимально ясно объяснить вопросы анализа и проектирования уже в нескольких абзацах.Примечание 9: Лучшей книгой для начинающих остаётся "Object-Oriented Analysis and Design with Applications", второе издание Гради Буча, опубликованное Wiley & Sons в 1996 году. Эта книга глубока и легко воспринимаема, хотя его методика обозначений кажется излишне сложной для большинства дизайнов.

1.12.1 Не теряйтесь

На протяжении всего процесса разработки самое важное — не потеряться! Однако это случается довольно легко. Большинство методик предназначены для решения самых широких задач. Конечно, существуют также особо сложные проекты, требующие от автора значительных усилий или больших затрат. Но большинство проектов являются относительно "обычными", так что успешный анализ и проектирование возможны, а также использование лишь части рекомендованного набора методик. Независимо от того, насколько ограничен этот набор, некоторые формы обработки всегда полезны, поскольку они делают разработку всего проекта более простой, чем прямое начало кодирования!

Иными словами, если вы исследуете конкретный метод, содержащий множество деталей и рекомендующий множество шагов и документов, вам всё равно будет сложно точно определить момент завершения. Проявите осмотрительность и обратите внимание на следующее: Что такое объект? (Как разделить свой проект на серию отдельных компонентов?)Каковы их интерфейсы? (Какие сообщения следует отправлять каждому объекту?)

После того как вы определили объекты и их интерфейсы, можно приступить к написанию программы. Из-за различных причин может потребоваться больше объяснений и документов, но необходимую информацию точно нельзя сделать меньше.

Процесс делится на четыре этапа, начальный этап 0 только начинается использовать некоторые формы структурирования.

1.12.2 Этап 0: Разработка плана

Первый шаг — это решение о том, какие шаги будут приняты в процессе. Это кажется простым (на самом деле всё здесь кажется простым), но довольно часто люди даже не доходят до этапа 1, а сразу начинают писать код. Если ваш план состоит из "начала написания кода", то это тоже допустимо (если вы хорошо понимаете проблему, которую решаете). Но хотя бы согласитесь с тем, что вам нужен план.На этом этапе могут потребоваться решения относительно некоторых дополнительных структур. Однако очень неблагоприятной является ситуация, когда программисты пишут код так, словно "когда придет время, всё само собой завершится". В начале это может казаться безобидным, но я считаю, что наличие нескольких контрольных точек или "маркёров" поможет сосредоточиться. Это лучше, чем просто работать ради работы. По крайней мере, достигнув одну за другой цели и пройдя через один маркер за другим, вы сможете четко видеть своё продвижение, что повысит вашу мотивацию и избавит вас от чувства бесконечности.С тех пор как я начал учиться структурам рассказов (я надеюсь однажды написать роман), я всегда следовал этому подходу, который позволяет мне просто позволять словам "течь" на бумагу. Когда я пишу о компьютерах, я обнаруживаю, что структура намного проще, поэтому мне не нужно много думать об этом. Но я всё равно создаю структуру всего своего написания, чтобы иметь представление о том, что я пишу. Поэтому, даже если ваш план заключается в немедленном начале написания программы, вам всё равно придётся пройти через эти этапы и задать себе конкретные вопросы. ## 1.12.3 Этап 1: Что мы должны создать?В предыдущих версиях программной разработки (так называемое "процедурное или процедурное проектирование"), этот этап назывался "формирование требований и спецификаций системы". Конечно, многие из этих операций сегодня уже не нужны, либо они изменили свою форму. Обширные болезненные документы стали историей. Однако их первоначальная цель была благой. Анализ требований означает "создание набора правил, согласно которым можно определить, когда задача выполнена и как клиент может быть удовлетворен". Спецификация системы представляет собой "набор конкретных указаний, позволяющих понять, что программа должна делать (а не как это сделать) для удовлетворения требований". Анализ требований фактически является контрактом между вами и вашим клиентом (даже если клиент находится внутри компании или является другим объектом или системой). Спецификация системы представляет собой самую высокую степень представления проблемы, которую мы используем для определения завершения задачи и времени, необходимого для её выполнения. Поскольку все эти аспекты требуют согласования со всеми участниками, я рекомендую максимально упрощать их — лучше всего использовать списки и базовые диаграммы — чтобы сэкономить время. Возможно, вам придётся расширить некоторые из этих ограничений до более крупных документов.Особое внимание следует сосредоточить на ключевых вопросах этого этапа, а не углубляться в мелкие детали. Ключевой вопрос заключается в выборе системы. Наиболее ценным инструментом здесь является набор условий использования, известный как "terms of use". Для вопросов в форме "что бы система сделала, если... ", этот подход предоставляет наиболее убедительный ответ. Например, "если клиент хочет снять чек на сумму больше доступной наличности, то как должна отреагировать банкомат?" В этом случае "условия использования" указывают правильное поведение банкомата при таких условиях.Необходимо стремиться создать полный набор "условий использования" или "сценариев применения" для своей системы. После завершения этой работы вы получите четкое представление о ключевых задачах вашей системы. Концентрация на "условиях использования" позволяет сконцентрироваться на самом важном и избежать отвлечения на второстепенные вопросы. То есть, имея полный набор "условий использования", можно сделать четкий вывод о том, что система должна делать, и перейти к следующему этапу. На этом этапе возможно, что все возможные условия использования системы еще не будут полностью поняты, но это не проблема. Все недостающие моменты проявятся со временем. Не стоит слишком беспокоиться о совершенстве спецификаций системы, так как это может вызвать чувство разочарования и стресс.На данном этапе лучше всего использовать несколько простых абзацев для описания своей системы, а затем расширять описание, добавляя "сущности" и "действия". "Сущности" естественно становятся объектами, а "действия" — методами, которые должны быть интегрированы в интерфейсы этих объектов. Просто попробуйте выполнить эти шаги, и вы поймёте, насколько полезным может быть такой подход; иногда он помогает решить большую часть задач. Хотя проект ещё находится в начальной стадии, некоторые аспекты планирования могут уже оказаться полезными. На данном этапе мы должны иметь достаточно чёткое представление о том, что собираемся создать, поэтому можем уже приближённо оценить, сколько времени это займет. В этот момент следует учитывать множество факторов: если сроки кажутся слишком длительными, компания может решить прекратить проект; либо менеджеры уже сделали свои расчёты и попытаются повлиять на вашу оценку. Однако лучше всего с самого начала составить "честное" расписание, отложив принятие некоторых труднодостижимых решений до более позднего времени.Существуют различные методики, которые помогают рассчитать точные сроки выполнения задач (так же как прогнозирование колебаний фондового рынка), но обычно лучшим подходом является использование своего опыта и интуиции (не забывайте, что интуиция также основана на опыте). Определите примерное время, которое потребуется для завершения проекта, затем удвойте это время и добавьте 10%. Ваша первоначальная оценка может быть верной; возможно, вы сможете завершить проект именно за то время, которое вы оценили. Но удвоение этого времени обеспечивает некоторую гибкость, а дополнительные 10% предназначены для окончательной доработки и улучшения качества работы.

При этом важно правильно объяснить эту стратегию руководству, независимо от того, какие жалобы или изменения они могут предложить. Убедитесь, что вы четко сообщили им: это лишь моя оценка!

1.12.4 Этап 2: Как строить?На данном этапе необходимо разработать набор паттернов проектирования и объяснить, как выглядят различные объекты в рамках этих паттернов и как они взаимодействуют друг с другом. В этот момент можно использовать специальный графический инструмент — "унифицированный язык моделирования" (Unified Modeling Language, UML). Для скачивания спецификаций UML посетите сайт http://www.rational.com. Как инструмент описания на первом этапе, UML также может оказаться полезным. Кроме того, его можно использовать на втором этапе для создания некоторых диаграмм (например, схем процессов). Конечно, использование UML не является обязательным, но он может значительно помочь, особенно если вам требуется создать подробную диаграмму для совместной работы большой группы людей. В дополнение к UML, можно выбрать методическое описание объектов и их интерфейсов (как это было сделано мной в книге "Thinking in C++"), однако такой подход очень примитивен и ограничен.У меня был успешный опыт консалтинга, когда группа начинающих дизайнеров работала над первым проектом ООП (объектно-ориентированного программирования). Они никогда ранее не строили такие проекты и рисовали объекты на досках. Мы обсуждали, как эти объекты будут взаимодействовать друг с другом (общаться) и удаляли некоторые из них, заменяя другими. Эта группа (которая знала цели проекта) фактически разработала паттерны проектирования; они сами "владеют" своим дизайном, а не просто позволяют ему возникнуть естественным образом. Я выполнял роль руководителя, задавал правильные вопросы, делал предположения и получал обратную связь от группы для корректировки своих предположений. Самое прекрасное в этом процессе заключается в том, что вся группа не училась объектно-ориентированному проектированию через анализ абстрактных примеров, а практиковала реальное проектирование своего текущего проекта, тем самым осваивая основы ООП.

После того как были даны описания объектов и их интерфейсов, второй этап считается завершенным. Разумеется, эта работа может быть неполной. Некоторые детали могут стать известны только после перехода к третьему этапу. Однако этого достаточно. На самом деле нам важно найти все объекты. Чем раньше мы найдем их, тем лучше, но структура ООП такова, что даже если мы найдем их позже, это не будет проблемой.## 1.12.5 Шаг 3: Начало создания книги

Книги могут читать программисты, и вот вы достигли того момента, который может быть особенно интересен для вас. Поскольку у вас есть план — независимо от его простоты, а также правильная структура дизайна до начала написания кода, вы обнаружите, что дальнейшая работа будет намного проще, чем если бы вы сразу принялись за программирование. Это именно то, чего мы хотели достичь. Делайте так, чтобы код выполнял те задачи, которые вы хотите решить; это конечная цель всех проектов программирования. Однако не спешите и не торопитесь, иначе вы можете получить противоположный эффект. По моему опыту, лучше сначала создать более полное решение, которое будет максимально детализировано и удовлетворяет максимальному количеству требований. Мне кажется, что программирование больше похоже на искусство, а не просто на техническую работу. Все ваши усилия в конце концов будут вознаграждены. Как истинному программисту, эта способность не должна быть воспринята как второстепенная. Полное планирование, тщательная подготовка и хорошая структура не только делают программу легче для создания и отладки, но и делают её легче понять и поддерживать, что является необходимым условием для прибыльности любого программного обеспечения.После того как система была построена и запущена, её следует протестировать на практике, используя ранее проведённый анализ требований и спецификацию системы. Пройдитесь по своему коду, проверьте, что все требования были выполнены. Теперь всё должно закончиться?

1.12.6 Фаза 4: Поддержка

На самом деле, полный цикл разработки ещё не завершён, и мы переходим к тому этапу, который традиционно называют "поддержкой". Название "поддержка" довольно двусмысленно и может использоваться для обозначения различных аспектов работы — от "сохранения его в соответствии с первоначальным планом", до "добавления функциональностей, которые клиент забыл указать ранее" или более традиционной "устранения всех выявленных ошибок". Из-за этого термин вызывает много недоразумений, некоторые люди считают, что все, что требует "поддержки", должно быть неполным или дефектным! Это слово подразумевает, что вы создали очень "сырой" продукт, который потребует множества последующих изменений, добавлений нового кода или защиты от устаревания.Поэтому нам следует использовать более подходящее название для этой фазы — "корректура". Другими словами, "первый вариант вашего проекта не является окончательным, поэтому вам стоит оставить себе пространство для дальнейшего обучения и понимания, чтобы вернуться и сделать необходимые изменения". По мере углубления знаний о решаемых проблемах могут потребоваться значительные изменения. Одним из побуждающих факторов к этим работам является то, что со временем ваши усилия начнут приносить плоды, будь то через короткий или долгий период времени.Когда же можно говорить о достижении идеального состояния? Это не просто о том, чтобы программа работала так, как требуется, и адаптировалась ко всем заданным условиям использования. Это также означает, что внутренняя структура кода должна быть совершенной. Во всяком случае, она должна хорошо согласованно функционировать без излишних конструкций или лишнего веса. Кроме того, важно обеспечить жизнеспособность структуры программы. Поскольку множество причин требуют обязательных изменений в будущем, эти изменения должны быть удобными и очевидными. Здесь нет места для сложностей. Важно не только понимание того, что вы создали, но и осознание того, как ваша программа постоянно эволюционирует. К счастью, объектно-ориентированные языки программирования особенно подходят для таких последовательных изменений — границы, установленные объектами, эффективно поддерживают целостность структуры и защищают её от бесполезных воздействий на нерелевантные объекты. Можно также делать значительные изменения в своём коде, не нарушая его целостности и не затрагивая остальную часть программы. Таким образом, поддержка корректуры является одним из важнейших преимуществ ООП. Проверка позволяет создать что-то хотя бы приближающееся к вашему первоначальному видению.Затем вы можете рассмотреть свое произведение в целом, сравнить его с вашими требованиями и понять, чего вам недостает. После этого вы сможете спокойно вернуться назад и переоценить неправильные части программы (Примечание 10). Возможно, потребуется решить несколько проблем, которые нельзя игнорировать, или хотя бы одну из их сторон, прежде чем вы получите правильное решение. Обычно требуется несколько повторных проверок (в этом случае паттерны проектирования могут оказаться полезными; см. главу 16).Проверка практически неизбежна при создании системы. Вам нужно постоянно сравнивать свои требования с тем, что вы действительно хотите получить. Иногда только после того, как вы увидите систему, вы осознаете, что вам следует решить другую задачу. Если вы признаете необходимость такой проверки, лучше всего начать с первого прототипа как можно скорее, чтобы проверить, соответствует ли он вашим ожиданиям, и развивать ваши идеи.Итерационная проверка тесно связана с поэтапной разработкой. Поэтапная разработка означает начало работы над основой системы, её реализацию как фреймворк, а затем постепенное добавление остальных частей системы на основе этого фреймворка. Затем различные функции (функциональные возможности) постепенно добавляются одна за другой. Самое сложное здесь — это создание фреймворка, который легко расширяется для всех требуемых функциональных возможностей (обсуждение этой проблемы см. в главе 16). Преимуществом такого подхода является то, что каждая последующая функциональная возможность может рассматриваться как отдельный проект внутри основного проекта. Кроме того, новые функции, возникающие во время разработки или обслуживания, могут быть легче добавлены. ООП поддерживает поэтапную разработку благодаря тому, что если программа правильно спроектирована, каждый этап может быть представлен как полноценный объект или группа объектов.Примечание 10: Это немного похоже на "быстрый прототип". Здесь важно создать простой и понятный вариант, чтобы иметь четкое представление о системе. Затем этот прототип можно отбросить и официально создать систему. Наиболее трудная ситуация при использовании быстрого прототипа заключается в том, что люди не отбрасывают прототип, а продолжают строить на его основе. Если к этому добавить отсутствие структурированного подхода в программировании, это может привести к хаотичной системе, увеличивая стоимость её поддержки.

1.12.7 Планирование как ключ к успехуБез тщательно подготовленного чертежа, конечно же, невозможно построить дом. Если строится будка для собаки, хотя бы минимальные эскизы всё равно необходимы, чтобы иметь представление о том, что вы делаете. Однако в случае с разработкой программного обеспечения всё совсем иначе — её "чертёж" (план) должен быть детализирован и полон подробностей. В течение долгого времени люди проводили свои разработки практически без какой-либо структуризации, но большие проекты часто заканчивались провалами. Через многочисленные попытки были найдены множество структур и детальных данных, однако использование этих методов вызывало опасение — казалось, что большую часть времени приходилось уделять написанию документов вместо написания кода (что было довольно распространено). Надеюсь, что то, что я здесь рассказываю, предоставляет альтернативный подход. Вам следует выбрать метод, который лучше всего подходит вашим потребностям (и привычкам). Даже самый небольшой план будет значительно улучшать ваш проект по сравнению с отсутствием планирования вообще. Помните: согласно оценкам, более 50% проектов без планирования завершаются неудачей!