Умл в 1с что это
Модель UML (UML model) ‒ это совокупность конечного множества конструкций языка, главные из которых ‒ это сущности и отношения между ними.
Сами сущности и отношения модели являются экземплярами метаклассов метамодели.
Рассматривая модель UML с наиболее общих позиций, можно сказать, что это граф (точнее, нагруженный мульти-псевдо-гипер-орграф), в котором вершины и ребра нагружены дополнительной информацией и могут иметь сложную внутреннюю структуру. Вершины этого графа называются сущностями, а ребра ‒ отношениями. Остальная часть раздела содержит беглый (предварительный), но полный обзор имеющихся типов сущностей и отношений. К счастью, их не слишком много. В последующих главах книги все сущности и отношения рассматриваются еще раз, более детально и с примерами.
1.4.1. Сущности
Для удобства обзора сущности в UML можно подразделить на четыре группы:
- структурные;
- поведенческие;
- группирующие;
- аннотационные.
Структурные сущности, как нетрудно догадаться, предназначены для описания структуры. Обычно к структурным сущностям относят следующие.
Объект (object) 1 ‒ сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение.
Класс (class) 2 ‒ описание множества объектов с общими атрибутами, определяющими состояние, и операциями, определяющими поведение.
Интерфейс (interface) 3 ‒ именованное множество операций, определяющее набор услуг, которые могут быть запрошены потребителем и предоставлены поставщиком услуг.
Кооперация (collaboration) 4 ‒ совокупность объектов, которые взаимодействуют для достижения некоторой цели.
Действующее лицо (actor) 5 ‒ сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.
Компонент ∇ (component) 6 ‒ модульная часть системы с четко определенным набором требуемых и предоставляемых интерфейсов.
Артефакт (artifact) 7 ‒ элемент информации, который используется или порождается в процессе разработки программного обеспечения. Другими словами, артефакт ‒ это физическая единица реализации, получаемая из элемента модели (например, класса или компонента).
Узел (node) 8 ‒ вычислительный ресурс, на котором размещаются и при необходимости выполняются артефакты.
∇ В русском языке допустимо использование слова "компонент" мужского рода и слова "компонента" женского рода. Современная языковая практика склоняется к использованию мужского рода, поэтому мы употребляем, например, термин "диаграмма компонентов". Но в некоторых случаях традиция требует использования женского рода, например, "компонента связности графа".
На следующем рисунке приведена стандартная нотация в минимальном варианте для структурных сущностей.
Рис. Нотация структурных сущностей
Поведенческие сущности предназначены для описания поведения. Основных поведенческих сущностей всего две: состояние и действие (точнее, две с половиной, потому что иногда употребляется еще и деятельность, которую можно рассматривать как особый случай состояния).
Состояние (state) 1 ‒ период в жизненном цикле объекта, находясь в котором объект удовлетворяет некоторому условию и осуществляет собственную деятельность или ожидает наступления некоторого события.
Деятельность (activity) 2 можно считать частным случаем состояния, который характеризуется продолжительными (по времени) не атомарными вычислениями.
Действие (action) 3 ‒ примитивное атомарное вычисление.
Это только надводная часть айсберга поведенческих сущностей: состояния бывают самые разные (см. раздел 4.2). Кроме того, при моделировании поведения используется еще ряд вспомогательных сущностей, которые здесь не перечислены, потому что сосуществуют только вместе с указанными основными.
Несколько особняком стоит сущность ‒ вариант использования.
Вариант использования (use case) 4 ‒ множество сценариев, объединенных по некоторому критерию и описывающих последовательности производимых системой действий, доставляющих значимый для некоторого действующего лица результат.
Ниже приведена стандартная нотация в минимальном варианте для поведенческих сущностей.
Рис. Нотация поведенческих сущностей
Группирующая сущность в UML одна ‒ пакет ‒ зато универсальная.
Пакет (package) 1 ‒ группа элементов модели (в том числе пакетов).
Аннотационная сущность тоже одна ‒ комментарий.
Комментарий (comment) 2 ‒ произвольное по формату и содержанию описание одного или нескольких элементов модели.
Рис. Нотация группирующей и аннотационной сущностей
Приведенная классификация не является исчерпывающей. У каждой из этих сущностей есть различные частные случаи и вариации, рассматриваемые в последующих главах.
1.4.2. Отношения
В UML используются четыре основных типа отношений:
- зависимость (dependency);
- ассоциация (association);
- обобщение (generalization);
- реализация (realization).
Зависимость ‒ это наиболее общий тип отношения между двумя сущностями.
Отношение зависимости указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность.
Графически отношение зависимости изображается в виде пунктирной линии со стрелкой 1 , направленной от зависимой сущности 2 к независимой 3 , как показано на следующем рисунке. Как правило, семантика конкретной зависимости уточняется в модели с помощью дополнительной информации. Например, зависимость со стереотипом «use» означает, что зависимая сущность использует (скажем, вызывает операцию) независимую сущность.
Рис. Отношение зависимости
Ассоциация ‒ это наиболее часто используемый тип отношения между сущностями.
Отношение ассоциации имеет место, если одна сущность непосредственно связана с другой (или с другими ‒ ассоциация может быть не только бинарной).
Графически ассоциация изображается в виде сплошной линии 1 с различными дополнениями, соединяющей связанные сущности, как показано на следующем рисунке. На программном уровне непосредственная связь может быть реализована различным образом, главное, что ассоциированные сущности знают друг о друге. Например, отношение часть-целое является частным случаем ассоциации и называется отношением агрегации.
Рис. Отношение ассоциации
Обобщение ‒ это отношение между двумя сущностями, одна их которых является частным (специализированным) случаем другой.
Графически обобщение изображается в виде линии с треугольной незакрашенной стрелкой на конце 1 , направленной от частного 2 (подкласса) к общему 3 (суперклассу), как показано на следующем рисунке.
Рис. Отношение обобщения
Отношение реализациии используется несколько реже, чем предыдущие три типа отношений, поскольку часто подразумеваются по умолчанию.
Отношение реализации указывает, что одна сущность является реализацией другой.
Например, класс является реализацией интерфейса. Графически реализация изображается в виде пунктирной линии с треугольной незакрашенной стрелкой на конце 1 , направленной от реализующей сущности 2 к реализуемой 3 , как показано на следующем рисунке.
Рис. Отношение реализации
Перечисленные типы отношений являются основными, различные их вариации и дополнительные отношения детально рассматриваются в последующих главах.
1.4.3. Диаграммы
Предыдущий параграф преследует примерно те же цели, какие имеет описание лексики в обычном языке программирования. А именно, мы обрисовали (еще не полностью, но уже достаточно) множество слов UML (лексем, графических примитивов, элементов моделирования ‒ называйте, как хотите ‒ фиксированного термина нет). Пора переходить к синтаксису, а именно к описанию того, как из слов конструируются предложения.
На первый взгляд, все очень просто: берутся сущности и, если нужно, указываются отношения между ними. В результате получается модель, то есть граф (с разнородными вершинами и ребрами), нагруженный дополнительной информацией. Но при более внимательном рассмотрении обнаруживаются проблемы. Мы хотим затратить некоторые усилия на обсуждение этих проблем, иначе целый ряд особенностей UML может показаться висящим в воздухе, хотя на самом деле, эти особенности и есть продуманное решение замалчиваемых обычно проблем.
∇ Скажем, эту книгу ‒ не в качестве образца, а в качестве примера.
∇∇ Смеем вас уверить, что писать структурированный текст также намного легче.
Диаграммы UML и есть та основная накладываемая на модель структура, которая облегчает создание и использование модели.
Диаграмма (diagram) ‒ это графическое представление некоторой части графа модели.
Вообще говоря, в диаграмму можно было бы включить любые (допустимые) комбинации сущностей и отношений, но произвол в этом вопросе затруднил бы понимание моделей. Поэтому авторы UML определили набор рекомендуемых к использованию типов диаграмм, которые получили название канонических типов диаграмм.
Инструменты моделирования, как правило, обеспечивают работу со всеми каноническими диаграммами, но делают это довольно догматически, не позволяя отойти от канона ни на шаг, даже если это нужно по существу задачи. С другой стороны, некоторые инструменты, наряду с каноническими, поддерживают и апокрифические типы диаграмм. Было бы удобно, если бы набор канонических диаграмм предлагался по умолчанию, но пользователь мог бы настроить, изменить и переопределить этот набор в случае необходимости, примерно так, как это делается с шаблонами Microsoft Word. Некоторые инструменты, но далеко не все, поддерживают такие возможности.
Заметим, что помимо сущностей и отношений на диаграмме присутствует другие элементы модели, которые мы также будем называть конструкциями языка. Это тексты, которые могут быть написаны внутри фигур сущностей или рядом с линиями отношений, рамки диаграмм и их фрагментов, значки, присоединяемые к линиям или помещаемые внутрь фигур. Эти элементы не только помогают представить модель в более наглядной форме, но подчас несут значительную смысловую нагрузку.
1.4.4. Классификация диаграмм
В UML 1 ∇ всего определено 9 канонических типов диаграмм. Ниже перечислены их названия, принятые в этой книге (в других источниках есть отличия).
∇ Здесь и далее под UML 1 понимаются версии UML, предшествующие UML 2.0.
- Диаграмма использования ∇ (Use Case diagram)
- Диаграмма классов (Class diagram)
- Диаграмма объектов (Object diagram)
- Диаграмма состояний (State chart diagram)
- Диаграмма деятельности (Activity diagram)
- Диаграмма последовательности (Sequence diagram)
- Диаграмма кооперации (Collaboration diagram)
- Диаграмма компонентов (Component diagram)
- Диаграмма размещения ∇∇ (Deployment diagram)
∇ В некоторых источниках название этого типа диаграмм переводится как "диаграмма прецедентов", что является грубейшей терминологической ошибкой. Не советуем пользоваться такими источниками ‒ скорее всего, их авторы не понимают того, о чем пишут.
∇∇ В некоторых источниках название данной диаграммы переводится как "диаграмма развертывания".
Этот список является итогом многочисленных дискуссий и компромиссов, поэтому не следует воспринимать его как догму. В частности, расхожее утверждение "в UML определены девять типов диаграмм" является не совсем верным: в метамодели UML определены элементы модели (сущности и отношения) и способы их комбинирования, а девять типов диаграмм ‒ это уже надстройка над языком, отражающая сложившуюся практику его использования.
Канонические диаграммы отнюдь не образуют полного ортогонального набора: они пересекаются как по включенным в них средствам, так и по области применения. Более того, некоторые из них являются частными случаями других, есть просто семантически эквивалентные пары, можно привести примеры допустимых диаграмм, для которых затруднительно указать однозначно, к какому именно из канонических типов диаграмма относится.
Сказанное можно проиллюстрировать условной классификацией диаграмм, приведенной ниже.
Рис. Иерархия типов диаграмм для UML 1
Мы поместили диаграмму использования отдельно, не относя ее ни к диаграммам описания структуры, ни к диаграммам описания поведения. В большинстве источников диаграммы использования относят к описанию поведения, что нам представляется некоторой натяжкой ∇ . Кроме отношений обобщения, на диаграмме классов, а именно эта диаграмма изображена на рис. Иерархия типов диаграмм для UML 1, дополнительно показаны некоторые зависимости между отдельными UML диаграммами. Эти зависимости в каждом конкретном случае носят различный характер, что отражено посредством использования различных стереотипов. Подробнее о стандартных стереотипах зависимостей см. параграф 3.1.1.
∇ Подобная взаимосвязь безусловно существует, что выражается на рис. Иерархия типов диаграмм для UML 1 в виде отношения зависимости со стереотипом «refine» .
В UML 2 ∇ внесены значительные коррективы как в список канонических диаграмм, а именно их число увеличилось до 13, так и в список доступных конструкций языка, что значительно расширило область его применения. Кроме этого две диаграммы были переименованы: диаграмма кооперации была переименована в диаграмму коммуникации ∇∇ , а диаграмма состояний в диаграмму автомата ∇∇∇ .
∇ Здесь и далее под UML 2 понимаются версии UML, начиная с UML 2.0.
∇∇ В UML 1 возникала невольная ассоциация между диаграммой кооперации и одноименной сущностью, что было не совсем верно и порой вводило в заблуждение.
∇∇∇ В UML 2 синтаксическая и смысловая нагрузка диаграммы состояний настолько изменилась, что название уже не отражало содержания.
Список новых диаграмм и их названий, принятых в этой книге, приведен ниже.
- Диаграмма внутренней структуры (Composite Structure diagram)
- Диаграмма пакетов (Package diagram)
- Диаграмма автомата (State machine diagram)
- Диаграмма коммуникации (Communication diagram)
- Обзорная диаграмма взаимодействия (Interaction Overview diagram)
- Диаграмма синхронизации (Timing diagram)
На рис. Иерархия типов диаграмм для UML 2 (часть 1 и 2) приведена диаграмма классов, отражающая взаимосвязь диаграмм в UML 2.
Рис. Иерархия типов диаграмм для UML 2 (часть 1)
Рис. Иерархия типов диаграмм для UML 2 (часть 2)
Далее в этой главе мы очень бегло опишем все тринадцать канонических диаграмм, с тем, чтобы иметь определенный контекст и словарный запас для последующего изложения. Детали изложены в остальных главах книги.
Но прежде чем перейти к следующему разделу, сделаем одно небольшое отступление относительно того, как стандарт требует оформлять диаграммы. Общий шаблон представления диаграммы приведен ниже.
Рис. Нотация для диаграмм
Основных элементов оформления два: наружная рамка и ярлычок с названием диаграммы. Если с рамкой все просто ‒ это прямоугольник, ограничивающий область в котором должны находиться элементы диаграммы, то название диаграммы записывается в специальном формате, приведенном на рис. Нотация для диаграмм.
Указанная сложная форма ярлычка поддерживается не всеми инструментами. Впрочем, это не обязательно, поскольку семантика первична, а нотация вторична. Далее мы везде используем в качестве ярлычка диаграммы прямоугольник, и это не должно вызывать недоразумений.
Возможные теги (типы) для диаграмм приведены в следующей таблице. Теги, предлагаемые стандартом, записаны во второй столбец. Однако, как показала практика, предлагаемые стандартом правила не всегда удобны и логически обоснованы, поэтому третий столбец таблицы содержит разумную на наш взгляд альтернативу.
UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования.
Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.
Словарь UML включает три вида строительных блоков:
Сущности – это абстракции, которые являются основными элементами модели, связи соединяют их между собой, а диаграммы группируют представляющие интерес наборы сущностей.
Диаграмма – это графическое представление набора элементов, чаще всего изображенного в виде связного графа вершин (сущностей) и путей (связей). Язык UML включает 13 видов диаграмм, среди которых на первом месте в списке — диаграмма классов, о которой и пойдет речь.
Диаграммы классов показывают набор классов, интерфейсов, а также их связи. Диаграммы этого вида чаще всего используются для моделирования объектно-ориентированных систем. Они предназначены для статического представления системы.
Большинство элементов UML имеют уникальную и прямую графическую нотацию, которая дает визуальное представление наиболее важных аспектов элемента.
Сущности
Диаграммы классов оперируют тремя видами сущностей UML:
- Структурные.
- Поведенческие.
- Аннотирующие.
Структурные сущности – это «имена существительные» в модели UML. В основном, статические части модели, представляющие либо концептуальные, либо физические элементы. Основным видом структурной сущности в диаграммах классов является класс .
Аннотирующие сущности – это поясняющие части UML-моделей, иными словами, комментарии, которые можно применить для описания, выделения и пояснения любого элемента модели. Главная из аннотирующих сущностей – примечание . Это символ, служащий для описания ограничений и комментариев, относящихся к элементу либо набору элементов. Графически представлен прямоугольником с загнутым углом; внутри помещается текстовый или графический комментарий.
Структурные сущности — классы
Класс – это описание набора объектов с одинаковыми атрибутами, операциями, связями и семантикой.
Графически класс изображается в виде прямоугольника, разделенного на 3 блока горизонтальными линиями:
- имя класса
- атрибуты (свойства) класса
- операции (методы) класса.
Для атрибутов и операций может быть указан один из трех типов видимости:
Видимость для полей и методов указывается в виде левого символа в строке с именем соответствующего элемента.
Каждый класс должен обладать именем, отличающим его от других классов. Имя – это текстовая строка. Имя класса может состоять из любого числа букв, цифр и знаков препинания (за исключением двоеточия и точки) и может записываться в несколько строк.
На практике обычно используются краткие имена классов, взятые из словаря моделируемой системы. Каждое слово в имени класса традиционно пишут с заглавной буквы (верблюжья конвенция), например Sensor (Датчик) или TemperatureSensor (ДатчикТемпературы).
Для абстрактного класса имя класса записывается курсивом.
Атрибут (свойство) – это именованное свойство класса, описывающее диапазон значений, которые может принимать экземпляр атрибута. Класс может иметь любое число атрибутов или не иметь ни одного. В последнем случае блок атрибутов оставляют пустым.
Атрибут представляет некоторое свойство моделируемой сущности, которым обладают все объекты данного класса. Имя атрибута, как и имя класса, может представлять собой текст. На практике для именования атрибута используются одно или несколько коротких существительных, выражающих некое свойство класса, к которому относится атрибут.
Можно уточнить спецификацию атрибута, указав его тип, кратность (если атрибут представляет собой массив некоторых значений) и начальное значение по умолчанию.
Статические атрибуты класса обозначаются подчеркиванием.
Операция (метод) – это реализация метода класса. Класс может иметь любое число операций либо не иметь ни одной. Часто вызов операции объекта изменяет его атрибуты.
Графически операции представлены в нижнем блоке описания класса.
Допускается указание только имен операций. Имя операции, как и имя класса, должно представлять собой текст. На практике для именования операции используются короткие глагольные конструкции, описывающие некое поведение класса, которому принадлежит операция. Обычно каждое слово в имени операции пишется с заглавной буквы, за исключением первого, например move (переместить) или isEmpty (проверка на пустоту).
Можно специфицировать операцию, устанавливая ее сигнатуру, включающую имя, тип и значение по умолчанию всех параметров, а применительно к функциям – тип возвращаемого значения.
Абстрактные методы класса обозначаются курсивным шрифтом.
Статические методы класса обозначаются подчеркиванием.
Изображая класс, не обязательно показывать сразу все его атрибуты и операции. Для конкретного представления, как правило, существенна только часть атрибутов и операций класса. В силу этих причин допускается упрощенное представление класса, то есть для графического представления выбираются только некоторые из его атрибутов. Если помимо указанных существуют другие атрибуты и операции, вы даете это понять, завершая каждый список многоточием.
Чтобы легче воспринимать длинные списки атрибутов и операций, желательно снабдить префиксом (именем стереотипа) каждую категорию в них. В данном случае стереотип – это слово, заключенное в угловые кавычки, которое указывает то, что за ним следует.
Отношения между классами
Существует четыре типа связей в UML:
- Зависимость
- Ассоциация
- Обобщение
- Реализация
Эти связи представляют собой базовые строительные блоки для описания отношений в UML, используемые для разработки хорошо согласованных моделей.
Первая из них – зависимость – семантически представляет собой связь между двумя элементами модели, в которой изменение одного элемента (независимого) может привести к изменению семантики другого элемента (зависимого). Графически представлена пунктирной линией, иногда со стрелкой, направленной к той сущности, от которой зависит еще одна; может быть снабжена меткой.
Зависимость – это связь использования , указывающая, что изменение спецификаций одной сущности может повлиять на другие сущности, которые используют ее.
Ассоциация – это структурная связь между элементами модели, которая описывает набор связей, существующих между объектами.
Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к другому.
Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в». В представлении однонаправленной ассоциации добавляется стрелка, указывающая на направление ассоциации.
Двойные ассоциации представляются линией без стрелок на концах, соединяющей два классовых блока.
Ассоциация может быть именованной, и тогда на концах представляющей её линии будут подписаны роли, принадлежности, индикаторы, мультипликаторы, видимости или другие свойства.
Множественность ассоциации представляет собой диапазон целых чисел, указывающий возможное количество связанных объектов. Он записывается в виде выражения с минимальным и максимальным значением; для их разделения используются две точки. Устанавливая множественность дальнего конца ассоциации, вы указываете, сколько объектов может существовать на дальнем конце ассоциации для каждого объекта класса, находящегося на ближнем ее конце. Количество объектов должно находиться в пределах заданного диапазона. Множественность может быть определена как единица 1 , ноль или один 0..1 , любое значение 0..* или * , один или несколько 1..* . Можно также задавать диапазон целых значений, например 2..5 , или устанавливать точное число, например 3 .
Агрегация – особая разновидность ассоциации, представляющая структурную связь целого с его частями. Как тип ассоциации, агрегация может быть именованной. Одно отношение агрегации не может включать более двух классов (контейнер и содержимое).
Агрегация встречается, когда один класс является коллекцией или контейнером других. Причём, по умолчанию агрегацией называют агрегацию по ссылке, то есть когда время существования содержащихся классов не зависит от времени существования содержащего их класса. Если контейнер будет уничтожен, то его содержимое — нет.
Графически агрегация представляется пустым ромбом на блоке класса «целое», и линией, идущей от этого ромба к классу «часть».
Композиция — более строгий вариант агрегации. Известна также как агрегация по значению.
Композиция – это форма агрегации с четко выраженными отношениями владения и совпадением времени жизни частей и целого. Композиция имеет жёсткую зависимость времени существования экземпляров класса контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено.
Графически представляется как и агрегация, но с закрашенным ромбиком.
Третья связь – обобщение – выражает специализацию или наследование , в котором специализированный элемент (потомок) строится по спецификациям обобщенного элемента (родителя). Потомок разделяет структуру и поведение родителя. Графически обобщение представлено в виде сплошной линии с пустой стрелкой, указывающей на родителя.
Четвертая – реализация – это семантическая связь между классами, когда один из них (поставщик) определяет соглашение, которого второй (клиент) обязан придерживаться. Это связи между интерфейсами и классами, которые реализуют эти интерфейсы. Это, своего рода, отношение «целое-часть». Поставщик, как правило, представлен абстрактным классом. В графическом исполнении связь реализации – это гибрид связей обобщения и зависимости: треугольник указывает на поставщика, а второй конец пунктирной линии – на клиента.
Пример кода и диаграммы классов для него
Программа получает данные с датчика температуры (вводятся с консоли) — по 5 измерений для каждого из двух объектов класса TemperatureMeasure и усредняет их. Также предусмотрен класс ShowMeasure для вывода измеренных значений.
Результат выполнения
UML-диаграмма классов для приведенного выше кода будет выглядеть следующим образом:
На диаграмме классов основным классом является класс TemperatureMeasure , который и является измерителем температуры. В качестве измеренного значения формируется среднее арифметическое всех измерений - сумма всех измерений, деленная на их количество.
Для получения измерений и их суммирования используется класс Sensor (в качестве датчика температуры). В консольной задаче сами измерения передаются в этот класс для суммирования. Класс состоит в отношении агрегации с основным классом TemperatureMeasure : мы сначала создаем объект класса Sensor , а потом передаем его в качестве параметра конструктора классу TemperatureMeasure , чтобы использовать его в качестве части класса.
Количество измерений формируется классом MeasureCount , который содержит статическое свойство total для подсчета общего измерений, а также свойство count для подсчета количества измерителей конкретного объекта TemperatureMeasure . Класс MeasureCount находится в отношении композиции с классом TemperatureMeasure : объект MeasureCount создается непосредственно при создании объекта TemperatureMeasure (в его конструкторе).
Класс ITemperatureMeasure представляет собой интерфейс класса TemperatureMeasure и является своего рода поставщиком в отношении реализации.
Наконец, класс ShowTemperature находится в отношении зависимости с классом TemperatureMeasure , поскольку реализация единственного метода Show класса ShowTemperature зависит от структуры класса TemperatureMeasure .
UML Diagrams расшифровывается как Unified Modeling Language . Это стандарт, который в основном используется для создания объектно-ориентированных, значимых моделей документации для любой программной системы, представленной в реальном мире. Это дает нам возможность разрабатывать богатые модели, которые описывают работу любых программно-аппаратных систем.
UML служит отличным способом создания профессиональной документации, которая является необходимой частью любой разработки проекта. UML является неотъемлемой частью создания объектно-ориентированного проектирования систем. Он предоставляет вам средства для создания мощных моделей и конструкций для рациональных систем, которые можно понять без особых трудностей.
В этом уроке вы узнаете,
Зачем использовать UML? Полная история
1990-е годы были эпохой развития объектно-ориентированных языков, таких как C ++. Эти объектно-ориентированные языки использовались для создания сложных, но привлекательных систем.
Поскольку разработанные системы были сложны для понимания, это привело к проблемам проектирования и анализа, с которыми столкнулись после развертывания системы. Было сложно объяснить систему другим.
Как только появился UML, было проведено множество экспериментов и подходов, меняющих правила игры, для упрощения таких сложных задач анализа системы.
UML – это объектно-ориентированный унифицированный язык моделирования. Он был изобретен блестящими инженерами-программистами Грэди Бучом, Иваром Джекобсоном и Джеймсом Румбо из Rational software в течение 1994 и 1995 годов. Он разрабатывался до 1996 года.
У каждого из изобретателей UML, а именно, Грэди Буча, Ивара Джекобсона и Джеймса Румбо, была фантастическая идея разработать язык, который уменьшит сложность.
- Метод Буча был очень гибким для работы при проектировании и строительстве объектов.
- Метод Якобсона предоставил отличный способ обойти варианты использования. У этого также есть мощный подход для дизайна высокого уровня.
- Метод Рамбо оказался очень полезным при работе с чувствительными системами.
Позже в UML были изобретены модели поведения и диаграммы состояний, которые были изобретены Дэвидом Харелом.
UML была признана стандартом группой управления объектами (OMG) в 1997 году. Группа управления объектами отвечает за управление UML с момента его принятия в качестве стандарта.
В 2005 году Международная организация по стандартизации утвердила UML в качестве стандарта ISO. Он используется в различных отраслях промышленности для создания объектно-ориентированных моделей.
Последняя версия UML 2.5.1 выпущена в декабре 2017 года.
Версии UML
Свидание | Версия | Около |
---|---|---|
Ноябрь 1997 | 1,1 | UML был принят Группой Управления Объектами. Это была первая версия UML. |
Март 2000 | 1,3 | Незначительное обновление было сделано для существующей модели с заметными изменениями в семантике, нотациях и метамоделях UML. |
Сентябрь 2001 | 1.4 | Это был период серьезного обновления UML. Он масштабировал UML, предоставляя различные расширения. Видимость, артефакт, стереотипы были введены в диаграммах. |
Март 2003 | 1,5 | Такие функции, как процедуры, механизм потока данных были добавлены в UML. |
Январь 2005 | 1.4.2 | UML был принят в качестве стандарта ISO. |
Август 2005 | 2,0 | Новые диаграммы, такие как объект, пакет, время, взаимодействие были добавлены в UML. Новые функции были добавлены в диаграммы активности и последовательности. Диаграмма сотрудничества была переименована в диаграмму связи. Множество функций и изменений были внесены в существующие диаграммы. |
Апрель 2006 | 2,1 | Внесены исправления в UML 2.0. |
Февраль 2007 | 2.1.1 | Обновления были введены в UML 2.1. |
Ноябрь 2007 | 2.1.2 | UML 2.1.1 был переопределен. |
Февраль 2009 | 2,2 | В UML 2.1.2 исправлены ошибки. |
Май 2010 | 2,3 | UML 2.2 был пересмотрен, и в диаграммы компонентов были внесены незначительные изменения. |
Август 2011 | 2.4.1 | Изменения в классах, пакетах и стереотипах. UML 2.3 был пересмотрен с улучшенными функциями. |
Июнь 2015 | 2.5 | UML 2.4.1 был пересмотрен с незначительными изменениями. UML был сделан проще, чем раньше. Быстрое функционирование и создание более эффективных моделей были введены. Устаревшие функции были устранены. Модели, шаблоны были исключены как вспомогательные конструкции. |
Характеристики UML
- Это обобщенный язык моделирования.
- Он отличается от языков программирования, таких как Python, C, C ++ и т. Д.
- Это графический язык, который можно использовать для создания мощных элементов моделирования.
- Это связано с объектно-ориентированным проектированием и анализом.
- Он имеет неограниченное количество приложений даже за пределами индустрии программного обеспечения. Его можно использовать для визуализации рабочего процесса на фабрике.
Концептуальная модель
Прежде чем начать с концепции UML, необходимо понять основы концептуальной модели.
Концептуальная модель состоит из различных концепций, которые взаимосвязаны. Это помогает нам понять
- Что это за объекты?
- Как происходит взаимодействие для выполнения процесса?
Концептуальная модель требуется в UML. Вы должны понимать сущности и отношения между ними, прежде чем фактически моделировать систему.
Следующие объектно-ориентированные концепции требуются для начала с UML:
- Объект : это сущность реального мира. В одной системе доступно несколько объектов. Это фундаментальный строительный блок UML.
- Класс : класс – это не что иное, как контейнер, в котором поддерживаются объекты и их отношения.
- Абстракция : это механизм представления сущности без отображения деталей реализации. Он используется для визуализации поведения объекта.
- Наследование : это механизм расширения существующего класса для создания нового класса.
- Полиморфизм : это механизм представления объекта, имеющего несколько форм, которые используются для разных целей.
- Инкапсуляция : это метод связывания объекта и данных в единое целое. Это обеспечивает тесную связь между объектом и данными.
Выше также называются основными строительными блоками UML.
Что такое диаграмма UML?
Диаграммы UML являются результатом работы языка унифицированного моделирования. Это графическое представление классов, объектов и отношений между ними. UML-диаграмма – это модель, которая описывает часть системы. Он используется для определения функциональности или дизайна системы. Диаграмма должна быть четкой и лаконичной, чтобы зритель мог ее легко понять.
UML-диаграммы делятся на три категории:
- Структурная схема
- Поведенческая диаграмма
- Диаграмма взаимодействия
Структурные диаграммы
Структурные диаграммы используются для представления статического представления системы. Он представляет собой часть системы, которая составляет структуру системы. Структурная схема показывает различные объекты в системе.
Ниже приведены различные структурные схемы в UML:
- Диаграмма классов
- Диаграмма объектов
- Схема упаковки
- Диаграмма компонентов
- Диаграмма развертывания
Поведенческие диаграммы
Любая реальная система может быть представлена в статической или динамической форме. Система считается полной, если она выражается как статическим, так и динамическим способами. Диаграмма поведения представляет собой функционирование системы.
Диаграммы UML, которые имеют дело со статической частью системы, называются структурными диаграммами. Диаграммы UML, которые имеют дело с движущимися или динамическими частями системы, называются диаграммами поведения.
Ниже приведены различные поведенческие диаграммы в UML:
- Диаграмма деятельности
- Диаграмма вариантов использования
- Схема конечного автомата
Диаграммы взаимодействия
Диаграмма взаимодействия – это не что иное, как подмножество поведенческих диаграмм. Он используется для визуализации потока между различными вариантами использования системы. Диаграммы взаимодействия используются, чтобы показать взаимодействие между двумя объектами и то, как потоки данных внутри них.
Ниже приведены различные диаграммы взаимодействия в UML:
- Временная диаграмма
- Диаграмма последовательности
- Диаграмма сотрудничества
Подробное объяснение вышеприведенных диаграмм объясняется в следующих руководствах.
Инструменты UML
На рынке доступно множество инструментов для создания UML-диаграмм. Некоторые из них основаны на десктопе, а другие можно использовать онлайн. Ниже приводится список инструментов, которые можно использовать для создания моделей UML:
- Звезда UML
- Арго УМЛ
- диаметр
- Визуальная Парадигма
- U-модель
- Лаборатория UML
- Enterprise Architect
Мы будем использовать приложение Star UML для генерации UML-диаграмм.
Согласно спецификации вашего ПК. Скачайте любую версию приложения. Здесь мы собираемся выбрать вариант окон.
После загрузки приложения установите его со всеми параметрами по умолчанию. После установки запустите приложение Staruml на вашем ПК.
Привет, Хабр!
В этой статье мы начнем рассказ о том, как устроена внутри платформа «1С:Предприятие 8» и какие технологии используются при ее разработке.
Нативные приложения
- STL (в частности, строки, контейнеры и алгоритмы)
- множественное наследование, в т.ч. множественное наследование реализации
- шаблоны
- исключения
- умные указатели (собственная реализация)
Компоненты
- Разделение способствует лучшему проектированию, в частности лучшей изоляции кода
- Из набора компонентов можно гибко собирать разные варианты поставки:
- Например, инсталляция тонкого клиента будет содержать wbase, но не будет backend
- а на сервере wbase, наоборот, не будет
- оба варианта будут, конечно, содержать nuke и bsl
- Предоставляет фабричные методы, позволяющие создать класс из другой компоненты зная только его название (без раскрытия реализации)
- Предоставляет инфраструктуру умных указателей с подсчетом ссылок. За временем жизни SCOM-класса не нужно следить вручную
- Позволяет узнать реализует ли объект конкретный интерфейс и автоматически привести указатель на объект к указателю на интерфейс
- Создать объект-сервис, всегда доступный через метод get_service и т.д.
Этот макрос опишет специальный статический класс-регистратор, конструктор которого будет вызван при загрузке компоненты в память.
После это можно создать его экземпляр в другой компоненте:Для поддержки сервисов SCOM предлагает дополнительную, достаточно сложную инфраструктуру. Центральным в ней является понятие SCOM-процесса, который служит контейнером для запущенных сервисов (т.е. выполняет роль Service Locator), а также содержит привязку к локализуемым ресурсами. SCOM процесс привязывается к потоку ОС. Благодаря этому внутри приложения можно вот так получать сервисы:
Более, того переключая логические (SCOM) процессы привязанные к потоку, можно получить практически независимые с точки зрения информационного пространства приложения, выполняющиеся в рамках одного потока. Так устроен наш тонкий клиент, работающий с файловой базой — внутри одного процесса ОС находятся два SCOM-процесса, один связан с клиентом, а второй — с сервером. Такой подход позволяет унифицировать написания кода, который будет работать как на локальной файловой базе, так и в «настоящем» клиент-серверном варианте. Цена за такое единообразие — накладные расходы, но практика показывает, что они того стоят.
На основе компонентной модели SCOM реализована и бизнес-логика и интерфейсная часть 1С: Предприятия.
Пользовательский интерфейс
Кстати, об интерфейсах. Мы не используем стандартные контролы Windows, наши элементы управления реализованы напрямую на Windows API. Для Linux-версии сделана прослойка, работающая через библиотеку wxWidgets.
Библиотека элементов управления не зависит от других частей «1С:Предприятия» и используется нами еще в нескольких небольших внутренних утилитах.За годы развития 1С:Предприятие внешний вид контролов менялся, но серьезное изменение принципов произошло только один раз, в 2009 году, с выходом версии 8.2 и появлением «управляемых форм». Помимо изменения внешнего вида, фундаментально изменился принцип компоновки формы — произошел отказ от попиксельного позиционирования элементов в пользу flow-компоновки элементов. Кроме того, в новой модели элементы управления работают не напрямую с доменными объектами, а со специальными DTO (Data Transfer Objects).
Эти изменения позволили создать веб-клиент «1С:Предприятия», повторяющий С++ логику контролов на JavaScript. Мы стараемся поддерживать функциональную эквивалентность между тонким и веб клиентами. В том случае, когда это невозможно, например, из-за ограничений доступных из JavaScript API (например, возможности работы с файлами очень ограничены), мы часто реализуем нужную функциональность при помощи расширений браузеров, написанных на C++. На данный момент мы поддерживаем Internet Explorer и Microsoft Edge (Windows), Google Chrome(Windows), Firefox (Windows и Linux) и Safari (MacOS).Кроме того, технология управляемых форм используется для создания интерфейса мобильных приложений на платформе 1С. На мобильных устройствах отрисовка контролов реализована с использованием «родных» для операционной системы технологий, но уже для логики компоновки формы и реакции интерфейса используется тот же код, что и в «большой» платформе «1С:Предприятие».
Интерфейс 1С на ОС Linux
Интерфейс 1С на мобильном устройстве
Интерфейс 1С на ОС Windows
Интерфейс 1С — веб-клиентOpen source
Заключение
В статье мы коснулись нескольких основных аспектов разработки платформы «1С: Предприятие». В ограниченном объеме статьи мы затронули лишь некоторые интересные, на наш взгляд, аспекты.
Общее описание различных механизмов платформы можно посмотреть тут.
Какие темы были бы интересны Вам в следующих статьях?Как реализована мобильная платформа 1С?
Описание внутреннего устройства веб-клиента?
Или, может быть, Вам интересен процесс выбора фич для новых релизов, разработки и тестирования?В этой статье мы подробно познакомимся с синтаксисом языка программирования 1С, на примерах рассмотрим применение основных языковых конструкций, после чего Вы сможете вполне самостоятельно писать программные модули или дорабатывать уже имеющиеся. В статье будут описаны основные, наиболее применимые команды, а с остальными при желании вы всегда сможете ознакомиться в синтаксис-помощнике системы «1С:Предприятие» (режим Конфигуратора, меню Справка | Синтаксис-помощник) или в документации, предоставляемой фирмой «1С» вместе со своими программными продуктами.
В языке программирования 1С все операторы имеют два написания: русское и английское. К примеру, оператор Новый(“”) аналогичен по смыслу и действию оператору New(“”) . Обычно все же пишут код на одном языке (чаще русском), однако не возбраняется (хотя и считается плохим стилем программирования) смешивать оба языка в одном модуле. Мы в описании языковых конструкций будем приводить только русский вариант их написания.
Каждая языковая конструкция будет описана в следующем формате:
ЭлементЯзыка(Параметр1, Параметр2,…, ПараметрN) [КлючевоеСлово]
Здесь:
- Параметр1, Параметр2, …, ПараметрN — список параметров;
- КлючевоеСлово — дополнительное ключевое слово, которое может присутствовать или отсутствовать в той или иной языковой конструкции.
Если у элемента языка нет параметров, скобки опускаются. Квадратные скобки [ ] означают, что параметр или ключевое слово, заключенные в них, необязательны и могут как присутствовать, так и отсутствовать.
Если среди элементов необходимо выбрать только один, они будут разделены следующим образом: Элемент1|Элемент2|Элемент3.Кроме того, будут представлены примеры программного кода с использованием описываемой языковой конструкции с подробными комментариями.
ПРИМЕЧАНИЕ
В таких текстовых вставках будет приведена дополнительная информация, замечания автора, упоминание о родственных или связанных с рассматриваемой конструкцией элементах языка.А КАК СДЕЛАТЬ?
В таких текстовых вставках будут представлены примеры использования рассматриваемой языковой конструкции в варианте «Вопрос — ответ»: ставится задача и дается способ ее решения. Программный код, приведенный здесь, является типовым способом решения задачи и может быть использован начинающими программистами в собственных наработках.Приведенные примеры рекомендуется тут же «проигрывать» на практике. Для этого мы сейчас создадим нашу первую внешнюю обработку, в которой и станем закреплять на практике полученные знания.
Наша первая обработка
В упрощенном определении обработка — это программа, написанная на языке 1С и выполняемая в системе «1С:Предприятие».
Обработка может быть как внутренней, входящей в конфигурацию и присутствующей в дереве конфигурации в разделе Обработки, так и внешней, имеющей расширение epf и запускаемой через пункт меню Файл | Открыть.
Мы будем экспериментировать на внешней обработке. Давайте создадим ее. Для этого в режиме Конфигуратора мы должны выбрать команду меню Файл | Новый и в открывшемся списке выбрать вариант Внешняя обработка. Откроется окно создания новой обработки:
Рисунок “Создаем внешнюю обработку”
Обработка, как и справочник или документ, может иметь реквизиты, несколько форм и печатных форм-макетов. В нашем случае мы пока создадим самую простенькую обработку с одной формой. Нам ее вполне хватит. Дадим нашей обработке имя:
Рисунок “Задаем имя и примечание”
Имя (идентификатор) обработки, как и имя любого объекта 1С, будь то имя справочника, документа или переменной, не должно содержать пробелов. Регистр не учитывается, т. е. НашаПерваяОбработка и нашаперваяобработка — это один и тот же объект, просто первое читается удобнее.
Синоним — это представление имени, его создают для того, чтобы в окнах системы «1С:Предприятие» вместо имени пользователь мог видеть название объекта в привычном и более читаемом виде. При этом обращение в программном коде, конечно, идет по имени, а не по синониму. Обратите внимание, что при вводе имени обработки синоним заполняется автоматически с правильным разделением слова по прописным буквам. Если бы мы назвали обработку «нашаперваяобработка», это бы не сработало.
Комментарий предназначен для записи дополнительной информации об объекте. Теперь создадим форму обработки. Для этого щелкнем правой кнопкой мыши на пункте Формы окна создания обработки и выберем пункт Добавить. Откроется окно конструктора формы обработки:
Рисунок “Конструктор формы обработки”
Здесь мы также можем задать имя, синоним и комментарий — на этот раз для формы, указать тип формы (обычная или управляемая, т. е. для работы через Интернет), определить положение командной панели.
Оставим все по умолчанию и нажмем кнопку Готово.
Готовая пустая форма содержит внизу командную панель, на которой расположены три кнопки:Рисунок “Так выглядит пустая форма обработки”
Выполнить (запускает обработчик выполнения обработки) , Закрыть (закрывает обработку) и кнопку с точками , предназначенную для добавления новых кнопок.
Ниже командной панели расположены вкладки, относящиеся к создаваемой форме:
- Диалог (собственно форма с элементами, размещенными на ней),
- Модуль (здесь пишется программный модуль формы)
- и вкладка со списком реквизитов.
Программный модуль формы сразу после создания выглядит так, как показано на картинке:
Рисунок “Модуль формы новой обработки с одной-единственной пустой процедурой”
На вкладке Модуль присутствует одна-единственная процедура-обработчик нажатия кнопки Выполнить, расположенной на форме. Обработчик пока пуст, в нем только комментарий, который не является исполняемым программным кодом. Поэтому, если мы откроем обработку в режиме «1С:Предприятие» через пункт меню Файл | Открыть и нажмем кнопку Выполнить, то никакие действия не произойдут. Процедуру обработчика (равно, как и другие процедуры модуля) нам предстоит писать самим.
Теперь давайте рассмотрим, какие бывают программные модули и какова их внутренняя структура.Какие бывают модули 1С Предприятие 8.3?
Программные модули в конфигурации системы «1С:Предприятие» не являются самостоятельными программами (за исключением внешних обработок, представляющих собой отдельные файлы). Каждый модуль привязывается к определенному моменту работы системы «1С:Предприятие».
Система запущена — запускается содержимое одного модуля. Открыли какой-нибудь справочник — запускается другой модуль. Щелкнули по кнопке на форме — выполняется процедура, «подвешенная» на эту кнопку и находящаяся в модуле формы справочника. Таким образом, программный код в системе «1С:Предприятие» является контекстно-зависимым. Вместе с тем программные модули часто связаны между собой и могут быть доступны из других модулей системы.
Существуют области видимости программных элементов, процедур и функций, иначе называемые контекстом выполнения программного модуля. Таких контекстов два:
- Глобальный контекст. Образуется значениями констант, перечислений, регистров и прочих объектов метаданных, определенных в дереве конфигурации, системными переменными, процедурами и функциями, а также переменными, процедурами и функциями, находящимися в общих модулях конфигурации, объявленными с ключевым словом Экспорт. Данные, образующие глобальный контекст, доступны из любых других модулей конфигурации.
- Локальный контекст конкретного модуля. Образуется значениями переменных, процедур и функций, находящимися в конкретном программном модуле. Эти значения являются локальными и доступны только внутри модуля, в котором находятся. Исключение— использование в качестве параметров. Например, переменные определены в каком-либо модуле, а потом из этого модуля следует вызов процедуры (или функции), находящейся в одном из общих модулей. В этом случае значения локальных переменных могут быть использованы в качестве параметров.
В отличие от «1С:Предприятие 7.7» в «1С:Предприятие 8.3» имеется больше различных типов модулей:
- Общие модули. Процедуры и функции, помещенные в такие модули, доступны из любого другого модуля. То есть, при проектировании, скажем, документа, мы всегда можем обратиться к любому из общих модулей. Расположены они в разделе дерева конфигурации Общие | Общие модули .
- Модуль формы. Предназначен для обработки действий пользователя с объектом, которому принадлежит форма. Например, если мы поместим на форму кнопку Выполнить, то обработчик нажатия этой кнопки помещается в модуль формы. В созданной нами обработке для экспериментов мы уже заходили в модуль формы этой обработки.
- Модуль объекта. Этот модуль предназначен для обработки общих событий объекта. Например, для документа здесь будут располагаться процедуры записи и проведения документа, а также отмены проведения. Для того чтобы открыть модуль объекта, расположенного в дереве конфигурации, нужно щелкнуть на нем правой кнопкой мыши и выбрать пункт Открыть модуль объекта . Для того чтобы открыть модуль нашей внешней обработки для экспериментов (не путаем с модулем формы), нужно в окне обработки нажать кнопку Действия и выбрать пункт Открыть модуль объекта . Для нашей обработки этот модуль пуст.
- Модуль приложения. Срабатывает в момент запуска приложения (загрузки конфигурации) и завершения его работы. Сюда помещают программный код, который должен быть выполнен при запуске/закрытии приложения. Модуль доступен в контекстном меню, по щелчку правой кнопкой мыши в самом верхнем пункте дерева конфигурации (там, где название конфигурации). Существуют две разновидности: модуль обычного приложения и модуль управляемого приложения. Модуль обычного приложения предназначен для обычной работы (в режиме «толстого» клиента), режим управляемого приложения — в основном для работы через Интернет (веб-приложение, «тонкий» клиент или «толстый» клиент в режиме управляемого приложения).
- Модуль сеанса. Это модуль, в котором записаны параметры начала сеанса работы в системе «1С:Предприятие». Содержит единственную процедуру УстановкаПараметровСеанса(). Модуль доступен в контекстном меню по щелчку правой кнопкой мыши в самом верхнем пункте дерева конфигурации (там, где указано название конфигурации).
- Модуль внешнего соединения. Назначение модуля аналогично назначению модуля приложения, но только в режиме COM-соединения. Модуль доступен в контекстном меню по щелчку правой кнопкой мыши в самом верхнем пункте дерева конфигурации (там, где указано название конфигурации).
- Модуль менеджера объекта. Существует для многих объектов конфигурации. Модуль предназначен для переопределения стандартного события выбора, которое возникает в момент ввода по строке. Модуль доступен в контекстном меню по щелчку правой кнопкой мыши по объекту в дереве конфигурации. В стандартных конфигурациях для большинства объектов пуст (не используется).
- Модуль команды.Команды — это объекты, подчиненные объектам дерева конфигурации. У каждой команды есть модуль команды, где можно описать предопределенную процедуру ОбработкаКоманды(), которая будет срабатывать для этой команды. Если мы пройдемся по дереву конфигурации, то увидим, что для каждого из объектов: справочников, документов, перечислений и т. д. имеется пункт Команды. По щелчку на нем правой кнопкой мыши мы можем добавить новую команду и задать для нее обработчик ОбработкаКоманды().
В статье будет рассматриваться работа с модулями формы, объекта, а также общими модулями, остальные модули довольно-таки узкоспециализированы, в рабочих конфигурациях модифицируются не так часто и, как правило, не являются постоянно используемыми в работе программиста.
Структура программного модуля
Программный модуль делится на три части.
- Раздел описания переменных. Здесь мы описываем переменные, с помощью оператора Перем. Этот раздел размещается от начала текста модуля до первого оператора Процедура или Функция или любого исполняемого оператора. В общих модулях этот раздел отсутствует.
- Раздел процедур и функций. Здесь пишутся все процедуры и функции модуля. Этот раздел размещается от первого оператора Процедура или до любого исполняемого оператора вне процедур или функций модуля.
- Раздел основной программы. Здесь пишутся команды и языковые конструкции, не относящиеся ни к одной из процедур и функций модуля. Этот раздел размещается от первого исполняемого оператора вне процедур или функций модуля до конца модуля. Здесь могут находиться только исполняемые операторы. Раздел основной программы исполняется в момент запуска модуля на выполнение, поэтому есть смысл помещать сюда, например, инициализацию переменных конкретными значениями. На практике раздел основной программы обычно только называется так — основную часть модуля занимают процедуры и функции, а этот раздел может отсутствовать вовсе. В общих модулях раздел основной программы не присутствует никогда.
Наличие всех частей модуля не является обязательным. Например, переменные могут объявляться непосредственно в процедурах (отсутствует раздел описания переменных). Или никакие команды не выполняются в момент выполнения модуля (отсутствует раздел основной программы). Наконец, модуль просто может состоять из одной или нескольких процедур или функций, т. е. второго раздела (кстати, на практике чаще всего так и бывает). И более того, в некоторых объектах модуль вообще может быть пуст.
Читайте также: