Звоните! 
 (926)274-88-54 
 Бесплатная доставка. 
 Бесплатная сборка. 
Ассортимент тканей

График работы:
Ежедневно. С 8-00 до 20-00.
Почта: soft_hous@mail.ru
Читальный зал -->  Диаграммы параллельных состояний 

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

список-параметров содержит разделенные запятой параметры, синтаксис которых аналогичен синтаксису атрибутов: <направле-ние> <имя>: <тип> = Оначение по умолчанию>. При этом дополнительным элементом является направление, которое применяется, чтобы показать характер использования параметра - для входа (in), выхода (out) или в обоих направлениях (inout). Если значение направления отсутствует, оно предполагается входным (in).

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

строка-свойств указывает значения свойств, которые применяются к данной операции.

Пример записи операции для счета клиента: -Ь показатьСостояние (дата: Дата): Деньги.

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

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

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

Другие термины, с которыми иногда приходится сталкиваться, - это методы извлечения значения (getting methods) и методы установки значения (setting methods). Метод извлечения значения возвращает некоторое значение из поля (и не делает ничего больше). Метод установки значения помещает некоторое значение в поле (и не делает ничего больше). За пределами класса клиент не способен определить, является ли запрос методом получения значения или является ли модификатор методом установки значений. Эта информация о методах является полностью внутренней для каждого из классов.

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



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

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

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

Обобщение

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

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

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

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



Правила ограничения

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

На рис. 4.2 показано, что Заказ может быть сделан только одним единственным Клиентом. Из этой диаграммы классов также следует, что каждая Позиция заказа рассматривается отдельно: вы можете заказать 40 каких-либо коричневых штучек, 40 голубых этих же штучек и 40 красных таких же штучек, но не 40 коричневых, голубых и красных штучек. Далее диаграмма утверждает, что Корпоративный клиент располагает кредитным лимитом, а Индивидуальный клиент - нет.

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

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

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

Ключевой особенностью здесь является различие между обобщением с точки зрения спецификации (подтипы или наследование интерфейса) и обобщением с точки зрения реализации (подклассы или наследование реализации). Подкласс представляет собой один из способов реализации подтипа. Подтип можно также реализовать с использованием механизма делегирования - действительно, многие образцы, описанные в книге Гамма и др., 1995 [20], содержат два класса с одинаковыми интерфейсами, но без использования подклассов. В книге Фаулера, 1997 [18] можно найти описание других идей реализации подтипов.

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

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



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


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