Введение в рубрику "Секреты проектирования"

1) Разделение системы на отдельные программы (и ее документирование)
2) Определение и документирование интерфейсов между отдельными программами
3) Выбор библиотек независимых производителей и пакетов Java, которые будут использовать ваши Java-программы, и их документирование
4) Выбор новых, созданных вами, библиотек (пакетов Java), которые будут совместно использовать различные компоненты вашей системы, и их документирование

5) Создание прототипов пользовательского интерфейса для тех компонентов системы, которые имеют какой-нибудь пользовательский интерфейс

6) Проектирование и документирование иерархий классов
7) Проектирование и документирование отдельных классов и интерфейсов

Определение системы

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

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

Создание прототипов пользовательского интерфейса

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

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

Объектно-ориентированное проектирование

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

1. Классы пользовательского интерфейса
2. Классы проблемной области
3. Классы управления данными

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

Этап 3. Реализация

Реализация - это программирование. Создание циклов, операторов захвата (catch clauses), переменных и комментариев, а также компиляция, тестирование элементов и устранение ошибок - вот что такое реализация. Это основная часть вашей работы.

Этап 4. Интеграция и тестирование

На этапе интеграции и тестирования члены группы разработчиков проекта, каждый из которых выполняет собственное задание (создает определенную часть программы) собираются вместе. Теперь они пытаются заставить все части программной системы работать совместно. Члены группы выясняют, верно ли были определены интерфейсы между отдельными компонентами системы и правильно ли они взаимодействовали на этапе ее разделения. На этапе интеграции и тестирования программирование сводится главным образом к устранению ошибок.

Документирование программных проектов

Существует множество способов проектирования программ. Прежде всего, это общепринятые методики, направляющие вас в процессе трансформации проблемной области в область решения. При проектировании Java-программ вы можете воспользоваться одной из общепринятых методик, объединить несколько таких методик или отказаться от них вообще и заниматься проектированием по своему усмотрению. Но вне зависимости от того, как именно вы решили подступиться к стадии проектирования вашей программы, вам необходимо каким-нибудь образом задокументировать проект. Документирование не только поможет вам следить за ходом проектирования, но и позволит передавать проект на рассмотрение другим разработчикам. Благодаря этому вы сможете еще до начала реализации получить от своих коллег отклики и ценные советы по поводу проекта. Важно получить эти отклики еще на ранних этапах, пока его относительно легко видоизменить. На этапе проектирования скорректировать возможные ошибки в проекте гораздо легче, чем позднее, на этапах реализации, интеграции и тестирования. (Обратите внимание: процесс получения откликов на ваш проект и внесение соответствующих изменений в него, еще раз доказывает, что разработка программ - процесс итеративный).

Во многих методиках проектирования для описания проекта предусмотрены графические обозначения. Инструменты компьютерного проектирования CASE (Сomputer Aided Software Engineering) в большинстве случаев позволяют документировать проект в процессе его подготовки. Однако при использовании Java у вас имеется и другая возможность. Язык Java позволяет без труда отобразить проект исключительно при помощи стандартных средств, являющихся частью любой среды разработки Java.

Документирование проекта при помощи кода

Самый простой способ документирования проекта состоит в том, чтобы отобразить этот проект в виде Java-кода, который имел бы структуру и организацию конечного продукта, но не обладал бы его функциональными возможностями. Для этого необходимо определить классы и интерфейсы, присвоить им имена, а затем описать их в комментариях. Кроме того необходимо определить имя и тип каждого поля и также описать их в комментариях. После этого следует определить имя, тип возврата функции, количество и типы параметров каждого метода. Однако тело метода определять не нужно. Вместо тела необходимо подготовить комментарий, в котором будет описано, как тело данного метода будет функционировать после реализации. Комментарий может представлять собой псевдокод, обыкновенное текстовое описание, или и то и другое вместе. Если вы воспользуйтесь этим способом, то в процессе проектирования ваш проект можно будет без особого труда видоизменить.

Если вы поступите таким образом, то по завершению этапа проектирования будете иметь уже достаточно значительный объем Java-кода. Вы получите основу Java-кода для каждой программы, к которой сделали прототип пользовательского интерфейса. Этот код выглядит как настоящий, но не имеет соответствующих функциональных возможностей. (Это классы пользовательского интерфейса).

Кроме того вы будете обладать основой Java-кода для каждого созданного вами класса - полями, комментариями и методами с пустыми телами. (Это классы проблемной области и управления данными).

Представление проекта с помощью javadoc

Среда программирования Java включает инструмент javadoc, который поможет вам задокументировать проект и передать его другим разработчикам. Для Java существуют три вида комментариев:

Одиночный - "//"
Пара "/*" и "*/"
Пара "/**" и "*/"

Символ "//" показывает, что оставшаяся часть строки - это комментарий. Символы "/*" и "*/" указывают, что компилятор должен игнорировать все расположенные между ними символы. Символы "/**" и "*/" действуют аналогично, однако javadoc отбирает комментарии между "/**" и "*/" и помещает их в HTML-файл, который он формирует для документирования кода.

Поэтому комментарии, которые начинаются с "/**", называются документационными комментариями или просто doc comments. javadoc анализирует файлы .java и формирует несколько HTML-файлов, которые описывают классы, поля, методы и демонстрируют документационные комментарии.

Проектирование всей системы без реализации методов позволяет документировать проект таким образом, чтобы упростить процесс реализации. К началу реализации вы уже будете располагать исходным кодом, и этот исходный код уже будет содержать достаточно качественные комментарии. Это позволит гарантировать, что создаваемые вами классы можно будет компилировать, даже несмотря на отсутствия тел методов.

Способность видоизменять код в ходе проектирования

На этапе проектирования надо стремиться к тому, чтобы сохранить возможность видоизменять программу. Представьте, что вы занимаетесь проектированием одной части программы, затем переходите к другой ее части, но вдруг обнаруживаете, что вам нужно вернуться к первой части и что-нибудь в ней изменить. Такая ситуация - не редкость. Поэтому разработчики хотели бы сохранить все части программы в "жидкой" форме, то есть иметь возможность без труда трансформировать их. Однако если вы проведете реализацию одной части программы еще до начала работы над следующей ее частью, вернуться к первой части и видоизменить ее будет уже гораздо сложнее. Чем больше написано кода, тем больше ваши затраты на разработку определенного проекта, и тем сложнее (с финансовой, технической, а также с моральной точки зрения) вернуться к началу и что-то изменить.

Если у вас имеется простой метод, и если вы реализовали его на этапе проектирования, то ничего страшного в этом нет. Никто не выгонит вас с работы (по крайней мере по этой причине). Но с реализацией методов на этапе проектирования не стоит спешить. Я рекомендую это прежде всего потому, что необходимо сохранить возможность видоизменить проект до тех пор, пока вы не продумаете все до конца. Старайтесь сохранить эту возможность до тех пор, пока не будет закончена вся работа в области решения.

Пять надоедливых обезьян

Жизнь такова, что при создании программ вам все время приходиться думать о целом ряде требований, которые нужно учитывать в процессе работы. Я называю их "обезьянами у вас на шее". Эти обезьяны постоянно спорят, потому что каждая из них старается обратить на себя ваше внимание, убедить вас, что ее проблема важнее всего. Первая здоровенная и тяжеленная обезьяна сидит у вас за спиной, обхватив вас за шею. Она то и дело вскрикивает: "Надо уложиться в срок!". Другая обезьяна взгромоздилась вам на макушку (потому что места на спине уже не осталось). Она колотит себя в грудь и вопит: "Главное - это правильно реализовать спецификацию!". Третья обезьяна подпрыгивает на компьютерном мониторе и пронзительно визжит: "Надежность! Надежность! Надежность!" Четвертая пытается вскарабкаться вам на ногу и горланит: "Не забудь о быстродействии!" Но это еще не все. Время от времени из-под клавиатуры осторожно выглядывает еще одна маленькая обезьянка. Когда это случается, все остальные обезьяны сейчас же замолкают. Тогда маленькая обезьянка медленно вылезает наружу, встает на задние лапки, и, глядя вам прямо в глаза, говорит: "Сделай так, чтобы твой код было легко читать и изменять". В этот момент остальные обезьяны с дикими криками набрасываются на маленькую обезьянку и заталкивают ее обратно под клавиатуру. После того, как она исчезает, остальные обезьяны возвращаются на свои места, и все начинается снова.

Вы сидите в кабинете, работаете над программой и думаете, кого же из них слушать? Увы, в большинстве случаев слушать приходится всех. Если вы хотите, чтобы все получилось, то придется постараться. Нужно, чтобы все обезьяны остались довольны. Другими словами, нужно найти правильный баланс между всеми этими, подчас взаимоисключающими, требованиями.

Первая обезьяна: как уложиться в срок?

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

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

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

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

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

Вторая обезьяна: правильная реализация спецификации

Чтобы ублажить вторую обезьяну, необходимо прежде всего иметь достаточно ясное, детальное представление своей конечной цели, с которым можно ознакомить всех заинтересованных лиц. Если вы не знаете, куда направляетесь, то скорее всего, придете совсем не туда, куда намеревались. Если все специалисты, привлеченные к разработке программы, хотят создать продукт, который удовлетворял бы клиентов и отвечал бы их ожиданиям, они должны ясно представлять себе, что именно от них ожидают.

Третья обезьяна: надежность

Если вы уложились в срок на промежуточных финишах (на этапах спецификации, проектирования и реализации), но для того, чтобы добиться достаточной надежности работы системы вам потребовалось два дополнительных года, у вас будут большие неприятности. Ошибки неизбежны, но существует определенный предел их количества. И если вы за него вышли, это означает, что продукт непригоден для использования, или по крайней мере менее конкурентоспособен. В зависимости от конкретного приложения этот предел может меняться. Согласитесь, что степень надежности программ навигации для пассажирских авиалайнеров должна быть большей, чем у обычного браузера. Однако определенный уровень надежности вы обязаны обеспечить в любом случае.

Исходя из собственного опыта могу утверждать, что надежность обеспечивают две основные составляющие - хороший, основательный проект и правильное программирование. С появлением Java (характерными чертами которого являются новые возможности по сборке мусора и ограничения на указатели) обеспечить надежность программного продукта стало гораздо проще. Но даже при отсутствии проблем с памятью, появление недостаточно надежных программ все еще возможно. Они появляются именно в результате создания неудачного проекта и некачественного программирования.

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

Четвертая обезьяна: быстродействие

В понятие "быстродействие" входит скорость выполнения программы, объем использования ресурсов и так далее. При проектировании и реализации программы этот фактор необходимо учитывать обязательно. Программисты нередко бывают озабочены проблемой повышения производительности программы. Однако на самом деле такой проблемы может и не быть. Хотя в процессе разработки фактор производительности и нужно учесть, он не должен поглощать все ваше внимание. Пожалуй, правильнее всего поступать следующим образом. В первую очередь стоит позаботиться о создании "добротного" проекта с "объектной ориентацией и поддержкой многопоточности". Если же во время интеграции и тестирования вы действительно обнаружите наличие проблем с производительностью, то проанализировать и решить их лучше всего именно на этом этапе.

Пятая обезьяна: гибкость

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

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

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

Заключение

Что же такое "добротный объектно-ориентированный проект с многопоточной поддержкой"? Ответ на этот вопрос зависит от того, о чем именно идет речь - об объектной ориентации или о многопоточной поддержке.

В первую очередь многопоточная поддержка связана с обеспечением надежности (вспомните третью обезьяну). Если вы забудете синхронизировать методы, которые действительно необходимо синхронизировать, это приведет к временному повреждению данных. Создание проектов с многопоточной поддержкой невозможно без понимания самого понятия "многопоточность", без ясного представления о требованиях к обеспечению поддержки многопоточности конкретных программ и без соответствующего программирования.

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

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

Однако, прежде всего, создание добротного объектно-ориентированного проекта позволит обеспечить гибкость программы, то есть решит проблему, которая так беспокоит обезьяну номер пять. Добротный объектно-ориентированный проект позволит вам создать код, который можно без труда понять и изменить. А чем более гибким является тело кода, тем быстрее (и дешевле) процесс усовершенствования кода или исправления в нем ошибок.

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

Примите участие в обсуждении

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

Я призываю вас присылать свои отклики на те материалы, которые будут опубликованы в ней. Пусть это будут любые комментарии - замечания, предложения, и даже гневные отповеди. Если вы с чем-то не согласны или хотите что-то добавить, то прошу вас мне об этом сообщать. В очередные статьи (начиная со второй) я буду включать некоторые из читательских откликов на статью за предыдущий месяц.

Вы можете включиться в обсуждение, посылая свои сообщения на мой электронный адрес - bill.venners@javaworld.com.

В следующем месяце

Начиная со следующего выпуска "Секретов проектирования" я собираюсь приступить к публикации небольшой серии статей, которые посвящены созданию классов и объектов. В первой из этих статей вы познакомитесь с рекомендациями, относящимися к области инициализации классов.

Источники