Русский
Русский
English
Статистика
Реклама

Uml

UML для самых маленьких диаграмма классов

21.07.2020 02:06:53 | Автор: admin


Аве, Кодер! Диаграмма классов UML иллюстрирует структуру системы, описывая классы, их атрибуты, методы и отношения между объектами.

Даже самые малые детки знают, что UML происходит от Unified Modeling Language, если по русски, то унифицированный язык моделирования, который, как гласит легенда, разработали, когда серьезные дяди и тети в конец задолбались плавать в разнообразии кружочков, черточек и облачков.

Для тех, кому лень читать:



Главное действующее лицо



Для начала напомним себе что такое класс? Если в двух словах, то класс представляет собой шаблон для создания объектов,
обеспечивающий начальные значения состояний: инициализацию полей-переменных и реализацию поведения полей и методов.

По сути, класс описывает то, каким объект может быть.

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

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


Каждый параметр в методе может также иметь описание направленности метода: in, out, inout.
На этой иллюстрации, method1 использует p1, как входной параметр и значение p1, каким-то образом, используется методом, а метод не изменяет p1.
Method2 принимает p2, как параметр ввода/вывода, значение p2, каким-то образом, используется методом и принимает выходное значение метода, но сам метод также может изменять p2.
Method3 использует p3, как выходной параметр, иными словами, параметр служит хранилищем для выходного значение метода.

Перспективы диаграммы классов в жизненном цикле разработки программного обеспечения


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


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


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


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

Типы отношений


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

Ассоциация.

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

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

Например, один студент может учиться у множества преподавателей.
Но и преподаватель может учить множество студентов.

Наследование

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

Реализация

Обычно, под этим подразумевается отношение интерфейса и объектов, реализующих этот интерфейс.
Например, интерфейс Owner имеет методы для покупки и продажи частной собственности, а отношения классов Person и Corporation, реализующих этот интерфейс, на диаграмме будут обозначаться в виде пунктирной линии со стрелкой по направлению к интерфейсу.

Зависимость

Объект одного класса может использовать объект другого класса в своем методе.
Если объект не хранится в поле класса, то такой вид межклассовых отношений моделируется как зависимость.
Зависимость, по сути, является специальным случаем ассоциации двух классов, в этом случае, изменения в одном классе неумолимо повлекут за собой изменения в другом.
Например, у класса Person есть метод hasRead с входным параметром book, который возвращает true, если, к примеру, человек прочитал книгу.
Зависимость обозначается пунктирной линией со стрелкой, обращенной к классу, от которого зависят, например, методы другого класса.

Агрегация

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

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

Композиция

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

Финалочка


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

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

Аве!
Подробнее..

Представление модели предметной области (МПО) и точек интеграции

16.01.2021 14:23:21 | Автор: admin
Как известно, описание архитектуры состоит из множества представлений, для соответствующих точек зрения, интересов и заинтересованных сторон.

В этой статье я расскажу о способе создания представления (диаграммы) модели предметной области (МПО), дополненное связями с точками интеграции, на базе которых построена функциональность системы: хранимыми процедурами, функциями и веб-сервисами. Таким образом, данное представление хорошо подойдёт проектам с большим количество точек интеграциий и поможет разработчикам и аналитикам быстрее ориентироваться в проекте, порой даже не заходя в код.

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

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

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

Представление сущности МПО



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

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

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

Методы бизнес-модели содержат все возможные действия, над данной моделью. Это могут быть CRUD и какие либо ещё возможные методы. Выделение метода зачастую ориентируется на точку интеграции, которая используется в данном методе. Есть смысл так же выносить производные методы, для понимания предметной области.

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

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

image
Рисунок 1. МПО на примере одной сущности

Пример того, как описывается одна сущность МПО изображён на Рисунке 1.

Представление МПО



Итоговое представление МПО может выглядеть примерно как на рисунке. В примере я привёл значительно упрощённую модель. В реальной модели было в 10-15 раз больше сущностей с значительно большим количеством методов и точек интеграции. Однако даже с большими размерами МПО было достаточно просто ориентироваться. Свою роль сыграливозможностям Enterprise Architect и Visual Paradigm, однако в первую очередь помог логический поиск Функциональность->Сущность->Метод->Точка интеграции

image
Рисунок 2. Пример полного представления МПО.

На рисунке 2 изображён пример полного представления МПО. По этому рисунку уже можно сложить мнение о том, какая функциональность реализована в приложении.

Как представление МПО + точки интеграции может упростить разработку



Для наглядности я приложил диаграмму компонентов (Рисунок 3), распределённых по приложениям инфораструктуры проекта:
UIWebSite
MainOnlineBackendService
PCIDSSOnlineBankLogicService

Эта диаграмма в статье только для того, чтобы дать представление о количестве слоёв в стэке вызова, которое может быть между элементами управления UI и интеграционой точкой, что влияет на анализ стэка.

image
Рисунок 3. Диаграмма компонентов.

Задача 1:
Допустим, что у нас стоит задача модифицировать функциональность открытия счёта и мы не знакомы с кодом проекта. В такой задаче может прийтись исследовать стэк вызова, а учитывая, что в каждом приложении существует свой набор компонентов, стэк вызова при клике на кнопку Открыть счёт может состоять из 8 уровней:
1 ReactUI
2 RestApiController
3 AccountCachedController
4 AccountServiceWrapper
5 MainOnlineBackendServiceImplementation
6 AccountServiceWrapper
7 OnlineBankLogicServiceImplementation
8 sheme1: sp_createAccount

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

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

Задача 2:
Допустим, что у нас стала возникать ошибка при выполнении какого-либо действия. Для проектов с множеством интеграций частой причиной ошибок является ошибки внешних систем, например было выполнено обновление хранимой процедуры, отключение/недоступность веб-сервиса. На уровне пользователя такие ошибки совсем не очевидны и возникает ощущение, что проблема конкретно в системе, с которой работает пользователь. Чтобы локализовать ошибку чаще всего необходимо проанализировать стэк вызова.

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

Это две типовые распространённые задачи, при которых требуется находить точки интеграции.

Задача 3:
Другое множество, где диаграмма была полезна это различные вопросы:
какая внешняя система отвечает за ту или иную функциональность
какая точка интеграции используется для выполнения того или иного действия
где получить номер карты по её Id
кто отвечает за функционаность со стороны другой системы

Задача 4:
Вы исследуете систему и вам необходимо накапливать информацию о всех понятиях и функционале системы. Диаграмма помогает это выполнять в достаточно локаничном виде. В дальнейшем такая декомпозиция/композиция позволяет спроектировать архитектурные слои
Подробнее..

Что находится между идеей и кодом? Обзор 14 диаграмм UML

29.06.2020 12:20:00 | Автор: admin


Аве Кодер!

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


UML это сокращение от Unified Modeling Language, и, как мы знаем, он является стандартизированным языком моделирования, состоящим из интегрированного набора диаграмм, разработанных, чтобы помочь разработчикам систем и программного обеспечения в определении, визуализации, конструировании и документировании артефактов программных систем, а также, к примеру, для бизнес-моделирования.

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

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

UML не возник на пустом месте, ему предшествовали несколько значимых событий, личностей и методологий. Например:
  • Техника объектного моделирования OMT [James Rumbaugh 1991], которая была лучшей для анализа информационных систем с большим объемом данных.
  • Booch [Grady Booch 1994] отлично подходит для разработки и реализации. Грэди Буч много работал с языком Ада и был крупным игроком в разработке объектно-ориентированных методов для языка. Хотя метод Буча был сильным, нотация была воспринята менее хорошо, например, в его моделях преобладали формы облаков, что выглядело не очень аккуратно.
  • OOSE (объектно-ориентированная программная инженерия [Ivar Jacobson 1992]) модель, известная как модель прецедентов это мощная методология для понимания поведения всей системы, область, где ООП традиционно была слабой.

В 1994 году Джим Рамбо, не путать с Джоном Рэмбо, хотя Джим тоже был крут, потому что был, на секундочку, создателем вышеупомянутой техники объектного моделирования, ошеломил мир программного обеспечения, когда он покинул General Electric и присоединился к Грэди Бучу в Rational Corp. Цель партнерства состояла в том, чтобы объединить их идеи в единый унифицированный метод (рабочее название для метода действительно было Единый метод).

К 1995 году создатель OOSE, Ивар Якобсон, также присоединился к Rational, и его идеи (в частности, концепция прецедентов) были включены в новый унифицированный метод, который теперь называется Unified Modeling Language.
В противовес всем известной Банде Четырех, Команда Румбо, Буча и Якобсона известна как Три Амигоса.

На UML также повлияли другие объектно-ориентированные нотации:
  • Меллор и Шлаер [1998]
  • Coad и Yourdon [1995]
  • Вирфс-Брок [1990]
  • Мартин и Оделл [1992]


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

Почему UML?
По мере того как стратегическая ценность программного обеспечения возрастала для многих компаний, отрасль искала методы для автоматизации производства программного обеспечения, а также для повышения качества и сокращения затрат и времени выхода на рынок.
Эти методы включают технологию компонентов, визуальное программирование, шаблоны и структуры.
Компании также ищут методы для управления сложностью систем по мере увеличения их масштаба.
В частности, они признают необходимость решения повторяющихся архитектурных проблем, таких как физическое распределение, параллелизм, репликация, безопасность, балансировка нагрузки и отказоустойчивость.
Кроме того, разработка под Web хоть и упрощает некоторые вещи, в целом, она усугубляет эти архитектурные проблемы.
Унифицированный язык моделирования (UML) был разработан для удовлетворения этих потребностей.

Основные цели дизайна UML:
  • Предоставить пользователям готовый, выразительный язык визуального моделирования, чтобы они могли разрабатывать и обмениваться осмысленными моделями.
  • Обеспечить механизмы расширяемости и специализации для расширения основных понятий.
  • Быть независимым от конкретных языков программирования и процессов разработки.
  • Обеспечить формальную основу для понимания языка моделирования.
  • Поощрять рост рынка объектно-ориентированных инструментов.
  • Поддержка высокоуровневых концепций разработки, таких как совместная работа, структуры, шаблоны и компоненты.
  • Интегрировать лучшие практики.


Диаграммы UML подразделяют на два типа это структурные диаграммы и диаграммы поведения.



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

  • Диаграмма составной структуры
  • Диаграмма развертывания
  • Диаграмма пакетов
  • Диаграмма профилей
  • Диаграмма классов
  • Диаграмма объектов
  • Диаграмма компонентов


Диаграммы поведения показывают динамическое поведение объектов в системе, которое можно описать, как серию изменений в системе с течением времени. А к диаграммам поведения относятся:

  • Диаграмма деятельности
  • Диаграмма прецедентов
  • Диаграмма состояний
  • Диаграмма последовательности
  • Диаграмма коммуникаций
  • Диаграмма обзора взаимодействия
  • Временная диаграмма


Теперь пару слов о каждой из них

Диаграмма классов

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

Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:

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



Диаграмма компонентов

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



Диаграмма развертывания

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



Диаграмма объектов

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



Диаграмма пакетов

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



Диаграмма составной структуры

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

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



Диаграмма профилей

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



Диаграмма прецедентов

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



Диаграмма деятельности

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



Диаграмма состояний

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



Диаграмма последовательности

Диаграмма последовательности моделирует взаимодействие объектов на основе временной последовательности. Она показывает, как одни объекты взаимодействуют с другими в конкретном прецеденте.



Диаграмма Коммуникации

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



Диаграмма обзора взаимодействия

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



Временная диаграмма

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




Зачем в UML столько диаграмм?

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



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

Для тех, кому лень читать: youtu.be/0I9aIP5gKCg

Аве!
Подробнее..

UML. Взгляд со стороны или Как UML удерживает аналитиков в прошлом

01.07.2020 16:06:10 | Автор: admin
Данная статья является переработанным материалом моего доклада на конференции Analyst Days 6 (2017).

Статья посвящена UML и особенностям его применения в настоящее время. Немного исторических сведений, совсем немного, только основные моменты:

  • UML зародился в 90-х годах как результат работы по создания языка объектно-ориентированного моделирования.
  • Спецификация 1.0 вышла в 1997 году.
  • Спецификация 2.0 вышла в 2005 году.
  • На сегодняшний день версия UML 2.5, развитие получили несколько профилей, такие как SysML и SoaML.

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

И как следствие: Аналитики используют концепцию описания программных систем, которая была заложена более 20 лет назад. Сама концепция хорошая, но нужно соотносить ее с местом и контекстом применения.

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

  • Все методики использования UML ходят вокруг Use Case Driven Development.
  • Моделям на UML не хватает целостности. Выбранный подход раздельного описания аспектов структуры и поведения, уровней бизнеса и приложений усложняет восприятие моделей в целом.
  • UML является объектно-ориентированным языком, это затрудняет с помощью него выражать другие концепции.

Про подход Use Case Driven Development я ничего говорить не буду, одно из воплощений его это Rational Unified Process. Далее я расскажу про последние два пункта.

Аспекты представления


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



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



Уровни представления


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



А что будет делать аналитик, когда захочет сопоставить описание предметной области и модели системы?

Он опять начинает строить гибридные диаграммы, таблицы связей и трассировки.

В результате опять получается множество диаграмм и таблиц.



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

Сервис-ориентированная подход


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

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

Для простой формализации сервис-ориентированном подхода нам потребуются 2 абстракции:
  • Процесс поток управления между/над сервисами. Так же нужно сказать, что процесс представляет собой последовательность действий, которые вместе достигают определенного результата.
  • Сервис элемент поведения, обеспечивающий определенную функциональность в ответ на запросы от субъектов или других сервисов. Сервис предоставляет или поддерживает возможности, имеет явно определенный интерфейс и управляется явно.

Посмотрим, как это моделируется на SoaML. Заодно сравним, как будет отличаться объектно-ориентированное моделирование на UML и сервис-ориентированное моделирование на SoaML.

Человек и Магазин


Задача простая, описать модель покупки товара в магазине.

Объектно-ориентированный подход, я думаю, всем понятен и прост. Чтобы не тратить время, не будем рассматривать бизнес-уровень. Думаю, все могут представить в голове советующий Use Case и его детализацию в виде диаграммы деятельности или диаграммы последовательности.



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



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



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



В рамках данного сервиса: Продавец выступает как provider, а Покупатель как consumer.
Продавец как поставщик предоставляет одну операцию продать. Бизнес-анализ закончен, переходим на уровень системы.

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



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

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

Получаем следующие сервисные интерфейсы:
  • Желание продавать, который наследуется от интерфейса Умеющий продавать;
  • Потребность покупать, который зависит от интерфейса Умеющий продавать.



Теперь можно представить модель целевого сервиса в виде диаграммы композитной структуры.



Сравним результаты объектно-ориентированного моделирования на UML и сервис-ориентированного моделирования на SoaML.



Визуально вся разница вот в этих маленьких квадратиках на границе компонентов. Я отметил их красным цветом.Неужели это вся разницы?

Разница между объектно-ориентированным и сервис-ориентированным моделирование на самом деле есть, просто SoaML свел всё к объектам. Но об этом позже.

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



Что же не так, по моему мнению, с SoaML.

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

Во-вторых: Сервис описывается как объект структуры, это нехорошо. В русской речи распространена фраза Поставщик представляет сервис, вот это компонент-ориентированный подход, который реализован в SoaML.

Но в случае с сервис-ориентированной парадигмой правильнее говорить Поставщик оказывает сервис. А если по другому перевести Сервис на русский язык, то всё сразу встает на свои места: Поставщик оказывает услугу.

С этой точки зрения Сервис это не Объект, это Поведение.

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

Парадигмы


Вернемся к UML. UML посредством своей парадигмы пытается описать другие парадигмы.



И если с компонентно-ориентированной парадигмой всё получается, она может быть представлена как логическое продолжение объектно-ориентированной. То с сервис-ориентированной получилось нехорошо.
В данном случае выражать одну парадигму через другую неудачная идея.
Использование такой концепции я продемонстрировал с SoaML на примере задачи Человек и Магазин.

Относится к парадигмам лучше как обозначено ниже.



Продемонстрирую, чем отличается сервис-ориентированное моделирование, от объектно-ориентированного.

Человек и Собака


Задача простая: Нужно построить простую модель взаимодействия, в которой Человек гуляет с Собакой. Данную задачу не задумываясь, наверное, решит любой студент технического факультета.
В школах и универах на соответствующих специальностях объектно-ориентированное программирование является обязательным.
Объектно-ориентированный подход представлен ниже.



А как будет выглядеть модель с сервис-ориентированным подходом? Не знаю, ответит ли такой вопрос студент.

Вот что я хотел бы получить. (Подумай сам, потом открой)


Нужно понимать, что это простая задача и это простая модель. Но она отражает суть сервис-ориентированного подхода.
Человек предоставляет (оказывает) для Собаки сервис (услугу) Гулять.


Можно вспомнить историю объектно-ориентированного программирования.
Как к нему скептически относились в начале его появления даже очень авторитетные люди, такие как Эдсгер Дейкстра и Никлаус Вирт.
И до сих пор некоторые люди считают ООП недостойным внимания.

Ну так вот, данная модель тоже может вызвать усмешки. Дело в том что сервис-ориентированная парадигма не имеет достаточной поддержки на начальном уровне программирования и проектирования.
Для программистов поддержка осуществляется только фреймворками, например, Java Enterprise Edition или Spring. Думаю, что программисты добираются до них с головой, уже отформатированной под объектно-ориентированный подход.
Аналитики строят свое представление о сервис-ориентированной архитектуре и проектирование по статьям в интернете, которые по-разному понимают, что это такое, а некоторые статьи без глубокого погружения в специфику и технические детали вообще малопонятны. В результате аналитики возвращаются к общепринятым Use Case между системой и пользователями. Распространено также, что архитектура системы и ее компонентный состав уже зафиксированы архитектором или обусловлены выбранной платформой. И тогда аналитики опять просто описывают Use Case между системой и пользователями.

Сравните объектно-ориентированный подход и эту, казалось бы, смешную, где Человек оказывает Собаке услугу Гулять.
Когда она перестанет быть для вас смешной, а будет смешным казаться объектно-ориентированный подход, где Человек реализует метод гулять, на вход которому подается Собака!!! Вот тогда к вам пришло понимание сервис-ориентированной парадигмы.

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

Еще один момент: В этом примере я ввел новое понятие Сервис.
При этом я пока четко не определил правила его использования, но оно отличается от того что в SoaML. Тут нужно быть аккуратным, не стоит этим сильно увлекаться, так как такого рода расширения относятся к метамоделированию. Может так получиться, что создаваемые модели окажутся противоречивыми и малопонятными.

Вместо заключения


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

Перевод UML умер, а никто и не заметил?

06.06.2021 16:09:40 | Автор: admin

UML, нам будет тебя не хватать
Unified Modelling Language (UML), разработанный Rational Software и принятый в качестве стандарта Object Management Group (OMG) в 1997 году, призван был стандартизировать множество различных типов графических нотаций, принятых в отрасли разработки ПО.

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

Откровением для меня стала формальная семантика, связанная с UML Activity Diagrams. Я не мог терпеть неформальные схемы Visio из-за множества неопределённостей в них. Например, что означают две стрелки, исходящие их прямоугольника: выбор или разделение потока на два параллельных пути? Аналогичный пример: две стрелки, указывающие на один прямоугольник, означают, что действие начинается сразу после достижения первым потоком прямоугольника? А может, это OR, XOR или AND? В общем, смысл вы поняли. UML решает эту проблему благодаря введению чёткой и недвусмысленной семантики.


Игра была нечестной изначально: правильного ответа нет

Я по-настоящему вкладывал душу в UML:

  • Я чертил схемы для собственных решений с 2004 по 2015 годы для семи разных работодателей и клиентов почти исключительно с помощью UML.
  • Я проводил буткемпы по UML (для бизнес-аналитиков) у двух крупных клиентов.
  • В качестве кандидатской диссертации я определил ключевое множество дискретной математики, являющееся фундаментом для большинства структурных и поведенческих моделей UML. Я даже написал на Haskell инструмент на основе GraphViz для визуализации этой математики в графическом UML.

Спустя несколько лет, примерно в 2015 году, я осознал, что практически перестал пользоваться UML, как и остальные мои коллеги, а также почти все клиенты из списка Fortune 500, которых я консультировал в последнее время. Что же произошло?

Я знаю: это была смерть от тысячи порезов. И нет, UML не убило бизнес-сообщество из-за его сложности или строгости. Напротив, людям из бизнеса нравилась возможность чётких и недвусмысленных коммуникаций при помощи нескольких новых символов. Айтишники возвысили UML (в своё время этим занимался и я), и они же стали причиной его падения.

Но жертвой стал не UML сам по себе. Если откровенно, UML стал просто побочной потерей. Настоящая резня развернулась в сфере разработки требований, включающей в себя бизнес-аналитику и проектирование. Убийцей стал Agile, а его отравленными стрелами были user stories.

В модели, куда на входе засовывают user stories, а на выходе получают демо (или feature production release), больше нет места для содержательного структурного анализа задач.

В современном дивном новом мире понимание напрямую кристаллизуется в код, готовый к продакшену. Даже моделирование бизнес-структур, по сути, было убито родственной Agile дисциплиной: Domain Driven Design (DDD). Ограниченные контексты инкапсулируют (заметают под ковёр) сложность, чтобы энтерпрайз мог масштабироваться на команды на две пиццы. Компании, использующие BDD и требующие от своих рабочих групп писать спецификации Cucumber, имеют здесь перевес, но этим занимаются очень немногие бизнесы.

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

Вы уже должны были понять: дело не в каких-то недостатках UML. Мы просто отказались от бизнес-анализа и формальных спецификаций, поэтому перед нами встаёт новый вопрос: чем пользоваться вместо UML?


Пример масала-диаграммы

Хотя некоторые используют легковесные техники моделирования наподобие C4, большинство применяемых сегодня диаграмм относятся к типу, который я несколько пренебрежительно называю масала-диаграммами. В конце концов, почему бы не назвать так диаграммы, которые я и сам делаю? Почему масала? Потому что они неформальные; они одновременно покрывают несколько размерностей, они могут быть и структурными, и поведенческими, логическими и физическими. Часто они являются мешаниной визуализаций архитектурной модели 4+1.


Как готовить масала-диаграмму

Системы стоимостью в миллионы долларов, от которых зависят наши жизни и финансы, создаются, финансируются и реализуются полностью на основе этих масала-диаграмм, которые часто не содержат ничего лишнего, кроме нескольких эпиков и user stories.

Автор, ну архитектура ипотечной системы моего банка уж точно не была спроектирована на основе этих ваших ужасных масала-моделей!

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

Неужели мир сошёл с ума? Нет мы просто отказались от инженерного проектирования ПО. Теперь это просто авантюра с кодом. Я не говорю, что те, кто пишет ПО, сами не являются инженерами; чаще всего, это не так. Смысл в том, что на организационном уровне ПО больше не проектируется, как это делается в других сферах, например, в машиностроении. Boeing никогда бы не заказал у Rolls Royce реактивный двигатель на основе подобной неформальной масала-диаграммы.

Однако у масала-диаграмм есть своё предназначение. Если использовать их там, где им место, то они прекрасны. Видите ли, это не спецификации. Их цель вызывать эмоции. Масала-диаграммы ценны, когда нужно вызвать радость в сердце руководителя, для которого они предназначены.

Как бы я ни спорил с моими друзьями из лагеря Agile, я не могу остаться слепым к счастью людей. Мои клиенты и коллеги не только просят больше масала-диаграмм, но и настаивают, чтобы я делал их ещё более масала (чтобы я объединял в них больше архитектурных размерностей!). Зачем же этому противиться?

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



На правах рекламы


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

Присоединяйтесь к нашему чату в Telegram.

Подробнее..

Перевод Как построить четкие модели классов и получить реальные преимущества от UML. Часть 4

01.03.2021 12:17:20 | Автор: admin

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

Настало время обсудить ещё и плохую модель, а также её ключевые отличия от хорошей

Плохая модель классов

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

Плохая модельПлохая модельХорошая модель

Понадобится нам для сравнения с плохой моделью

Хорошая модельХорошая модель

Здесь у нас та же самая область применения, но совершенно другая модель. Вот что сразу видно:

  1. Меньше классов и отношений

  2. Более короткие и неполные названия связей

  3. Нет ссылочных атрибутов или тегов идентификаторов

  4. Менее точные (ориентированные на реализацию) типы данных по атрибутам

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

Меньше элементов модели

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

А ещё такая модель будет требовать от программиста (или компилятора) зарезервированного места для заведомо ненужного атрибута. В принципе, это не такая уж проблема, если у вас немного диспетчеров. А если их тысячи? А если мы при этом оставили элементы вида не применимо в большом количестве классов? Для некоторых систем наличие сотен тысяч экземпляров обычное дело, это всего лишь один из вариантов того, как более компактная модель приводит к менее эффективному коду. На практике можно встретить много случаев, когда более детализированная и крупная модель несёт в себе ДНК, которая нужна для более точной реализации правил приложения.

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

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

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

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

Более короткие имена

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

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

Так как имя роли часто совпадает с именем связанного класса, их можно смело удалять, это не уменьшит выразительность модели. Авиадиспетчер и контролер это одно и то же? ОК, так и запишем.

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

Когда аналитик помещает точную глагольную фразу с обеих сторон каждой связи, он вынужден тщательно рассматривать мощность связи и обусловленность с каждой стороны. Это критично именно здесь выражены многие правила. Следует избегать общих, всеохватывающих глагольных фраз, таких как содержит, является группой, имеет и мое любимое связано с. Просто погуглите композиция и агрегация, чтобы понять, насколько легкомысленно использовать общие термины для выражения точных ассоциаций. Какое утверждение скажет вам больше? Блок памяти разбит на взаимоисключающие части |..* Область или блок памяти является (выберите один вариант агрегация / композиция) из области?

Если вы говорите, что диспетчер управляет трафиком внутри <некоторого числа> зон управления, это вынуждает вас подробно рассматривать правила приложения. Вы наверняка уже поняли, что это 0..* и что нулевой случай соответствует выходному диспетчеру. Если перефразировать все в качестве класса дежурный контролер управляет трафиком внутри <некоторого числа> зон управления, то у вас получится отразить множественность 1..* и закрепить важное правило. Перевернув глагольную фразу с активного залога на пассивный, вы получите контрольную зону, в которой содержится трафик, управляемый только одним дежурнымконтроллером. Он должен всегда быть, плюс должен быть на дежурстве в соответствии с правилами приложения. Глагольные фразы ведут модель к повышенной точности.

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

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

Отсутствие тегов идентификаторов или ссылочных атрибутов

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

Предположим, что каждый экземпляр класса уникален. Автоматически. То есть код сгенерируется так, что каждая строка таблицы соответствует однозначно выбираемой сущности. Поэтому нам не нужно накладывать атрибут{I}на каждый класс. Получается, что если у вас есть какой-то класс под названием Thing, то вы можете дать ему искусственный атрибутThing.ID {I}, но это необязательно это верно только для искусственных идентификаторов.

Однако, все ограничения уникальности реального мира должны быть выражены всегда. Представьте, что вы моделируете взлетно-посадочные полосы с одинаковым курсом и стороной в нескольких аэропортах. У вас не может быть две ВПП с одинаковым курсом и стороной (скажем, два 28R). Это ограничение, и его надо выразить.

Как вы это сделаете?

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

Включение ссылочных атрибутов в идентификатор для выражения ограничения реального мираВключение ссылочных атрибутов в идентификатор для выражения ограничения реального мира

При помощи тегов{I} и {R}в классе взлетно-посадочной полосы эта модель сообщает нам, что уникальный экземпляр ВПП можно выбрать с помощью подставления заголовка, стороны и кода аэропорта. 28L в SFO, например, это взлетно-посадочная полоса 28 слева в Международном аэропорту Сан-Франциско. Так у вас появляется возможность объединять идентификационные данные и ссылочные теги, чтобы выразить тот или иной факт о реальном мире. А именно несколько взлетно-посадочных полос могут иметь один и тот же курс и сторону, но не в одном аэропорту.

Менее точные типы данных

В хорошей модели мы видели строго определенные типы данных приложения. Плохая же полагается на нечетко определенные типы реализации. Давайте на примере атрибутаControlZone.Name. В хорошей модели он определялся как типCZoneID. На рисунке видно, что имена зон управления состоят изCZи целочисленного значения, например,CZ1,CZ2и прочее в таком духе. Возможно, это получится реализовать и при помощи нечетко определенных типов строк. А если мы в модели говорим, что нам нужна строка, что мы просим в реализации? Если программист (или компилятор) модели работает с более специфичным типом приложения, то сможет при необходимости выбрать более жесткий тип реализации.

Вернемся к модели одного класса. У нас есть тип данных под названиемВысота, это можно определить как количество метров в диапазоне 70 000..-400 с точностью, скажем, 0,01. В отношении данного применения это было бы более точным. Конечно же, программист может захотеть реализовать это в виде данных типа float в C или любого другого типа, который соответствует нужной платформе.

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

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

Итак, атрибуты. Даже если мы позволим атрибуту быть свободно определенной строкой (такой как имя), мы сможем использовать типы данных длинное имя и короткое имя. Длинное может быть определено как строка до 80 символов длиной, а короткое до 10. Нацелены они могут быть как на один тип строк реализации, так и на разные.

Поведенческие ограничения в плохой модели не выражены, а вопросы оставлены без ответов

Пора рассмотреть модель в целом поглубже. Что говорит плохая модель о поведении приложения диспетчеров, правильна ли она?

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

А вот как выглядит правило R2 в плохой модели: 0..1: 0..1. Эта ни к чему не обязывающая ассоциация охватывает и выходных диспетчеров, которые не вошли в систему, и станции дежурства, которые в данный момент не используются. Вот мы с вами и потеряли ограничение, указывающее, что во время дежурства диспетчер должен быть авторизован в системе.

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

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

На примере таблицы Самолеты одного класса мы рассмотрели вопросы, на которые могла бы ответить модель. Попробуйте спросить у плохой модели: Какие авиадиспетчеры сейчас не работают?. Она не может ответить на этот вопрос. Она может показать, какие диспетчеры не курируют зоны управления. Но ведь эти диспетчеры могут быть на дежурстве. Можно ли исправить это, добавив атрибут статуса в класс диспетчера в плохой модели? Само собой. Однако при этом вы все равно упускаете диспетчеров со значениемвыходной, которые при этом курируют зону управления.

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

Вот один пример невалидного сценария, разрешенного в плохой модели:

Плохая модель позволяет диспетчеру находиться на дежурстве без станции дежурстваПлохая модель позволяет диспетчеру находиться на дежурстве без станции дежурства

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

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

Актуальные вакансии компанииRetail Rocket

С переводом помогали: Бюро переводовAllcorrect

Редактор: Алексей @Sterhel Якшин

Подробнее..

Перевод Как построить четкие модели классов и получить реальные преимущества от UML. Часть 2

05.10.2020 10:14:40 | Автор: admin

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

UML и семантика, лежащая в его основе

Итак, мы рассмотрели пример лишь одного класса и заметили, что даже он охватывает сразу несколько правил. Используя табличное представление, мы получаем довольно жесткую структуру данных, поэтому можем думать о механике доступа к ним без учета конкретной реализации. Мы уже усвоили, что можем делать те или иные утверждения о том, что мы знаем, что можем вычислить, а что не можем. И все это без знания каких-то алгоритмов, диаграмм, действий или состояний. У нас просто есть схема одного класса, и этого уже достаточно, чтобы отвечать на вопросы и оценивать соответствие миру, которым планируем управлять. А представьте, что будет, когда бы добавим сотни классов и отношения.

Соблюдение ограничения идентификатора

У вас может возникнуть резонный вопрос где на самом деле применяется ограничение {I}. Модель классов устанавливает лишь требование идентификации. Когда код пишет программист или генератор модели, то должен иметь место систематический механизм обработки идентичности. При этом встроенная архитектура может использовать хэш-таблицу, а корпоративная полагаться на доступные механизмы БД для обнаружения и отклонения повторяющихся записей.

Хорошая модель

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

На рисунке ниже диаграмма классов условно хорошей модели

Хорошая модельХорошая модель

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

Классы авиадиспетчеров

В левой половине модели есть три класса: авиадиспетчер(Air Traffic Controller), выходной диспетчер (он же Off Duty Controller) и дежурный диспетчер (On Duty Controller). Вот как может выглядеть таблица суперкласса, заполненная примерными данными.

ID {I}

Имя

Дата рождения

Рейтинг

диспетчер 53

Тошико

12 июня 1975 года

A

диспетчер 67

Гвен

28 марта 1981 года

B

диспетчер 51

Оуэн

23 декабря 1974 года

C

Смотрите, что имеем. Три авиадиспетчера, для каждого из которых мы точно знаем имя, дату рождения и квалификацию (рейтинг). В таблице у значения ID есть тег {I} что это значит? Правильно, что эти значения должны быть уникальными. В таблице есть данные, которые относятся к диспетчеру, независимо от того, находится ли сейчас авиадиспетчер на своём рабочем месте или у него выходной.

Обратите внимание на текст {disjoint, complete} около отношения обобщения R1 это пара стандартных тегов UML. Это значит, что каждый объект Авиадиспетчер может быть в состоянии дежурный диспетчер или выходной диспетчер. А элемент disjoint означает, что находиться в двух состояниях сразу авиадиспетчер не может. Complete же уточняет, что каждый авиадиспетчер точно находится или на работе, или не на работе. При этом статус каждого точно определен в любой момент времени.

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

Отношение обобщения Disjoint Complete Отношение обобщения Disjoint Complete

Дежурный диспетчер

ID {I, R1}

Время регистрации в системе

Станция {R3}

диспетчер 53

27.09.08, 15:00

S2

диспетчер 67

27.09.08, 11:00

S1

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

Посмотрите на тег {R3} в атрибуте ссылки станции. Он значит, что станция соответствует идентификатору на другой стороне R3. В нашем случае это Duty_Station.ID.

Это очередной пример механики структуры данных, независимой от платформы. Допустим, вам интересно, на какой станции зарегистрирован диспетчер 53? Из структуры нашей таблицы понятно, что для ответа на этот вопрос достаточно просто найти строку с диспетчер 53 в столбце ID, а в столбце Станция получить значение S2.

А можно пойти дальше и получить данные из таблицы станций, используя S2 как ключ. Тогда получится ответить и на более сложный вопрос, например, Кто из диспетчеров зарегистрировался в системе станции S2?. Опять ищем нужную строку в таблице дежурного диспетчера в столбце Станции и получаем значение ID диспетчер 53.

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

Направления доступа для каждой связи обычно оптимизируются или отключаются при необходимости (ряд компиляторов моделей, например, сканируют язык действий, видят, что в определенном направлении связи не выполняется никаких операций записи, и пропускают код сеттера).

Есть компиляторы моделей, которые проделывают все это сами, выдавая хороший C, Java, C++ и (да-да) ассемблер. Но вот генерация какого-либо SQL это, конечно, вариант для систем типа БД.

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

Выходной диспетчер

ID {I, R1}

диспетчер 51

Как это ни странно, для выходных диспетчеров данные не хранятся, по крайней мере, мы об этом пока не знаем. Главное назначение этого класса в том, что он показывает, что время регистрации в системе и ID станций не сохраняются для тех диспетчеров, которые не на службе. Этот трюк дает нам возможность не использовать значение не применимо в наших таблицах. Что плохого в этом значении? Если вы в принципе разрешаете такие пустые значения, то для обработки особых случаев в своем коде вы напрашиваетесь на логику если то. А еще требуете место для хранения, которое на самом деле не нужно приложению.

А еще смотрите как только диспетчер уходит с работы, данные станции и времени регистрации будут удалены (или заархивированы). Так как диспетчер не может одновременно и работать, и не работать, то при миграции объекта диспетчер он или получает, или теряет данным. Вот как это отображается в таблицах.

Авиадиспетчер

ID {I}

Имя

Дата рождения

Рейтинг

диспетчер 53

Тошико

12 июня 1975 года

A

диспетчер 67

Гвен

28 марта 1981 года

B

диспетчер 51

Оуэн

23 декабря 1974 года

C

Перемещение ролиПеремещение роли

Так проводится различие между объектом диспетчер, который является суммой общих и конкретных данных, представленных в любой момент времени двумя экземплярами класса.

Зона управления(Control Zone)

Имя {I}

Трафик

Диспетчер {R2}

CZ1

12

диспетчер 53

CZ2

4

диспетчер 53

CZ3

6

диспетчер 67

Зона управления это область воздушного пространства, находящаяся в ведении одного ATC. Правило, которое мы зафиксируем, состоит в том, что каждая зона управления всегда должна быть подконтрольна какому-то диспетчеру. При этом для каждой зоны управления у нас тоже есть уникальное имя, количество трафика и назначенный для неё диспетчер. Возможно, вы придумаете и еще какие-то полезные атрибуты, скажем, объем, местоположение и прочее. Но пока для примера все же упростим.

Теперь мы можем ответить на вопрос Каким объемом трафика управляет диспетчер 53?.

Станция дежурства

ID {I}

Местоположение

Вместимость

S1

Впереди

20

S2

Впереди

45

S3

В центре

30

У каждой станции дежурства есть уникальный идентификатор, общее местоположение объекта и максимальная пропускная способность (она же - объем трафика, которым станция может управлять).

И тут уже нет никаких ссылочных атрибутов, потому что у нас уже есть один в классе дежурного диспетчера. Теперь, если надо ответить на вопрос Сколько лет человеку, авторизованному на станции S2?, то мы сможем это сделать. Для этого берем значение S2 и проверяем таблицу дежурных диспетчеров на предмет нужной строки. Если она есть, переходим в таблицу диспетчер, ищем строку с S2 и получаем из столбца Дата рождения нужное значение. Сравните её с текущей датой (она вам всегда доступна как системный параметр), проведите несложные вычисления и возраст диспетчера у вас есть.

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

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

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

Иллюстрированный сценарий

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

Иллюстрированный сценарий ATCИллюстрированный сценарий ATC

На сценарии выше у нас три диспетчера, два на дежурстве, третий на заслуженном выходном. Каждый из них авторизован на одной выделенной станции, время регистрации каждого из них в системе мы тоже записали. Каждая зона управления подконтрольна одному дежурному диспетчеру. Что до выходного диспетчера, он не авторизован в системе, поэтому время его входа в систему не зарегистрировано.

Одна станция бездействует, и ни она, ни выходной диспетчер не имеют связи с зонами управления.

В общем, наша хорошая модель на самом деле позволяет обработать реалистичный сценарий.

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

Поэтому я всегда стараюсь рисовать диаграмму в свободной форме, потом модель UML, и уже после этого сравниваю их. Такая валидация работает в обе стороны. Можно ли заполнить таблицы данными, приведенными на иллюстрации сценария? Могу ли я создать убедительную иллюстрацию сценария, используя только данные в моих таблицах? Если я обнаруживаю новый сценарий, я проверяю, подходят ли его данные модели.

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

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

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

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

С переводом помогали: Бюро переводовAllcorrect

Редактор: Алексей @Sterhel Якшин

Подробнее..

Перевод Как построить четкие модели классов и получить реальные преимущества от UML. Часть 3

29.10.2020 10:19:47 | Автор: admin

Продолжение цикла статей из серии "Как посмотроить четкие модели классов и получить реальные преимущества от UML". В первых двух частях (первая, вторая) мы обсудили общий принципы UML, о семантике и признаках хорошей модели. В этой части разберем как поведение системы можем быть выражено в модели.

Отношения в области управления воздушным движением

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

Хорошая модельХорошая модель

R2: управление внутренним трафиком

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

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

On Duty Controller is directing traffic within zero or many Control ZoneOn Duty Controller is directing traffic within zero or many Control Zone

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

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

Control Zone has traffic directed by one On Duty ControllerControl Zone has traffic directed by one On Duty Controller

R3: авторизация в системе

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

Правила, выраженные хорошей моделью

Хорошая модельХорошая модель

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

  1. В каждый взятый момент времени авиадиспетчер либо находится на службе, либо отсутствует {R1}.

  2. Дежурный диспетчер должен быть зарегистрирован на одной станции {R3}.

  3. В любой момент времени станция может управляться или не управляться одним дежурным диспетчером, авторизованным в системе {R3}.

  4. Зона управления должна иметь свой трафик, управляемый точно одним дежурным диспетчером в каждый момент времени {R2}.

  5. Дежурный диспетчер может управлять или не управлять трафиком в одной или нескольких зонах управления в каждый момент времени {R2}.

Какие же в хорошей модели выражены поведенческие ограничения?

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

  1. Что должно произойти, когда выходной диспетчер выходит на дежурство?

  2. Если на дежурстве остался только один диспетчер, может ли этот диспетчер уйти с дежурства?

  3. Если каждая зона управления курируется, может ли другой выходной диспетчер зарегистрироваться в системе?

  4. Если есть 5 дежурных диспетчеров и 5 станций, что нужно сделать, чтобы отключить станцию для проведения работ по обслуживанию?

  5. Если есть 3 зоны управления и 3 дежурных диспетчера, то каково максимальное число зон управления, курируемых одним и тем же дежурным диспетчером?

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

А теперь проверьте себя. Вот как правильно.

  1. Чтобы стать дежурным, необходимо войти в доступное место службы станция дежурства. Элемент выходной диспетчер будет удален и заменен новым элементом дежурный диспетчер, ссылающимся на тот же элемент диспетчера. (Добавочно обратите внимание во встраиваемых системах создание и удаление внутри модели иногда производится предварительным выделением области памяти и переключения бита, чтобы показать, действительно ли данный элемент существует. Так что существуют и другие способы реализации создания/удаления, отличные от конструкторов и деструкторов.)

  2. А вот в этом вопросе больше одного правильного ответа. Каждая из зон управления требует курирования. Допустим, у нас существует один или несколько экземпляров зоны управления, тогда ответом будет нет. Невозможно перенести элемент дежурный диспетчер, не нарушив левую сторону связи R2, если только количество экземпляров зоны управления не равно нулю. Тогда ответом будет да. Если бы был только один другой дежурный диспетчер, то зоны управления можно было бы сначала передать, но в данном случае этого нет, так что это не вариант.

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

  4. Поскольку имеется равное число станций и дежурных диспетчеров, мы можем предположить, что каждая станция используется. Поэтому нам нужно, чтобы дежурный диспетчер вышел из системы, но для этого нам нужно снять ATC с дежурства. И чтобы сделать это, мы должны сначала убедиться, что все зоны управления, руководимые этим дежурным диспетчером, сначала будут переданы другому дежурному диспетчеру.

  5. Три. Для дежурного диспетчера допустимо иметь в ведении 0 зон управления, поэтому один из них может управлять всеми тремя зонами. В этом случае у двух других дежурных диспетчеров не будет назначенных зон управления. Главное убедиться, что каждая зона управления курируется.

  6. Нет. Один из выходных диспетчеров должен сначала стать дежурным, а потом уже все зоны управления должны быть переданы.

Давайте снова с иллюстрацией, которая нужна для хорошей модели. Вот дежурный диспетчер уходит с дежурства

Диспетчер 67 снимается с дежурстваДиспетчер 67 снимается с дежурства

Заполненные таблицы диспетчеров при этом обновляются вот так:

Авиадиспетчеры

ID {I}

Имя

Дата рождения

Рейтинг

Диспетчер 53

Тошико

12 июня 1975 года

A

Диспетчер 67

Гвен

28 марта 1981 года

B

Диспетчер 51

Оуэн

23 декабря 1974 года

C

Диспетчер 67 снимается с дежурстваДиспетчер 67 снимается с дежурства

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

В четвертой статье рассмотрим пример плохой модели и ее отличий от хорошей.

С переводом помогали: Бюро переводовAllcorrect

Редактор: Алексей@Sterhel Якшин

Подробнее..

Некоторые спорные размышления над работой Г. Фреге Смысл и денотат

28.08.2020 18:19:00 | Автор: admin
Термины значение (meaning) и выражать не были введены в качестве
основных терминов семиотики в связи с тем, что они нас только
многозначны и используются настолько по-разному, что лучше было бы
вообще не использовать их в качестве основных терминов при обсуждении
семиотических проблем. Но при желании их, разумеется, можно ввести,
опираясь на более фундаментальные семиотические термины. Так, можно было
бы сказать, что значение знака это его значение-сигнификация и
интерпретанта одновременно, но ни одно из них в отдельности.

Моррис Ч.У. Значение и означивание

В этом небольшом эссе я поделиться с читателем своими размышлениями,
возникшими при прочтении работы Г. Фреге Смысл и денотат[1].


Слабонервных прошу не читать статью (да к тому же написанную 9 лет назад)!


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


1. Основные понятия


Начинает Г. Фреге свою работу с анализа символических утверждений:


a=a


и


a=b.


И ставит по отношению к ним следующий вопрос: Является ли тождество
отношением? Если да, то является ли оно отношением между вещами или
отношением между именами, или знаками, вещей?. И сам же на него
отвечает: Для моего идеального языка я принял второе положение. Тем
самым Г. Фреге утверждает, что данные тождества устанавливают отношения
между знаками aиb. Чем же он это обосновывает?


Для доказательства своего выбора Г. Фреге приводит следующие аргументы:


1. Выражение вида а = а (Кант назвал их аналитическими) истинны a
priori, в то время как истинность выражений вида а = b далеко не всегда
очевидна, и именно поэтому в выражениях вида а = b могут содержаться
существенно обогащающие нас сведения. ....


2. Если же считать, что тождество это отношение между вещами,
обозначаемыми посредством букв а и b, тогда а = b ничем не отличается от
а = а (если, конечно, а = b истинно). Действительно, в этом случае, а =
b выражало бы отношение вещи к самой себе и притом такое отношение,
которое возможно только между вещью и ею же самой, но не между разными
вещами. .


С этим можно было бы согласиться, но встает резонный вопрос: не
вкладываем ли мы при этом в отношение .=. только один из возможных
смыслов, а именно отношение полной эквивалентности всех признаков а и b.
Если же мы вкладываем в отношение .=. эквивалентность любой (или
некоторой фиксированной) части (совокупности) признаков объектов, то
тождества


a=a


и


a=b


могут рассматриваться как тождественность объектов. Такое их понимание
становятся согласованными и допустимым, поскольку при таком понимании
данных тождеств, они могут


  1. указывать на понимание участвующих объектов как экземпляров
    некоторого класса;


  2. указывать на их принципиальную эмпирическую неразличимость (и не
    только из-за эмпирической недоступности для наблюдения различающих
    их признаков);


  3. указывать на возможность использования имени a вместо имени b.



В этом контексте можно сослаться в качестве примеров на возможность
рассуждения в математике о числах, классах эквивалентности и др., в
физике о принципе тождественности квантовых объектов и пр.[2]


Ну, хорошо Вернемся к этому вопросу позже, а теперь продолжим
рассмотрение той интерпретации которую предлагает Г. Фреге: Однако,
утверждая, что a=b, мы скорее имеем в виду, что знаки, или имена,
а и b обозначают одно и то же, следовательно, речь идет именно об
этих знаках, то есть отношением тождества связаны именно знаки. . Итак
мы имеем следующие важные положения теории Г. Фреге:


1. знаки и имена синонимы.


2. в тождестве a=b утверждается, что нечто существующее может
быть поименовано (названо) двумя различными именами а и b.


Первое важно для нас как утверждение о том, что знак представляет
собой имя, а не то что имя есть одна из сторон или признаков
знака. Второе можно принять как одну из допустимых или возможных
интерпретаций отношения тождества в контексте данной работы Г. Фреге:
При этом имена (или знаки) находятся в указанном отношении лишь
постольку, поскольку они что-то называют или обозначают: тождество двух
знаков устанавливается путем соотнесения каждого из них с одним и тем же
обозначаемым. А соотнесение это произвольно: ведь всякий имеет право
считать любое произвольно выбранное событие или вещь знаком для чего
угодно. Тогда получается, что выражение а = b касается уже не сути дела,
а только принятого нами способа обозначения: в таком случае с помощью
подобных выражений мы не могли бы передавать полезную информацию. Однако
ведь именно этого мы чаще всего и хотим. .


Фреге рассматривает следующий пример: Пусть а, b, с прямые,
соединяющие вершины треугольника с серединами противолежащих сторон;
тогда справедливо (1):


(1). Точка пересечения а и b совпадает с точкой пересечения b и с.


Таким образом, мы, строго говоря, имеем две точки:


(2). AB точку пересечения прямых a и b;


(3). BC точку пересечения прямых b и c.



Рисунок 1. Рисунок к примеру Г. Фреге


Тогда утверждение (1) может быть выражено (записано) точно также как и
тождество, рассматриваемое выше:


AB = BC


Из этого Г. Фреге делает вывод: Таким образом, одной точке
соответствуют два разных обозначения или имени. Эти имена (точка
пересечения прямых а и b, точка пересечения прямых b и с) указывают и на
разные способы представления обозначаемого; поэтому в предложении (1)
заключено подлинное знание.


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


Для чего же это необходимо Фреге? Опирая на эти рассуждения, позволяет
Г. Фреге ввести некоторые понятия семиотики, а, именно, денотат и
смысл: Таким образом, становится ясно, что знак как таковой (будь то
слово, словосочетание или графический символ) может мыслиться не только
в связи с обозначаемым, то есть с тем, что можно было бы назвать
денотатом знака [Bedeutung], но и в связи с тем, что мне хотелось бы
назвать смыслом знака [Sinn]; смысл знака это то, что отражает
способ представления обозначаемого данным знаком. И далее: Из
сказанного следует, что под знаком (или именем) я понимаю любое
обозначение, выступающее в роли имени собственного; денотатом знака
является определенная вещь (в самом широком смысле слова), но не понятие
или отношение, которым будет посвящено отдельное исследование.
Обозначение одной вещи может состоять из нескольких слов или иных
знаков. Для краткости мы будем называть такие обозначения именами
собственными.


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


Здесь мне бы хотелось привести следующую графическую иллюстрацию
собственного понимания этих слов Г. Фреге с использованием нотации
UML[3] (см. Рисунок 2 и Рисунок 3).



Рисунок 2. Графическая иллюстрация отношений между обозначаемым (денотатом) и его именем



Рисунок 3. Альтернативная графическая иллюстрация отношений между обозначаемым (денотатом) и его именем


Итак, смысл это устанавливаемое (или интерпретируемое) отношение между
именем и денотатом. Для нас важно также понять какую кратность могут
иметь роли этого отношения. Из предшествующих рассуждений мы можем
прийти к выводу, что денотат может иметь несколько имен (то, что в
лингвистике называется синонимией). Поэтому мы можем уточнить рисунок 2
образом, представленном на следующем рисунке (см. Рисунок 4):



Рисунок 4. Отношение между денотатом и его именем, с указанием возможной синонимии


Таким на данный момент мы видим отношение (смысл) денотата и его имени:


1. каждому имени должен соответствовать один и только один денотат;


2. у одного денотата может иметься несколько имен.


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


1. Может ли одно и то же имя называть несколько различных денотатов?


2. Может ли имя ничего не обозначать или ему должно должен
соответствовать хотя бы один денотат?


3. Может ли существовать денотат без имени?


Попробуем получить ответ на первый вопрос. Г. Фреге пишет: В идеале
соответствие между знаками, смыслами и денотатами должно быть устроено
таким образом, чтобы всякому знаку всегда соответствовал один
определенный смысл, а всякому смыслу, в свою очередь, всегда
соответствовал один определенный денотат; в то же время денотату (вещи)
может соответствовать не один смысл, а несколько, и один и тот же смысл
может выражаться разными знаками не только в разных языках, но и в
пределах одного и того же языка. Пока Г. Фреге не сказал нам ничего из
того, чего бы ни было показано на вышеприведенном рисунке (см. Рисунок
4). Но в том же абзаце, он пишет: Разумеется, в действительности
указанное соответствие часто нарушается. Как было только что сказано, в
идеальной знаковой системе всякому выражению должен соответствовать
только один определенный смысл; однако естественные языки далеко не
всегда удовлетворяют этому требованию: редко бывает так, чтобы слово
всегда имело один и тот же смысл в разных контекстах. Итак, мы получили
ответ на первый из интересующих нас вопросов:


  • одному и тому же имени в разных контекстах могут
    соответствовать различные денотаты.

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


  • наиболее удаленное от земли небесное тело.


  • ряд, сходящийся медленнее любого другого ряда.



Можно продолжить эти примеры, приведя множество подобных абстракций:


  • вечный двигатель.


  • круглый квадрат



и т.п.


Приведенные примеры Г. Фреге резюмировал следующим образом: Таким
образом, даже если смысл имени очевиден, денотата у него может и не
быть. Но, что-то все равно на этом конце отношения Смысл должно
соответствовать имени?! Хорошо, пусть это будет не объект реального
мира, не предмет, но возможно некоторая абстракция, некоторый концепт,
некая мысль, идея, некоторая сущность понимаемая, воспринимаемая или
репрезентируемая человеческой психикой? Ответа у Г. Фреге пока мы не
находим. Поэтому временно примем, без четкого определения и интуитивно
представляемое расширенное понимание термина денотат, включающего в
себя не только предметы реального мира, но и предметы мира модельного,
нереального. Возможно, нам в последующем придется ввести некоторые
разновидности денотата или отнести его как разновидность некоторого
другого суперкласса (понятию). Но сейчас это позволит нам принять
следующий ответ на второй вопрос:


  • одному и тому же имени в разных контекстах должен обязательно
    соответствовать один или более различных денотатов.


  • одному и тому же денотату могут соответствовать несколько имен.



В этом случае нам потребуется переработать нашу графическую модель
следующим образом (см. Рисунок 5):



Рисунок 5. Модель Денотат-Смысл-Имя


Представлениям Г. Фреге будет соответствовать следующая модель (см.
Рисунок 6):



Рисунок 6. Модель Денотат-Смысл-Имя по Г. Фреге


Кратность 0..1 одной из вершин отношения Смысл на последнем рисунке
просто говорит о том, что одному и тому же имени в разных контекстах
могут соответствовать различные денотаты.


Если мы попытаемся найти ответ на третий вопрос, то можно убедиться что
любой ответ на него содержит в себе парадокс! Действительно, попробуем
предположить, что существует некий предмет, для которого нет имени. И,
это вполне реальная ситуация, когда люди сталкиваются с предметами и
явлениями, для которых у них нет имени (например, дети). Но тогда мы
могли бы дать ему имя Денотат, не имеющий имени. А поэтому, он
оказывается поименованным (обозначенным), а, следовательно, для него не
надо давать имени и т.д. В некотором смысле это абсурд.


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


Поэтому можно принять в качестве ответа на третий вопрос следующее
утверждение:


  • любому денотату соответствует хотя бы одно имя.

Поэтому на это итерации мы должны получить следующую версию модели (см.
Рисунок 7):



Рисунок 7. Модель Денотат-Смысл-Имя с учетом полученных ответов


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



Рисунок 8. Модель Денотат-Смысл-Имя с учетом декомпозиции отношения Смысл


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


У нас остался не проясненным вопрос о ролях установленных отношений
Денотат-Смысл и Имя-Смысл. Но от него пока отвлечемся и возможно
вернемся к нему уже в другой работе.


У нас еще остается один интересный вопрос, содержащийся в примечании
переводчика к использованию Г. Фреге термина денотат:


Буквальный перевод слова Bedeutung значение, смысл. Однако, по ряду
причин, главным образом потому, что здесь Bedeutung употребляется в
смысле денотат, мы предпочли именно этот вариант перевода. Прим.
перев..


Это означает, что реально Г. Фреге мог говорить не о денотате как
предмете реального мира, а значениях имен реального мира! И
только установка переводчика на интерпретацию Bedeutung как денотат в
переводе приводит к иным смыслам. Автор все же надеется что это не так
Однако, это дает ему надежду, поименовать одну из ролей отношения
Денотат-Смысл. Мы могли бы, например, обозначить один из концов этого
отношения как значение (см. Рисунок 9).



Рисунок 9. Модель Денотат-Смысл-Имя с указанием некоторых ролей отношений Денотат-Смысл и Смысл-Имя


На предшествующих рисунках (см. Рисунок 9) мы также видим наличие
дополнительного отношения агрегации. Оставим это отношение пока без
дальнейшего рассмотрения.


Далее Г. Фреге переходит к следующей части своей работы, в которой
освещает свое понимание денотата предложения.


2. Денотат предложения


В начале Г. Фреге напоминает, что им понимается под денотатом слова:
Когда мы употребляем слово обычным образом, его денотат это то, что
мы имеем в виду. И это не расходится с тем, что мы приняли в качестве
рабочей гипотезы ранее.


Но вот что он пишет о предложениях (прежде всего оформленных в виде
прямой речи): Однако иногда нам требуется сказать что-либо о самих
словах или об их смысле, например, когда мы передаем чужие слова
посредством прямой речи. Тогда прямая речь, то есть произносимые нами
слова, обозначает, прежде всего чужие слова слова другого лица, и
только эти последние имеют обычный денотат. Слова в прямой речи это
знаки знаков. На письме в таких случаях изображения слов [Wortbilder]
заключают в кавычки, а изображению слова, заключенному в кавычки, нельзя
приписывать обычный денотат соответствующего слова.


Практически Г. Фреге не ничего конкретного сказал, а самое главное не
прояснил сказанное. Что же, попробуем это сделать за него Итак он
пишет:


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


2. Чужие слова имеют обычный денотат.


3. Слова в прямой речи это знаки знаков.


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


Разберем первые тезис.


Итак, при передаче прямой речи индивид выступает в качестве
ретранслятора, в буквальном смысле, воспроизводящем чужую речь. В этом
случае он выступает как бы в роли этого третьего лица, подменяет
отсутствующие при этом третье лицо и адресат в этот момент должен
воспринимать его как это третье лицо. Только в этом случае может быть
верен второй тезис Г. Фреге: чужие слова имеют обычный денотат[4]. С
этим можно согласиться лишь в таком простом контексте.


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


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


  • прямой речи чужим словам, заключенным в кавычки, а


  • чужие слова имеют обычный денотат?



Строго говоря, мы столкнулись с противоречивым высказыванием. Тогда,
скорее всего, четвертый тезис относится не к закавыченному предложению,
а к отдельному слову (словосочетанию) заключенному в кавычки и
размещенному в речи или тексте первого лица (адресанта). Это более
привычная ситуация. В этом случае более вероятно проявление у
закавыченного слова или словосочетания иного смысла или иного денотата.
Но тогда надо говорить о косвенном смысле и косвенном денотате. Что и
делает Г. Фреге дальше: Желая говорить о смысле выражения А, мы можем
прибегнуть к словосочетанию смысл выражения А. Например, чтобы
сообщить что-либо о смысле сказанного третьим лицом, мы пользуемся
косвенной речью. Ясно, что и в этом случае словам, выступающим в
косвенной речи, тоже нельзя приписывать их обычный денотат, ибо в роли
последнего выступает их обычный смысл. Для краткости мы будем говорить,
что в косвенной речи слова выступают в косвенном употреблении и имеют
косвенный денотат. Таким образом, мы будем различать у слов обычный
денотат и косвенный денотат, обычный смысл и косвенный смысл. Косвенный
денотат слова совпадает с его обычным смыслом. Возможность косвенного
употребления слов надо постоянно иметь в виду при установлении
соответствий между знаком, смыслом и денотатом..


Итак, Г. Фреге выделяет следующие разновидности денотатов:


  • обычный денотат,


  • косвенный денотат



и соответствующие им разновидности смысла


  • обычный смысл,


  • косвенный смысл.



Вызывает интерес дальнейшее уточнение денотата и смысла:


Смысл и денотат знака следует отличать от соответствующего этому знаку
представления. Если денотат знака это вещь, данная нам в ощущениях, то
мое представление об этой вещи есть внутренний образ, возникший у меня
на основе моих впечатлений от этой вещи, а также в результате моей
деятельности, физической и мыслительной, связанной с этой вещью[5].
Образ-представление, часто бывает пропитан эмоциями, отдельные его части
могут быть более или менее расплывчатыми. Более того, не всегда, даже
для одного человека, определенное представление связано только с одним
смыслом. Представление (внутренний образ) всегда субъективно оно
меняется от человека к человеку. Отсюда проистекает многообразие
различных представлений, сопряженных с одним и тем же смыслом. У
художника, наездника и зоолога с именем Буцефал будут связаны,
вероятно, очень разные представления. Этим представление существенно
отличается от смысла знака, который может быть общим достоянием, а не
просто частью опыта одного человека. Именно благодаря смыслам знаков
человечество сумело накопить общий багаж знаний и может передавать его
от поколения к поколению[6]..


Итак, смыслу может соответствовать и денотат, и представление
(субъективный образ). Но тогда рушиться вся построенная нами до этого
модель. Однако вновь обратимся к примечанию переводчика к использованию
термина денотат:


Буквальный перевод слова Bedeutung значение, смысл. Однако, по ряду
причин, главным образом потому, что здесь Bedeutung употребляется в
смысле денотат, мы предпочли именно этот вариант перевода. Прим.
перев..


Перед нами в таком случае встает вопрос: а не использовал ли до этого
момента Г. Фреге слово Bedeutung как слово значение? Вполне
возможно, но тогда и нам необходимо это использовать: что если вместо
отношения Денотат-Смысл использовать отношение Значение-Смысл, а
разновидностями Значения сделать Денотат и Представление? В этом автор
видит свой резон. Итак, мы приходим к следующей итерации нашей модели
(см. Рисунок 10), которую можно было бы назвать Имя-Смысл-Значение.



Рисунок 10. Модель Имя-Смысл-Значение


Таким образом, мы смогли получить некоторую формальную классификацию
значений по его разновидностям:


  • денотаты как вещи, данные нам в ощущениях; предметы объективной
    реальности.


  • представления как психические феномены, внутренние образы
    индивидов.



Что касается представлений, то Г. Фреге говорит следующее: Разные люди
могут одинаково воспринимать один и тот же смысл, однако одинаковых
представлений у разных людей быть не может. Si duo idem faciunt, non est
idem (даже если два человека представляют себе одно и то же, у каждого
будет свое собственное представление). Хотя иногда и удается уловить
разницу между представлениями или восприятиями разных людей, точное
сравнение представлений невозможно, так как разные представления нельзя
иметь одновременно в одном сознании.. И с этим можно согласиться.


Но автор эссе не может принять следующее за этим пояснение Г. Фреге об
отношении между денотатом и представлением: Между денотатом и
представлением располагается смысл не столь субъективный, как
представление, но и не совпадающий с самой вещью, то есть с денотатом.
Поясним это соотношение следующим примером. не может выстраиваться
такое отношение между денотатом и представлением, поскольку
однозначно они имеют отношения с именами, знаками, о чем в этом же
абзаце Г. Фреге говорит: Денотат собственного имени это, как мы уже
говорили, сама вещь, которую оно обозначает. Что же касается
представления, связанного с данным именем, то оно абсолютно субъективно.
. Хотя бы неплохо было обозначить некоторую связь между объективной
реальностью и ее представлением в психике (см. Рисунок 11).



Рисунок 11. Модель Имя-Смысл-Значение с учетом отношения отражения реальности в психике


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


Далее Г. Фреге возвращается к анализу смыслов предложений: Итак, можно
усматривать три степени различия между выражениями[7] (словами,
словосочетаниями и целыми предложениями): различие затрагивает либо
только представление, либо смысл, но не денотат, либо, наконец, и смысл
и денотат. Поскольку, слово не имеет четкой связи с представлением, для
первой степени могут существовать различия, улавливаемые одними, но не
замечаемые другими говорящими.. С моей точки зрения, хотелось бы
уточнить сказанное Г. Фреге: поскольку слово не имеет четкой связи со
своим значением (как денотатом, так и с представлением), то при попытке
поверхностного понимания могут существовать различия в их значениях,
улавливаемые одними, и не замечаемые другими говорящими.


Можно полностью согласиться со словами Г. Фреге о роли неоднозначности
связи между именем и смыслом в литературном творчестве: Разница между
переводом и оригиналом не должна, вообще говоря, выходить за пределы
первой степени различия. Сюда же относятся различные нюансы и разная
стилистическая окраска, которые придаются смыслу в поэзии и вообще в
художественном тексте. Эти нюансы не объективны: читатель или слушатель
должен сам воссоздавать их для себя по намекам поэта или оратора. Если
бы представления разных людей не были в достаточной степени сходны,
словесное искусство, видимо, не могло бы существовать. Однако точно
установить, насколько представления читателей отвечают замыслам автора,
невозможно..


Часть представлений через какое-то время в процессе научного познания
или практического освоения мира, может быть, стать денотатами: Наше
предположение о том, что у имени Луна есть денотат, может, конечно,
оказаться неверным такое уже случалось в истории науки. Однако на
вопрос о том, не является ли вообще ошибочным предположение о наличии
денотатов у каких-либо имен, можно и не отвечать. Достаточно сослаться
на наше намерение говорить или рассуждать именно о денотате знака (делая
при: этом оговорку: если, конечно, таковой существует)..


Возвращаясь к вопросу о смысле целого повествовательного предложения, Г.
Фреге пишет: Такое предложение всегда содержит (выражает) некоторое
суждение [Gedanke]. А под суждением Г. Фреге понимает: не
субъективную деятельность мышления, а его объективное содержание,
способное быть достоянием многих.. Итак: целое повествовательное
предложение содержит некоторое объективное содержание, способное быть
достоянием многих.


Г. Фреге дальше ставит вопрос: Должны ли мы рассматривать это суждение
как смысл или как денотат соответствующего предложения?


С моей точки зрения это достаточно странный вопрос. Как мы уже
выясняли, точнее во-первых, смысл и значение настолько тесно
связаны, что одно без другого не существует, как не существует
несвязанных смыслов и имен[8]; во-вторых, наверно, главное содержание
этого вопроса все-таки сводится к тому, что является значением смысла
простого предложения: денотат или представление, или какую форму
приобретает его денотат, что он из себя представляет?[9]


В попытке получить ответ на свой вопрос Г. Фреге, предлагает
использовать следующий метод: Предположим, что у данного предложения
есть денотат. Заменим в нем некоторое слово на другое слово с тем же
денотатом, но с другим смыслом; это никак не должно повлиять на денотат
предложения в целом.. Для своего рассуждения Г. Фреге использует
следующие модельные предложения:


Утренняя звезда это небесное тело, освещаемое солнцем


и


Вечерняя звезда это небесное тело, освещаемое солнцем.


К ним можно добавить и такое:


Венера это небесное тело, освещаемое солнцем.


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


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


Но Г. Фреге волнует вопрос о денотате предложения: Но что же тогда
считать денотатом предложения? И, вообще, имеется ли у предложения какой
бы то ни было денотат? Может быть, у предложения в целом есть только
смысл, но нет денотата? Во всяком случае, можно ожидать, что найдутся
предложения, которые так же как и некоторые их части имеют смысл, но
не имеют денотата..


В качестве примера такого предложения Г. Фреге приводит следующее:


Одиссея высадили на берег Итаки в состоянии глубокого сна.


очевидным образом имеет смысл. Но поскольку мы не знаем, есть ли
денотат у имени Одиссей, мы вряд ли можем сказать, что таковой имеется
у всего предложения. . Но он же сам писал и разделял значения смысла
на денотаты и представления. Поэтому у него есть и смысл, и значение
представление о факте высадки мифического героя на берег Итаки!


Но как видно из дальнейшего, не признания возможности отсутствия
объективных смыслов (суждений) добивается Г. Фреге данными
рассуждениями: его волнует вопрос о том, как мы понимаем друг друга,
обмениваясь предложениями не имеющих денотатов (как предметов реального
мира или ссылок на них)? И он стремится найти этот денотат (или их
класс): Можно было бы вообще считать, что доискиваться до денотата
имени излишне: если бы нас интересовало только суждение, выраженное в
предложении, можно было бы довольствоваться знанием смысла. Ведь если
рассматривать только смысл предложения, то есть суждение, то незачем
заниматься денотатами отдельных его частей; для смысла предложения важны
только смыслы его частей, а не их денотаты; суждение не изменится от
того, имеет слово Одиссей денотат или нет. Однако сам факт, что нас
волнует вопрос о денотатах отдельных частей предложения, указывает на
то, что мы в общем случае предполагаем наличие денотата и у предложения
в целом. Суждение теряет для нас всякую ценность, как только мы
заметаем, что какая-нибудь из его частей не имеет денотата. Поэтому наше
стремление узнать не только смысл, но и денотат предложения вполне
оправдано..


Выход из этого Г. Фреге видит в использовании людьми истинности
высказывания: Ясно, однако, что тот, кто всерьез считает данное
предложение истинным или ложным, считает также, что имя Одиссей имеет
не только смысл, но и денотат, ибо именно денотату этого имени можно
приписывать или не приписывать состояние, обозначенное в приведенном
предложении соответствующим предикатом.. И далее: Почему самого по
себе суждения нам недостаточно? Потому и лишь потому, что нас интересует
истинность суждений Именно стремление установить истину и заставляет
нас двигаться вперед, от смысла предложения к его денотату.[10]. Но не
все так хорошо с предикатами, иначе бы Г. Фреге не вынес в сноску
следующее: Желательно иметь для знаков, которые должны быть наделены
только смыслом, особое название, например, изображения [Bilder];
тогда слова, произносимые актером на сцене, будут изображениями; более
того, и сам актер будет изображением. К этому можно сделать лишь одно
замечание: Г. Фреге не может, при анализе всего многообразия способов
передачи содержания предложений, обойтись только использованием
денотатов, ему нужны и представления.


Итак, почему же Г. Фреге пошел по этому пути:


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


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



Весьма странным ответом на поставленные вопросы является предложение Г.
Фреге считать денотатом предложения его истинностное значение: Мы
вынуждены, таким образом, признать, что денотатом предложения является
его истинностное значение [Wahrheitswert]истина или ложь других
истинностных значений не бывает[11]. Всякое повествовательное
предложение, в зависимости от денотатов составляющих его слов, может,
таким образом, рассматриваться как имя, денотатом которого (если,
конечно, он существует) будет либо истина., либо ложь. Обе эти
абстрактные вещи (истина и ложь) признаются, хотя бы молчаливо. Всеми,
кто вообще делает какие-либо утверждения или считает хотя бы что-нибудь
истинным, то есть даже самыми последовательными скептиками. То, что мы
считаем истинностное значение вещью, может показаться неоправданным
произволом, пустой игрой слов, из которой нельзя извлечь никаких
интересных следствий..


Проблема состоит в том, что то, что он предлагает как следствие из своих
рассуждений является предположением, для которого с точки зрения автора
Г. Фреге так и не нашел достаточно убедительных аргументов. Г. Фреге сам
это осознает: То, что мы считаем истинностное значение вещью, может
показаться неоправданным произволом, пустой игрой слов, из которой
нельзя извлечь никаких интересных следствий. Уточнить, что именно
понимается здесь под вещью, можно только через понятие и отношение..
Поэтому он продолжает: Можно попытаться рассмотреть отношение суждения
к истинности не как отношение смысла к денотату, а как отношение
субъекта к предикату.. И для этого он приводит следующий пример,
состоящий из двух предложений:


(9) Суждение, что 5 простое число, истинно.


(10) 5 простое число.


Тем самым, следуя тем соображениям, которые к данному моменту мы находим
в работе Г. Фреге, мы можем интерпретировать предложение (9) как пример
предложений, выражающих отношение смысла к денотату, а (10) как пример
предложений, выражающих отношение субъекта к предикату.


Согласно Г. Фреге: Утверждение истины в обоих случаях заложено в самой
форме повествовательного предложения, причем даже в тех случаях, когда
эта форма лишена своей обычной утвердительной силы.. Опять таки
почему? Не то того ли, что это так хочется самому Г. Фреге? Мы же видим,
что (9)-ый пример представляет собой предложение, обладающее
императивной модальностью: вы должны отнести число 5 к классу простых
чисел; (10)-ый пример, больше говорит о свойстве конкретного числа 5
т.е. данное предложение носит фактографический характер, сообщает об
имеющемся факте. И только сложившаяся интеллектуальная традиция,
позволяет нам принять точку зрения Г. Фреге: если предложение (9)
произнесено актером со сцены, оно выражает только одно суждение, то же
самое суждение, что и предложение (10).. Но при этом они имеют
различные прагматические цели.


Только оговора Г. Фреге о том, что если (9) произнесено актером на
сцене (т.е. абсолютно нейтральным лицом), оно может не иметь
императивной модальности, и поэтому по всем характеристикам (9) и (10)
будут практически эквивалентными. Но и не только! Все таки, следовало бы
различить их формы:


P(P(5))=true для (9) и


P(5) для (10).


Т.о., вне конкретной коммуникативной ситуации (10) не отражает ничего
кроме некоторого отношения экземплификации или приписывания
экстенсионала 5 классу простых чисел, а это совсем не означает
истинности P(5) [12]. В тоже время очень легко предложение (9) можно
переформулировать в императивной модальности:


Я утверждаю, что суждение 5 простое число истинно.


или


Я нарекаю 5 простым числом


или


Я отношу 5 к простым числам.


В этом смысле поражает следующая за этим оговорка Г. Фреге: Отсюда
следует, что между суждением и его истинностным значением имеет место
совсем не то же отношение, что между субъектом и предикатом. Субъект и
предикат (в логическом смысле этих терминов) являются частями суждения и
находятся на одном и том же уровне с точки зрения познания: соединяя
субъект с предикатом, мы всегда получаем тем самым суждение, но не
совершаем перехода от смысла к денотату, или от суждения к его
истинностному значению. Соединяя субъект с предикатом, мы остаемся на
том же самом уровне, не переходя на следующий. Истинностное значение не
может быть частью суждений, поскольку оно не смысл, а вещь, точно так
же, как не может быть, скажем, частью суждения о Солнце, само Солнце..


Непонятно в силу вышесказанного и другое утверждение Г. Фреге: Если
наше предположение о том, что денотатом предложения является его
истинностное значение [Wahrheitswert], верно, то последнее не должно
изменяться, если какую-нибудь часть предложения заменить выражением,
тождественным ей по денотату, но отличным по смыслу. Это действительно
так и есть. Лейбниц писал по этому поводу: Eadem sunt, quae sibi mutuo
substitui possunt, salva veritate[13].


Удивляет собственно переход от первого ко второму. Ведь в утверждении
Лейбница по своей сути содержится следующая мысль: если не меняется
значение предложения, то и истинность его также не должна меняться, но
не наоборот. Действительно, мы можем привести бесконечное множество
эквивалентных по значению истинности утверждений, но совершенно разных
по смыслу[14]. Автор еще раз убеждается в справедливости собственного
мнения, обратного мнению Г. Фреге: истинностное значение (значение
функции истинности) не может быть денотатом предложения. Раз, каким бы
то ни было образом, был установлен смысл (как отношение между значением
и именем установлено) предложения, то его можно было бы, считать
истинным, пока он позволяет лицу (индивидууму) успешно действовать в
окружающем мире. Другое дело, что само отношение Смысл может иметь
какие-то дополнительные атрибуты истинность, значимость и т.п..


Видно, что Г. Фреге, на самом деле никак не может ничего представить,
что кроме простого скалярного значения (типа числа, булевого значения
или целостного образа) может образовывать денотат предложения
(описывающего ситуацию или фактическое положение дел в мире): Что же
еще, кроме истинностного значения, может быть в общем случае приписано
всякому предложению, что так тесно связано с денотатами его частей и не
зависит от подстановок указанного типа?[15].


Подытоживая все свои рассуждения на тему денотата предложения, Г. Фреге
пишет: Если же денотатом предложения является его истинностное
значение, то все истинные предложения, с одной стороны, и все ложные
предложения, с другой, будут иметь один и тот же денотат: все первые
обозначают истину, все вторые ложь. Отсюда видно, что в денотате
предложения все частное стирается. Поэтому денотат сам по себе нас не
интересует; однако и суждение, взятое в отрыве от денотата, т. е. смысл
сам по себе, тоже не несет в себе нового знания. Этим свойством обладает
только соединение суждения и его денотата (истинностного значения).
Утверждение можно рассматривать как переход от суждения к его
истинностному значению..


Воздержимся от дополнительных комментариев этих слов Г. Фреге, поскольку
автор уже высказался на эту тему. Интересно следующее за ним
утверждение: Впрочем, можно было бы сказать, что утверждение
обязательно связано с разбиением истинностного значения на некоторые
части. Это разбиение выполняется на основе обращения к суждению. При
этом каждому смыслу, имеющему некоторое истинностное значение,
соответствует свое особое разбиение этого истинностного значения на
части. (Слово часть [Teil] употребляется здесь достаточно необычным
образом, а именно: отношение между предложением и его частью переносится
на денотат предложения; тем самым денотат слова мыслится как часть
денотата всего предложения, если само это слово является частью
предложения. Такое словоупотребление, очевидно, не вполне корректно, так
как денотат целого и какой-либо его части еще не определяет денотата
остальной части, а также и потому, что применительно к физическим телам
слово часть употребляется в другом смысле. Для данного понятия
следовало бы найти другое выражение).. Оно интересно тем, что
фактически его можно понимать как существование, по мнению Г. Фреге,
потенциальной возможности вычислять истинностное значение предложения
на основе истинностных значений его частей.


В дальнейшем Г. Фреге приступает к анализу денотата придаточных
предложений. На основе своих грамматических изысканий приходит к
следующим выводам:


1. денотатом придаточного является определенное суждение: для
истинности целого сложноподчиненного предложения безразлично, истинно
или ложно суждение, выраженное в придаточном;


2. денотатом предложения не всегда бывает его истинностное значение.


Если по поводу первого вывода автор собственно ничего не имеет, в силу
всего вышесказанного, то второй вывод вызывает удивление Г. Фреге
пошел на смягчение своего же ранее сделанного предложения. Автор думает,
что это закономерно, поскольку вся концепция денотата предложения как
логического значения не правомерна и построена на слишком зыбком
основании. Что подтверждается и дальнейшими выводами Г. Фреге:


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


2. Так же обстоит дело с косвенными вопросами.


Г. Фреге приводит и другие примеры. Чтобы как-то выкрутиться из такого
неудобного положения, ему приходится постулировать отсутствие денотата у
некоторых видов предложений: В данной связи возникает следующая
трудность. Естественные языки обладают тем недостатком, что они
допускают выражения, которые облечены в правильную грамматическую форму
и потому представляются имеющими некоторый денотат (как бы обозначают
некоторую вещь), хотя в действительности денотата у них может и не быть,
так как это зависит от истинности некоторого другого предложения. .


Для подкрепления своей позиции он пытается привлечь ссылки
математические примеры: этот недостаток присущ в какой-то степени и
знаковой системе математического анализа: здесь мы тоже встречаем
выражения, которые внешне выглядят так, как будто они что-то обозначают,
однако в действительности (по крайней мере, до сих пор) денотат их
неизвестен, например: сумма бесконечного расходящегося ряда. . Но
здесь он говорит о значении, тем самым, подтверждая косвенно свое
представление о связи денотата со значением[16].


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


  • находится адекватное понимание;


  • словам подбираются соответствующие значения (будь-то денотаты или
    представления);


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



В заключении, хотелось бы процитировать Г. Фреге, давшего определение
идеального языка: В идеальном языке [Begriffsschrift] любое
грамматически правильное выражение, построенное из ранее определенных
знаков, которое вводится в качестве собственного имени, должно
обязательно обозначать нечто, и всякий новый знак может вводиться в
качестве собственного имени лишь при условии, что ему уже обеспечен
некоторый денотат. . Так что данный нами предпоследний комментарий
может служить доводом того, что идеальным языком обладает практически
каждый из нас.


3. Заключительные замечания


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


В данном эссе мы рассмотрели некоторые положения работы Г. Фреге Смысл
и денотат (Смысл и значение). Для большей наглядности автор решил
использовать графическую нотацию UML, что позволило ему не только
образно представить довольно абстрактные понятия семиотики, но и (как
ему кажется) прояснить место таких понятий как Смысл и Значение.



Рисунок 12. Заключительная итерация модели Имя-Смысл-Значение


На основе полученной модели (см. Рисунок 12) можно кратко сформулировать
полученные результаты следующим:


  1. Под смыслом мы понимаем устанавливаемое в процессах порождения имени
    или его интерпретации отношение между именем и его значением.


  2. Значения можно разделить на два взаимосвязанных класса сущностей:



  • денотаты как вещи, данные нам в ощущениях; предметы объективной
    реальности;


  • представления (концепты) как психические феномены, внутренние
    образы индивидов;


  • некоторым представлениям (концептам) можно поставить в соответствие
    денотаты.



  1. Одному и тому же имени в разных контекстах должно обязательно
    соответствовать одно или более различных значений.


  2. Любому значению соответствует хотя бы одно имя.


  3. Одному и тому же значению могут соответствовать несколько имен.


  4. Отношение омонимии устанавливается непосредственно не между именем и
    значением, а между именем и смыслом, при этом именно имя агрегирует
    омонимичные смыслы.



Что же у нас осталось нераскрытым? К нераскрытому, в этой работе автора,
содержанию можно отнести:


  • структуру имени;


  • структуру денотата;


  • структуру представления (концепта);


  • роли и их кратности в отношении Значение Смысл Имя.


  • возможные связи или отношения между синонимичными именами, или их
    определениями;


  • присваивание и переприсваивание значений имен и многое многое
    другое.



Но это уже другая работа


[1] Фреге Г. Смысл и денотат (1892) в сборнике Семиотика и
информатика. Выпуск 8. 1977, с. 181-210


[2] Естественно, что Г. Фреге не мог оперировать принципами квантовой
физикой, поскольку последняя родилась почти на два десятилетия позже
написания рассматриваемой нами работы.


[3] Для понимания такой графической нотации читателям рекомендуется
познакомиться со следующими книгами:


Буч Г., Максимчук Р.А., Энгл М.У., Янг Б.Дж., Коналлен Д., Хьюстон К.А.
Объектно-ориентированный анализ и проектирование с примерами приложений
(UML 2) или


Fowler M., Scott K. UML Distilled. A Brief Guide to the Standard Object
Modeling Language.


[4] Здесь мы специально не останавливаемся на модели и структуре
коммуникативного акта. Также не будем обсуждать вопросы контекста и
невербальных компонент коммуникации.


[5] Мы можем объединить представления с восприятиями, для которых
впечатления и акты поведения выступают вместо отпечатков, оставляемых
ими в сознании. Для нас различие между представлениями и восприятиями
несущественно, тем более что в общую картину действительности, наряду с
самими ощущениями и актами поведения, входят воспоминания о них. При
этом восприятие можно рассматривать также и как вещь, поскольку вещи
воспринимаются органами чувств или носят пространственный характер.
ссылка Г.Фреге.


[6] Поэтому нецелесообразно употреблять слово представление для столь
разных понятий. ссылка Г.Фреге.


[7] Наверное, между смыслами выражений.


[8] Вопрос только в характере этих отношений.


[9] Собственно последующие рассуждения Г. Фреге подтверждает наше
предположение.


[10] При этом Г. Фреге делает интересную оговорку: Правда, истинность
интересует нас далеко не всегда. Например, при чтении эпоса нас волнуют,
наряду с красотой языка, только смысл предложений и вызываемые ими
представления (образы) и чувства. Вопрос об истинности этих предложений
увел бы нас из сферы художественного восприятия в сферу научных
изысканий. Вот почему, коль скоро мы воспринимаем поэму Гомера только
как художественное произведение, нам безразлично, в частности, имеет имя
Одиссей денотат или нет.


[11] Сейчас бы Г. Фреге такого заявления бы не сделал!


[12] Математики в случае такого утверждения потребовали бы
доказательства его истинности, несмотря на то, что данное утверждение
содержится в повествовательном предложении, т.е. фактически потребовали
построения его функции истинности. По сути дела, доказательство является
построением функции истинности для формального утверждения.


[13] Два выражения считаются одинаковыми, если они всегда могут
подставляться одно вместо другого, причем истинность целого не
изменяется Прим. перев. работы Г. Фреге.


[14] По Г. Фреге это, наверное, означало бы логическую синонимию.


[15] Ясно, что сейчас представления о возможных типах денотатов гораздо
шире. Но традиция принимать логические значения в качестве денотатов
предложений настолько сильно укоренилась в логической семантике и др.
подобных дисциплинах, что мешает дальнейшему развитию понимания проблемы
смысла и значения. Это прослеживается в многочисленных
логико-семантических трудах нашего времени (спустя более чем 100 лет от
момента написания Г. Фреге рассматриваемой работы), что собственно и
вызвало у автора желание досконально разобраться с этим мнением.


[16] Я не буду говорить о их эквивалентности.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru