Проектирование программ: язык моделирования

⇐ ПредыдущаяСтр 66 из 85Следующая ⇒

Язык моделирования — это, по сути, фикция, набор соглашений по поводу принципов предварительного моделирования программы на бумаге. Тем не менее без этого этапа невозможно создать эффективный профессиональный программный продукт. Давайте договоримся изображать классы на бумаге в виде треугольников, а отношения наследования между ними — в виде пунктирных стрелок от базового класса к производному. Для примера смоделируем класс Geranium (Герань), произведенный от класса Flower (Цветок), как показано на рис. 18.1.

Рис. 18.1. Схематическое изображение наследования класса

На рисунке видно, что Geranium — особый вид Flower, и это вполне соответствует действительности. Если мы с вами договоримся графически изображать таким способом наследования классов, то будем прекрасно понимать друг друга. Со временем мы, вероятно, захотим моделировать многие сложные отношения и разработаем свой набор соглашений и правил по созданию диаграмм, отображающих взаимосвязи объектов программы.

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

В таком случае было бы полезным существование единого языка моделирования, понятного для всех. (В действительности эту прекрасную идею реализовать ничуть не проще, чем заставить всех жителей Земли говорить на эсперанто.) Тем не менее такой язык был создан, и имя ему — UML (Unified Modeling Language — унифицированный язык моделирования). Его задача состоит в том, чтобы добиться единообразия в отображении взаимоотношений между объектами в диаграммах. В соответствии с соглашениями языка UML нашу схему, представленную на рис. 18.1, следовало бы изобразить иначе (рис. 18.2).

Рис. 18.2. Те же отношения наследования, но с учетом соглашений UML

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

Соглашения UML совсем несложные. Диаграммы нетрудно понимать и использовать. Мы рассмотрим эти соглашения на конкретных примерах в ходе освоения этой главы, что гораздо проще изучения UML вне контекста. Хотя этой теме можно посвятить целую книгу, по правде говоря, это будет пустая трата времени и бумаги, поскольку язык UML вполне соответствует принципу: лучше один раз увидеть на практике, чем десять раз прочитать.

Процесс проектирования программ

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

Появилась даже новая профессия — методологи: это программисты, которые изучают и разрабатывают методы программирования. Часто в литературе можно встретить статьи, посвященные описанию нового метода программирования. Метод — это совокупность языка моделирования и подходов анализа и проектирования. Три наиболее известных методолога в мире — это Грейди Буч (Grady Booch), создавший метод Буча, Айвер Якобсон (Ivar Ja- cobson), разработавший подходы объектно-ориентированного программирования, и Джеймс Рамбо (James Rumbaugh), создавший технологию объектного моделирования. Вместе они создали метод Objectory~ коммерческий продукт от фирмы Rational Software, Inc. Это фирма, в которой они работают и где их любовно величают " три амигос".

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

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

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

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

Рис. 18.3. Каскадный процесс проектирования

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

Еще раз повторим последовательность действий.

1. Разработка концепции.

2. Анализ.

3. Проектирование.

4. Реализация.

5. Тестирование.

6. Возвращение.

Разработка концепции — это вынашивание чистой идеи, к сожалению, далекой от реальной жизни. Анализ — это процесс осознания требований к проекту. Проектирование — процесс формирования модели классов, на основе которой будет создаваться код. Реализация — написание кода (например, на C++); тестирование — проверка того, все ли в порядке, и возвращение — это шлифовка вашего продукта до того состояния, когда его можно будет отдать заказчику. Осталось реализовать все это на практике.

Идея

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

Дискуссии

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

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

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

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

Анализ требований

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

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

Ситуация использования

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

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

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

Таким образом, определение ситуаций использования включает:

• формулирование общих представлений о том, где и каким образом будет использоваться создаваемый программный продукт;

• работу с экспертами по выяснению особенностей предполагаемого места использования продукта, не связанных с проблемами обычного программирования;

• определение пользователя, для которого создается программный продукт.

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

Определение пользователей

Обратите внимание, что пользователи — это не обязательно люди. Системы, которые будут взаимодействовать с создаваемой нами системой, тоже пользователи. Таким образом, если создается программа для автоматизированного кассового аппарата (ATM, известного как банкомат), то пользователем по отношению к нему будут клиенты и банковские клерки, а также другие банковские системы, например система no отслеживанию ипотек или no выдаче ссуд для студентов. Основные характеристики пользователей таковы:

• они являются внешними по отношению к системе;

• они взаимодействуют с системой.

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

В случае создания программного обеспечения для ATM необходимо учесть следующих возможных пользователей:

• клиент;

• менеджер;

• компьютерная система банка;

• клерк, заправляющий кассовый аппарат деньгами и ответственный за его включение и выключение.

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

⇐ Предыдущая 61 62 63 64 656667 68 69 70 Следующая ⇒