Читальный зал -->  Диаграммы параллельных состояний 

1 2 [ 3 ] 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

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

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

Для чего нужно заниматься анализом и проектированием

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

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

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

Общение

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

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

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

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

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

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

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

Изучение объектно-ориентированных методов

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

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

Это вовсе не означает, что так уж трудно научиться разрабатывать программы на каком-либо объектно-ориентированном языке программирования. Проблема заключается в том, чтобы научиться использовать преимущества объектно-ориентированных языков. Том Хэдфилд (Тот Hadfield) удачно сформулировал это следующей фразой: объектные языки обладают преимуществами, но не предоставляют их автоматически. Чтобы использовать эти преимущества, вы должны пойти на смену пользующейся плохой славой парадигмы. (Немедленно убедитесь, что ВЫ все еще сидите!)

Средства языка UML разрабатывались в некоторой степени для того, чтобы помочь людям выполнять качественные объектно-ориентированные проекты, однако разные средства обладают различными достоинствами.

Одним из наилучших способов изучения объектно-ориентированных методов являются CRC-карточки (см. врезку в главе 5). Они не являются составной частью языка UML, хотя могут и должны использоваться вместе с ним. CRC-карточки были созданы главным образом для обучения людей работе с объектами. Именно поэтому они намеренно отличаются от традиционных методов проектирования. Запись на этих карточках ответственности класса и отсутствие сложной нотации делает их особенно важным средством.

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

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

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

1 2 [ 3 ] 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

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



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.

Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы.