2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 14
Текст из файла (страница 14)
Когда выклассовстроите модели, то, как правило, фокусируете внимание на групобсуждаются пах классов, взаимодействующих друг с другом. В UML такиев главе 8.сообщества классов формируют кооперации и обычно визуализируются в диаграммах классов.Внутренняяструктураклассовобсуждаетсяв главе 15.На заметку. Обязанности выражаются текстом в свободном формате. Отдельная обязанность представлена фразой,предложением или (как максимум) коротким абзацем.Типичные приемы моделированияМоделирование словаря системыПрочие характеристикиАтрибуты, операции и обязанности – это наиболее часто используемые средства, которые понадобятся вам при создании абстракций.
Фактически для большинства моделей, которые вы строите,базовая форма этих трех компонентов – все, что нужно для выражения самых важных частей семантики ваших классов. Однакоиногда у вас будет возникать потребность в визуализации илиспецификации некоторых других характеристик (таких как видимость отдельных атрибутов операций); свойств операций, зависимыхот языка (таких как полиморфизм или константность); либо дажеисключений, которые объект класса может генерировать или обрабатывать. Эти и многие другие средства могут быть выражены средствами UML, но они рассматриваются как дополнительные понятия.ИнтерфейсыПриступив к построению моделей, вы очень скоро обнаруживаобсуждают- ете, что почти каждая абстракция, которую вы создаете, представся в главе 11.
ляет собой класс определенного вида. Иногда реализацию классанеобходимо отделять от его спецификации. В UML это может бытьвыражено посредством интерфейсов.Болеесложныеконструкцииклассаобсуждаютсяв главе 9.Вариантыиспользования обсуждаютсяв главе 17.Чаще всего вы будете использовать классы для моделированияабстракций, происходящих от проблем, которые вы пытаетесь решить, либо от технологий, используемых для решений этих проблем. Каждая из таких абстракций является частью словаря вашейсистемы, то есть вместе взятые, они представляют совокупностьпонятий, важных для пользователей и разработчиков.Для пользователей идентифицировать большинство абстракций не так сложно, потому что последние, как правило, происходятот тех элементов и понятий, которые уже используются для описания систем.
Методика применения CRCFкарт и анализа на основе вариантов использования – отличный способ помочь найти этиабстракции. Что же касается разработчиков, для них подобные абстракции обычно являются всего лишь технологическими сущностями, представляющими части решения.Чтобы смоделировать словарь системы, необходимо: Идентифицировать те сущности, которыми оперируют пользователи или разработчики для описания проблемы или ееКлассы70решения. Использовать CRCFкарты и анализ на основе вариантов использования для выявления этих абстракций.
Для каждой абстракции идентифицировать набор ее обязанностей. Убедиться, что каждый класс четко определен и обязанности сбалансированно распределены между классами. Представить атрибуты и операции, необходимые для выполнения обязанностей каждого класса.Рис. 4.9 показывает набор классов, предназначенный для реализации системы розничной торговли и содержащий классы Customer(Покупатель), Order (Заказ) и Product (Продукт).
Также рисуноквключает несколько других абстракций, связанных с основными, –они взяты из словаря проблемной области. Это Shipment (Поставка) –используется для отслеживания заказов; Invoice (СчетFфактура) –для оплаты заказов; Warehouse (Склад) – место хранения товаровперед отправкой. Есть также одна абстракция, имеющая отношениек решению: Transaction (Транзакция). Она применяется к заказами поставкам.–Типичные приемы моделирования71Моделирование распределенияобязанностей в системеЕсли вам придется моделировать немало классов, вы захотите убедиться, что ваши абстракции обеспечивают сбалансированный наборобязанностей. Иными словами, нельзя допустить, чтобы какойFтоиз классов оказался слишком большим или слишком маленьким.Каждый класс должен хорошо выполнять одну задачу. Если выабстрагируете классы, которые окажутся слишком большими, то обнаружите, что ваша модель трудно поддается изменениям и не слишком удобна для повторного использования.
Если же абстрагироватьслишком маленькие классы, у вас будет слишком много абстракций,которые трудно понять и которыми трудно управлять. UML поможет визуализировать и специфицировать баланс обязанностей.Чтобы смоделировать распределение обязанностей в системе,необходимо: Идентифицировать множество классов, работающих совместно для достижения некоторого поведения. Идентифицировать набор обязанностей каждого из этихклассов.Кооперации Рассмотреть множество классов как одно целое; расчленитьклассы, на которые приходится слишком большая доля обяобсуждаютзанностей, на меньшие абстракции; объединить мелкие класся в главе 28.сы с тривиальными обязанностями в более крупные; перераспределить обязанности так, чтобы для каждой абстракциибыл отведен их оптимальный набор.––Рис.
4.9. Моделирование словаря системы–По мере расширения ваших моделей вы обнаружите, что многиеклассы имеют тенденцию собираться в группы (кластеры), концептуально и семантически связанные. В UML для моделирования таких кластеров можно использовать пакеты.Редко когда ваши модели будут абсолютно статическими. СкоМоделирование поведения рее всего, абстракции из словаря вашей системы в большинствеобсуждается своем будут динамически взаимодействовать друг с другом.
UMLпредусматривает множество способов моделирования динамичесв глакого поведения.вах 4 и 5.Пакеты обсуждаютсяв главе 12.–––Рис. 4.10. Моделирование распределения обязанностей в системе72Наборклассовформируетобразец (см.главу 29).КлассыТипичные приемы моделирования Рассмотреть способы взаимодействия классов и перераспределить их обязанности исходя из того, что ни один классне должен делать слишком мало или слишком много.В качестве примера на рис. 4.10 приведен набор классов, взятыйиз языка Smalltalk, показывающий распределение обязанностеймежду классами Model (Модель), View (Представление) и Controller(Контроллер).
Все эти классы работают вместе так, что ни одномуиз них не приходится делать слишком много или мало.Рис. 4.11. Моделирование непрограммных сущностейМоделирование примитивных типовМоделирование непрограммных сущностейИногда сущности, которые вы моделируете, не имеют аналогав программном обеспечении. Например, люди, которые посылаютсчета, и роботы, которые автоматически пакуют заказы для поставоксо складов, могут быть частью потока работ (workflow), моделируемого для торговой системы. Ваше приложение может не иметь никаких программных компонентов, которые представляют сущности(в отличие от заказчиков в приведенном примере, поскольку вашасистема, вероятно, будет поддерживать информацию о них).Чтобы моделировать непрограммные сущности, необходимо: Смоделировать абстрагируемые сущности в виде классов.
Если вы хотите выделить непрограммные сущности из опреСтереотипыделенных в UML стандартных строительных блоков, сообсуждаютздайте новый строительный блок, применив стереотипы дляся в главе 6.спецификации этой новой семантики и закрепив за ним некий отличительный символ. Если моделируемая сущность представляет собой часть аппаУзлы обсужратного обеспечения, которая, в свою очередь, содержит продаютсяграммное обеспечение, рассмотрите ее моделирование в видев главе 27.узла определенного рода – таким образом, чтобы позднееможно было расширить представление ее структуры.Внешние сущности частомоделируются какдействующиелица (см.главу 17).На заметку.
Язык UML в основном предназначен для моделирования программных систем, хотя в сочетании с текстовымиязыками моделирования аппаратного обеспечения – такими,например, как VHDL – он может быть достаточно выразительным для моделирования аппаратной части. Более того, консорциум OMG предложил расширение UML под названиемSysML, предназначенное для моделирования систем.Как показано на рис. 4.11, вполне допустимо абстрагироватьлюдей (в данном примере – AccountsReceivableAgent, АгентПоДебиторскойЗадолженности) и аппаратное обеспечение (Robot – Робот) в виде классов, потому что они представляют собой множестваобъектов с общей структурой и общим поведением.е типов73В противоположность сказанному выше, иногда моделируемыесущности могут браться непосредственно из языка программирования, который используется для реализации решения.
Как правило,эти абстракции включают примитивные типы – такие как целыечисла, символы, строки и даже перечислимые типы, созданные вами.Чтобы моделировать примитивные типы, необходимо: Смоделировать абстрагируемую сущность в виде класса илиперечисления (enumeration), изображая ее в нотации классас соответствующим стереотипом. Если вам нужно специфицировать диапазон значений, ассоцииОграничениярованный с этим типом, используйте ограничения (constraints).обсуждаютТипы обсуждаютсяв главе 11.ся в главе 6.Рис. 4.12.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
