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

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 такой механизм группировки получил название пакет (package).

Пакеты

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

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

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

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

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

На рис. 7.1 изображены классы предметной области, моделирующие бизнес-систему и сгруппированные в два пакета: Заказы и Клиенты.

Оба пакета являются частью пакета предметной области в целом. Приложение Сбора Заказов имеет зависимости с обоими пакетами предметной области. Пользовательский Интерфейс Сбора Заказов имеет зависимости с Приложением Сбора Заказов и AWT (средством разработки графического интерфейса пользователя в языке Java).

Пользовательский Интерфейс Сбора Заказов

Пакет

Пользовательский

Интерфейс Списка Рассылки

Зависимость

Приложение Сбора Заказов

Приложение Списка Рассылки

Рис. 7.1. Диаграмма пакетов

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

Существует очевидное сходство между зависимостями пакетов и зависимостями компиляции. Тем не менее, между ними имеется принципиальное различие: зависимости пакетов не являются транзитивными.

Можно привести следующий пример транзитивного отношения: у Джима борода длиннее, чем у Гради, а у Гради длиннее, чем у Айвара, отсюда можно заключить, что у Джима борода длиннее, чем у Айвара.

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

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 
Продажа и изготовление мебели.

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