Рис. 1. Верхняя панель инструментов

Рис. 2. Боковая панель инструментов. Блок "Перечисления"

В системе ELMA выделяют системные и пользовательские объекты и перечисления. Пользовательские объекты и перечисления создаются администратором системы в Дизайнере ELMA.

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

Пользовательские объекты или перечисления – это объекты или перечисления, спроектированные и настроенные в Дизайнере ELMA с учетом требований каждой конкретной компании. Данные объекты и перечисления могут быть созданы пользователями системы, изменены и/или удалены . В списке пользовательские объекты и перечисления отображены черным цветом.

Режимы отображения объектов и перечислений в списке

Списки объектов и перечислений могут быть отображены в нескольких режимах: "Отображаемое имя" и "Имя класса". Выбор режима отображения объектов и перечислений осуществляется из выпадающего списка (рис. 3), расположенного в поле Показывать в боковом меню вкладки Объекты в Дизайнере ELMA.

Рис. 3. Дизайнер ELMA. Вкладка "Объекты". Поле "Показывать"

Каждый объект и перечисление имеют несколько имен:

Отображаемое имя – имя объекта и/или перечисления, отображаемое списке объектов в Дизайнере ELMA, в карточке объекта и/или перечисления на вкладке Общие в поле Отображаемое имя * (рис. 4), а также в веб-приложении .

Рис. 4. Дизайнер ELMA. Вкладка "Объекты". Режим отображения "Отображаемое имя"

Имя класса – уникальное имя объекта и/или перечисления, задаваемое латинскими символами и отображаемое в списке объектов в Дизайнере ELMA, в карточке объекта и/или перечисления на вкладке Общие в поле Имя класса * (рис. 5).

Рис. 5. Дизайнер ELMA. Вкладка "Объекты". Режим отображения "Имя класса"

Особенности отображения объектов и перечислений

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

Кнопки верхней панели инструментов

Резюме

Недостатки модели TCP/IP

Несмотря на огромную популярность, у модели TCP/IP и ее протоколов имеется ряд недостатков:

· отсутствие разграничений концептуальных понятий интерфейса, протокола и уровневого сервиса, что достаточно четко сделано в модели ISO/OSI. Вследствие этого модель TCP/IP не может применяться при разработке новых сетей;

· с помощью модели TCP/IP нельзя описать никакой другой стек протоколов, кроме TCP/IP;

· в модели не различаются физический и канальный уровни, в то время как они абсолютно разные и в корректной модели это должно учитываться;

· наиболее тщательно продуманы и проработаны протоколы IP и TCP. Многие из других протоколов стека разрабатывались студентами (студентам к размышлению!) и свободно распространялись, вследствие чего широко укоренились в практике и теперь их трудно заменить на что-либо новое, предлагаемое по коммерческой схеме.

В качестве резюме отметим, что модель ISO/OSI является полезной для теоретических исследований и разработок новых сетей, хотя протоколы OSI не получили широкого распространения. Для TCP/IP можно сделать обратное утверждение: стек не может рассматриваться в качестве полноценной модели, тогда как сами протоколы хорошо апробированы и чрезвычайно популярны.

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

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

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

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

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

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

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

Иерархия программного обеспечения (ПО) может быть представлена в следующем виде:

· прикладное ПО;

· промежуточное ПО;

· базовое ПО.

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

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

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

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

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

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

К базовому ПО относятся и объекты обработки и хранения данных, реализуемые в таких программных комплексах, как СУБД (системы управления базами данных), базовое ПО сервера обработки транзакций и др.

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

Различают следующие типы объектных интерфейсов (программных интерфейсов):

· прикладной протокол (Application Protocol, АР) – логический интерфейс между прикладными объектами;

· интерфейс прикладных программ (Application Program Interface, API) – логический интерфейс между прикладными объектами и объектами промежуточного ПО, которые поддерживают прикладные объекты;

· протокол промежуточного ПО (Managing Protocol, МР) – логический интерфейс между объектами промежуточного ПО;

· интерфейс базовых программ (Base Program Interface, ВРІ) – логический интерфейс между объектами промежуточного и базового ПО, которые поддерживают объекты промежуточного ПО;

· интерфейс человек-компьютер (User-Computer Interface, UCI) – логический интерфейс между пользователем и, главным образом, объектами базового ПО, однако он может включать в себя также логический интерфейс с объектами промежуточного ПО и даже объектами приложений.

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

Рассмотрим процесс построения объектной модели для системы банковского обслуживания (см. п. 1.3) в процессе анализа требований и предварительного проектирования этой системы. Для построения объектной модели рассматриваемой системы нам необходимо выполнить все этапы, перечисленные в п.2.2.

2.3.1. Определение объектов и классов

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

Исследуем этот список, исключая из него имена классов в соответствии с рекомендациями п. 2.2.1:

избыточные классы : ясно, что клиент и пользователь означают одно и то же понятие; для банковской системы более естественно оставить класс клиент;

нерелевантные классы : таким классом является класс цена (он не имеет непосредственного отношения к работе банковской сети);

нечётко определённые классы : такими классами являются служба ведения записей и проверка безопасности (эти службы входят в состав проводки), система (в нашем случае непонятно, что это такое), банковская сеть (вся наша программная система будет обслуживать банковскую сеть);

атрибуты : данные проводки, данные счёта, деньги (имеются в виду реальные деньги, выдаваемые клиенту кассиром или банкоматом, либо принимаемые кассиром), квитанция (выдаётся клиенту вместе с деньгами) более естественно иметь в качестве атрибутов;

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

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

2.3.2. Подготовка словаря данных

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

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

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

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

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

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

Клиент – держатель одного или нескольких счетов в банке. Клиент может состоять из одного или нескольких лиц, или организаций. То же самое лицо, держащее счёт и в другом банке, рассматривается как другой клиент.

Компьютер банка – компьютер, принадлежащий банку, который взаимодействует с сетью ATM (банкоматов) и собственными кассовыми терминалами банка. Банк может иметь свою внутреннюю компьютерную сеть для обработки счетов, но здесь мы рассматриваем только тот компьютер банка, который взаимодействует с сетью ATM.

Консорциум – объединение банков, которое обеспечивает работу сети ATM (банкоматов). Сеть передаёт в консорциум проводки банков.

Проводка – единичный интегрированный запрос на выполнение некоторой последовательности операций над счетами одного клиента. Было сделано предположение, что ATM (банкоматы) только выдают деньги, однако для них не следует исключать возможности печати чеков или приёма денег и чеков. Хотелось бы также обеспечить гибкость системы, которая в дальнейшем обеспечит возможность одновременной обработки счетов разных клиентов, хотя пока этого не требуется. Различные операции должны быть правильно сбалансированы.

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

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

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

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

Основные положения объектной модели

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

. (object-oriented analysis, ООА) направлен на создание моделей реальной действительности на основе объектно-ориентированного мировоззрения.

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

. (object-oriented design, ООД)

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

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

В данном определении содержатся две важные части: объектно-ориентированное проектирование

1) основывается на объектно-ориентированной декомпозиции;

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

Именно объектно-ориентированная декомпозиция отличает объектно-ориентированное проектирование от структурного, в первом случае логическая структура системы отражается абстракциями в виде классов и объектов, во втором - алгоритмами.

. (object-oriented programming, OOП)

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

В данном определении можно выделить три части:

1) OOП использует в качестве базовых элементов объекты, а не алгоритмы;

2) каждый объект является экземпляром какого-либо определенногокласса;

3) классы организованы иерархически .

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

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

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

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

абстрагирование;

инкапсуляция;

модульность;

иерархия.

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

типизация;

параллелизм;

сохраняемость.

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

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

Абстракция основывается на понятиях клиента и сервера.

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

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

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

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

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

Модульность - это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.

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

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

Иерархия - это упорядочение абстракций, расположение их по уровням.

Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия "is-a") и структура объектов (иерархия "part of").

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

Если иерархия "is а" определяет отношение "обобщение/специализация", то отношение "part of" (часть) вводит иерархию агрегации. В иерархии "part of" класс находится на более высоком уровне абстракции, чем любой из использовавшихся при его реализации.

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

Параллелизм - это свойство, отличающее активные объекты от пассивных.

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

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

Зачем нужна Объектная Модель (ОМ)

Кратко — чтобы в проекте не было вот этого:

Не поймите превратно. Я люблю пасту, но только в качестве еды.

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

Поэтому, Объектная Модель выполняет две важные функции :

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

Теперь подробнее о каждом из этих пунктов.

Справочник

Справочник позволяет отделить сущность и ее параметры от ее функционала. Это дает возможность быстро, одним взглядом понять как и из чего она состоит, как хранится в базе, как работает в логике игры и так далее. Такое простое восприятие сущностей позволяет программистам легко понять будущую архитектуру проекта и спроектировать то, как он будет создаваться еще до того, как они начнут воплощать его в коде. Такое четкое понимание может спасти от переработок в будущем, когда спустя год-полтора вдруг оказывается, что все работает не так, не хватает гибкости, это не предусмотрено а то вообще потребует полного рефакторинга 75% кода. Конечно, справочник ОМ — это не волшебная пилюля, но как минимизация таких рисков работает отлично при условии, что она грамотно составлена).

Кроме того, справочник позволяет сортировать игровые сущности по их типам, в то время как в Функциональной Спецификации они сортируются или описываются по функциональности. Например, у нас есть такая иерархия в ОМ:

• Игорвая сущность
  • Предмет
    • Оружие
      • Меч
    • Расходники
      • Бутылка

Но при описании геймплея у нас может быть совсем иная структура. Например:

• Боевая система
  • Начисление урона
  • Работа брони
  • Бутылки во время боя
  • Стрелковое оружие
  • Холодное оружие
• Крафт
  • Крафт бутылки
  • Крафт оружия
    • Стрелкового
    • Холодного

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

И обратный пример, если у нас весь диздок отсортирован в по иерархической системе сущностей: при описании боевой системы, она будет размазана по всему диздоку.

Наследование (pro feature)

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

• Игровая сущность (GameEntity)
  • Предмет (InventoryItem)
    • Одежда (Equipment)
      • Армор (Armor)

Ниже — как они выглядят в документации (естественно, в сокращенном виде, по 3-4 строки из ОМ):

Члены типа GameEntity (это верхняя, самая главная сущность в архитектуре проекта и то, как она хранится в БД)

Члены типа InventoryItem

Члены типа Equipment

Члены типа Armor

Как видно, Armor — это последняя сущность в приведенном примере, и имеет всего три параметра: ArmorType, DamageReduxF, DamageReduxP . Однако он наследует из предыдущей сущности: DurabilityMax, DurabilityCurrent, Tiemype . В свою очередь, та сущность наследует: Volume, PlayMoneyPrice, realMoneyPrice, и так далее до самого верха.

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

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

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