Boatman's Home:  О сайте   Новости   Карта  
Статьи и заметки о менеджменте и системном анализе в ИТ + мысли о трудовых отношениях, рынках труда, услуг и программных продуктов
Это страница на старом движке. Новые статьи здесь
2011-01-08 01:35    Boatman   Обсудить в Google Groups   Перейти на страницу обсуждений

Данная статья создана для размещения на сайте boatmanshome.ru. Автор и обладатель исключительного права на эту статью - Нужненко Сергей Александрович.
Для данной статьи автор разрешает размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях.
Без согласования с автором запрещается для данной статьи или любой ее части воспроизведение в коммерческих целях, а так же любые распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
Для согласования видов использования статьи можно связаться с автором по e-mail: haron@ru.ru с пометкой в теме "Boatmanshome-text-use".

Как читать диаграммы, и все такое...

Введение
Моделирование
   Модель
   Текст
   Графика
Графическое моделирование, как оно есть
   Подходы к рисованию
   Назначение графических моделей
   Модель и метамодель
   Контекст диаграммы
Чуть ближе к ИТ
   Организация модели (пара мыслей)
   Параметры назначения графических моделей
      Моделируемые объекты и отвечаемые вопросы
      Границы
      Детализация
      Полнота
      Взаимосвязи слоев
      Когда фиксировать параметры слоев модели
   Классификация диаграмм
   Еще пара вопросов
В итоге

Я уже писал о диаграммах и хочу вернуться к теме снова.

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

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

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

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

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

Введение  ^

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

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

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

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

Моделирование  ^

Модель  ^

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

Оно говорит нам, что модель - это заместитель оригинала, с помощью которого мы изучаем ЛИШЬ некоторые свойства оригинала. Если мы могли бы изучать все свойства оригинала, то модель сама была бы оригиналом.

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

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

Текст  ^

Когда баба Зина говорит бабе Маше, сидя на лавочке во дворе у подъезда: "А знаешь, внучка Петровны, та, что из 19й квартиры, вчера дома не ночевала - совсем от рук отбилась, еще 18ти нет, а уже гуляет...", она строит модель девушки из 19й квартиры. Из этой модели мы узнаем ЛИШЬ НЕКОТОРЫЕ свойства обсуждаемого человека, тогда как все остальные свойства мы не знаем.

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

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

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

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

Более подробно достоинства и недостатки разных форматов представления информации мы разбирали в предыдущей статье про диаграммы.

В итоге для написанного текста были придуманы более развитые инструменты:
- для облегчения ориентирования:
-- форматированный текст, отделяющий части текста друг от друга;
-- список, разделяющий текст на блоки;
-- иерархический список, выстраивающий текст в дерево;
- для облегчения создания:
-- шаблоны формулировок;
- для того и для другого:
-- Таблица;
-- Шаблонная структура документа.

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

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

Графика  ^

И, наконец, чистая графика - это кинематические, электрические, гидравлические и технологические схемы, машиностроительные и строительные чертежи, планы и карты и многе другое. Ключевой особенностью таких моделей является то, что они отражают узкие аспекты реальности для целей последующей формальной обработки с использованием ПРИЛАГАЕМОГО МАТЕМАТИЧЕСКОГО АППАРАТА.

Адекватность модели - это способность отражать избранные свойства объекта-оригинала.

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

В технике существуют сотни видов графических моделей со своими правилами интерпретации.

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

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

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

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

Графическое моделирование, как оно есть  ^

Подходы к рисованию  ^

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

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

Назначение графических моделей  ^

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

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

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

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

Вот пример: на диаграмме ниже (ex1) просмотр может быстро давать выводы следующего вида: "Я архивариус, значит, буду читать тексты ВИ4..6";"я пользователь, значит буду читать тексты ВИ1..4".

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

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

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

Опять хочу подчеркнуть, что ценность диаграммы не в самой выдаче информации, а в БЫСТРОЙ И БЕЗОШИБОЧНОЙ выдаче. В процессе анализа и синтеза мы задаем себе и другим сотни и тысячи вопросов, по этому скорость и безошибочность ответов прямо влияет на скорость и точность аналитической работы.

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

На примере (ex4) показан состав классов информации, хранимой в системе (информационный объем). Состав и связи классов получаются на основе анализа потоков данных (ех3) и логики их обработки (она будет в текстах ВИ, спецификациях функций или в подобных артефактах).

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

Диаграмма из предыдущего примера (ex5) может давать списки покупных и разрабатываемых компонентов (а, по спискам и стоимость/время закупки/разработки) и контрольные списки для плана развертывания системы (что установить, что настроить, наличие чего проверить).

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

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

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

Модель и метамодель  ^

Коллеги часто задают вопрос, с чего начинать: с извлечения текста или с рисования модели? Этот вопрос подобен классическому "курица или яйцо".

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

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

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

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

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

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

Теперь обсудим метамодель.

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

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

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

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

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

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

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

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

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

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

И еще один момент: правила рисования проще описывать, когда под рукой уже есть диаграмма, то есть они документируются после создания (первой) диаграммы и поддерживаются по мере ее развития. Лучший момент создания первой редакции раздела или документа "как читать диаграммы" - первая поставка диаграмм(ы) на ревью.

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

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

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

Контекст диаграммы  ^

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

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

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

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

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

В одной из моих презентаций этот метод так же условно называется "полка в магазине". Имеется ввиду такой мысленный эксперимент: вы покупатель перед прилавком космического магазина, затерянного в глубинах вселенной. Там никогда ничего не слышали и не знают про землю и то, как у нас все устроено, про вас лично, вашу организацию и ваш проект. За прилавком продавец и вы ему объясняете, что хотите купить. И вот какой диалог мы можем услышать:
- Дайте мне "роль".
- Роль? Вам каую?
- Ну дайте мне роль "Руководитель проекта".
- "Руководитель проекта"? Тысячи их!
- Ну дайте такую, которая участвует в активностях "Инициация", "Управление проектом", "Завершние проекта".
- У нас 9000 ативностей и в них 9000 ролей "Руководитель проекта".
- ...

Рано или поздно продавец принесет нам то, что мы хотим, если мы сможем свести количество объектов от 9000 до 1го.

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

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

Этот метод можно условно называть "Проверка стулом" или, по английски "stool chek" :)

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

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

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

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

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

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


Чуть ближе к ИТ  ^

Организация модели (пара мыслей)  ^

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

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

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

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

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

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

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

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

Самый простой (но не единственный) порядок проектирования такой:
1. концептуальная (схематичная) проработка - рассматриваются ключевые параметры системы и просчитываются ключевые свойства ее частей.
2. Архитектура (компоновка) - рассматривается точный состав и связи частей, просчитываются их взаимодействия.
3. Дизайн (деталировка) - принимаются детальные решения по устройству каждой части системы.

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

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

Как с этим быть мы сейчас будем разбираться.

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

И сейчас мы обсудим это подробнее.

Параметры назначения графических моделей  ^

Моделируемые объекты и отвечаемые вопросы  ^

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

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

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

Границы  ^

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

Для возможных границ при создании автоматизированной системы можно предложить такой вариант:
- граница между окружением объекта автоматизации (автоматизированной деятельности) и внутренностями объекта автоматизации.
- граница между объектом автоматизации (автоматизируемая деятельность) и программно-аппаратным комплексом.

Независимо от предыдущих мы можем провести границу между объектами, создаваемым в проекте (в примере ex5-1 - это разрабатываемое ПО) и объектами, предоставляемыми снаружи (в примере ex5-1 - это рабочие станции и сеть).

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

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

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

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

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

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

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

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

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

При этом само сетевое взаимодействие, обслуживающие его компоненты и транспортные протоколы прикладного уровня "вырезаны". Вместо них на диаграмме есть среда исполнения "MS Windows XP", заключающая в себе программные компоненты, обеспечивающие взаимодействие. А вместо отрезанных уровней взаимодействия проведена связь "depends", говорящая нам, что в конечном итоге это взаимодействие осуществляется, и заменяющая вырезанную часть с обеих сторон.

Можно видеть, что правила "отсечения" частей при моделировании в ИТ не так тривиальны, как в механике, но все-таки они тоже действуют.

Детализация  ^

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

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

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

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

Сущственным препятствием к освоению моделирования в ИТ является то, что для уровня детализации очень трудно дать рекомендации на все случаи жизни. Существуют некоторые попытки, наподобие шкал уровня варианта использования от А.Коберна (облака, уровень моря, дно), но они продолжают вызывать вопросы у новичков и требуют доопределения "на местах".

В этой ситуации единственно верными ориентирами служат вопросы "достаточно для чего?" и соображение о том, что избыточная детализация - это лишняя работа.

Не смотря на то, что фактически про детализацию я написал "it depends...", я могу привести требования по количеству изображений из машиностроительного черчения: Количество изображений (видов, разрезов, сечений) должно быть наименьшим, но обеспечивающим полное представление о предмете при применении установленных в соответствующих стандартах условных обозначений, знаков и надписей (ЕСКД ГОСТ 2.305-68).

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

Полнота  ^

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

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

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

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

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

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

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

Взаимосвязи слоев  ^

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

Мы должны установить взаимосвязи между объектами из разных слоев и требования по проверке таких взаимосвязей.

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

На UML activity диаграмме желательно использовать для потоков данных объекты классов, уже присутствующих на соответствующей UML Class диаграмме и состояния, присутствующие в Statemachine этих классов. Это тот же пример из связи статики и динамики.

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

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

На диаграмме из примера (ex3) показаны трассировки ВИ на функции.

На примере (ex5-1) показаны явные связи программных компонентов с пользователями.

Sequence диаграмма из примера (ex6) трассирует программные компоненты с диаграммы развертывания (ex5-1) на текст сценария варианта использования, проверяя таким образом полноту программного обеспечения с одной стороны и возможность реализации варианта использования - с другой.

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

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

Когда фиксировать параметры слоев модели  ^

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

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

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

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

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

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

Так, вместо точного указания иерархии диаграмм в модели перед большим обследованием (типа, 1 уровень - VAD, и 2 уровня eEPC), что ничего не дает, лучше сосредоточиться на целях моделирования: что нужно получить в итоге (например, описание процессов в нотациях VAD и eEPC, дающее подход к определению реалистичных целевых показателей объекта после автоматизации, точки автоматизации (функции по участкам), а так же подход к определению численности и ролей персонала создаваемой АС).

Классификация диаграмм  ^

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

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

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

Группа Нотация Уровень абстракции Статика/динамика Объекты Связи Комментарий
- Mind Map любой Чаще всего структурные связи (границы) Что угодно Произвольные связи Моделирование "на салфетке", концептуальный этап
- Structure tree любой Связи состава (объем) Объекты одной категории/аспекта Иерархия, деление объема на части Заменимо на иерархический список
- Org Chart таксономия связи состава (объем) Должности, люди, роли, подразделения, организации Иерархия подчинения -
- Time Line точное время динамика события и состояния объектов раньше/позже -
- Function Graph (график функции) точное время динамика Численная величина Зависимость от времени Может так же применяться для задания связей между любыми величинами, состояниями и объектами
- Fishbone/Root&Cause (рыбья кость) причина-следствие динамика факторы: состояния разных объектов причинно-следственные -
- Fault tree любой динамика события причинно-следственные -
- BPMN все возможные цепочки переходы по состояниям активности, входы и выходы, события, исполнители вход/выход, до/после, кто исполняет -
SADT DFD причина-следтствие потоки функции, входы и выходы входы и выходы -
SADT IDEF0 причина-следтствие потоки функции, входы и выходы, исполнители входы и выходы, кто исполняет -
SADT IDEF1 классы, атрибуты и связи статика сущности и атрибуты любые отношения -
SADT IDEF3 все возможные цепочки переходы по состояниям активности, входы и выходы, события вход/выход, до/после -
ARIS eEPC все возможные цепочки переходы по состояниям активности, входы и выходы, события, исполнители вход/выход, до/после, кто исполняет -
ARIS Objective причина-следтствие система целей цели цель-подцель -
ARIS VAD категории и аспекты границы и связи участки деятельности, исполнители, ключевые выходы направление цепочки прибавленной стоимости, выходы/входы, кто исполняет -
UML Use Case причина-следствие система целей цели пользователя, действующие лица, границы систем и подсистем отношения целей (цель-подцель, предшествование, обобщение и реализация), задействованные в достижении роли, достижение с помощью систем/подсистем, принадлежность ролей системам/подсистемам -
UML Class классы, атрибуты и связи статика классы, атрибуты любые связи -
UML Activity все возможные цепочки переходы по состояниям активности, входы и выходы, события, исполнители вход/выход, до/после, кто исполняет -
UML Interaction overview все возможные цепочки переходы по состояниям активности, входы и выходы, события, исполнители вход/выход, до/после, кто исполняет -
UML Deployment таксономия связи взаимодействия устройства ПТК, программные компоненты связи взаимодействия программно-аппаратных компонентов -
UML Object единичный объем статика любые объекты любые статические связи -
UML Component Классы, атрибуты и связи связи взаимодействия программные компоненты динамические связи программных компонентов -
UML Statemachine таксономия переходы по состояниям состояния возможные переходы -
UML Package таксономия статика пакеты связи трассировки -
UML Sequence таксономия переходы по состояниям любые объекты сообщения -
UML Communication Sequence таксономия переходы по состояниям любые объекты связи динамического взаимодействия, сообщения -
UML Timing Единичный объем динамика состояния или значения время изменения -

Еще пара вопросов  ^

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

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

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

Вся выводимая информация так или иначе должна быть обеспечена вводом - это надо проверять.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В итоге  ^

В итоге я благодарю читателей за внимание и кратко перечисляю тезисы этой статьи:
- Графическая модель несет строго заданное количество информации, а ее проверка и эквивалентные преобразования осуществляются преобразованием графики в набор текстовых высказываний;
- Графическая модель применяется для интенсивной работы со связями;
- Полезно иметь соглашение "как читать диаграммы", задающее однозначное преобразование шаблонной картинки в шаблонное высказывание.
- Метамодель - это вопросник, показывающий какие могут существовать слои, объекты и связи при моделировании. В данном тексте я не включаю в метамодель соглашение "как читать диаграммы", цели моледирования и другие параметры назначения, связи между слоями, другие проверки и описываю их отдельно. Иногда под метамоделью понимают все перечисленное вместе плюс набор возможных операций по извлечению из модели интересующей нас информации.
- Метамодель (в узком понимании) и соглашение "как читать диаграммы" полезно иметь хотя бы в голове.
- Кроме этого при моделировании необходимо держать в голове или даже задокументировать:
-- вопросы, отвечаемые моделью (возможно, так же операции по извлечению нужных нам сведений);
-- Установку границ и отношения к ним изображаемых объектов (черный ящик, прозрачный и т.п.);
-- Необходимую детализацию модели;
-- Необходимую полноту модели (что перекликается с установкой границ);
-- Взаимосвязи слоев и проверки трассируемост между слоями;
- Необходимо понимать, что параметры моделирования могут меняться в ходе моделирования, по этому их преждевременная фиксация может быть вредна.
- Все виды нотаций, применяемых в ИТ по сути могут быть классифицированы в двух измерениях: статика-динамика (или структура-функция) + низкая абстракция-высокая абстракция (или конкретные единичные бъемы под моделью-огромные объемы под моделью). Некоторые диаграммы универсальны (например, сущность-связь), другие предназначены для изображения определенных видов объектов и связей (например, оргструктура или UML Component Diagram).
- Базовым балансовым "уравнением" для автоматизированной системы является баланс информационного или информационно-матеиального потока. Этот баланс никогда не нарушается в действительности и должен сходиться по расчетам. Так же мы пречислили другие виды основных расчетов и ввели само понятие базовых расчетов при проектировании автоматизированной системы.

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

Еще раз благодарю за внимание. С вопросами и предложениями по теме прошу писать мне ( здесь актуальные контакты ).