Пояснения по диаграмме данных

> -- Цитата:
> Создадим диаграмму для структуры данных модуля Index.	Очевидно, что самой главной сущностью, владельцем, является сам модуль.	Важно: здесь модуль является сущностью и владельцем, потому что у него есть переменные, через и идёт доступ к данным. Т.е. тут модуль является как бы и объектом, в единственном экземпляре.	А вот модули Dogs, Lamps, Arrows из предыдущего ООП-примера не являются сущностями - они не хранят в себе данные и не занимаются управлением созданными объектами. Они всего лишь хранят описания типов данных.		Итак, вверху нашей диаграммы - сущность модуль Index. Какие переменные модуля мы на ней отразим? currentDoc можно не отражать, он не существенен для понимания структуры данных, он имеет чисто служебное значение для процедур.	А wordsTable и allDocuments - существенны.			Но! Мы должны понимать, что элемент массива - это не отдельная сущность Word, это список сущностей Word. Особенность реализации - что этот список никак явно не именуется (мы не вводим тип данных WordList, и т.п.) И у нас переменная типа Word всегда может обозначать как указатель на отдельное слово (сущность Word), так и указатель на список слов (не названная в программе явно сущность "связанный список из Word").	wordsTable: ARRAY 60*60*60 OF Word,		где элемент - связанный список из Word	allDocuments: Document		связанный список из Document			Строим связь один-ко-многим одноправленную от сущности модуля к сущности СПИСОК ИЗ Word. Атрибут связи со стороны модуля (т.е. через что идёт связь) - переменная wordsTable.		Дальше связь один-ко-многим однонаправленную от сущности СПИСОК ИЗ Word к сущности Word. Связь в списке осуществляется через поля next.		У сущности Word отражаем её поля. Если бы их было много, мы бы что-то не показывали, но раз их немного, то можно все. Кроме поля next, которое, вообще говоря, относится к концепции списка, а не самой сущности Word.		Есть соблазн не отражать на диаграмме отдельно сущность DocLink. Типа, это всего лишь частная реализация связи один-ко-многим от Word к Document.	Но! Эта сущность может становиться важной, если мы будем развивать систему. Мы можем захотеть хранить информацию о местах вхождения слова в документ (чтобы сразу показывать и подсвечивать, например, и т.п.) - и всё такая доп. информация о вхождении слова окажется в сущности DocLink.	Поэтому прорисуем эту сущность, как подчинённую к Word.		Мы встретились как раз с тем случаем, о котором сказано в документации ERIL: когда связь "один-ко-многим" является односторонней со стороны DocLink. Т.е. DocLink ссылается на единственный Document. Получается, что на Document ссылается много DocLink-ов. Но узнать для Document множество этих DocLink-ов нельзя, оно не хранится. Поэтому получается, связь односторонняя - и изобразили мы её стрелкой, а не "лапой".		Мы строили диаграмму по коду, как иллюстрацию кода, поэтому она недостаточно абстрактна, содержит детали реализации на конкретном языке.	Если бы мы сначала проектировали модель данных, а потом по ней реализовывали на конкретном языке, то у нас бы была более "чистая" модель. Она бы переводилась на конкретный язык различным образом: допустим, при реализации на Java мы бы использовали не связные списки, а контейнеры ссылок на объекты.