Ну, будем исходить из того, что "персонаж" - это экземпляр пользователя как части исполнителя нашей задачи. И нужен для решения этой задачи создания другой части - пользуемой искусственной системы:> -- igor в viewtopic.php?p=68814#p68814 писал(а):
> Это называется разработкой с программой. Очень полезная вещщщь для продумывания и разработки интерфейса будущей программы.С учётом порядка разработки как моделирования/формализации, основной вопрос - как мы от поведения персонажей приходим к спецификации системы? Возможен такой ответ:> -- Платон Днепровский в http://www.gui.ru/platon/?p=20 писал(а):
> И еще раз кратко остановлюсь на вопросе Геннадия:Как осуществляется переход от персонажей к самому интерфейсу?Во-первых, после формирования персонажей составляются подробные матрицы: что делают персонажи, чем они при этом пользуются, как часто они это делают и т.д. Причем, как вы понимаете, в описание включаются все данные, а не только непосредственно бизнес-сценарии и артефакты самой системы. Исходя из этих данных, затем можно сделать вывод, как именно реализовывать ту или иную функцию системы. Вот «деланье выводов», сиречь синтез интерфейсных решений – это самая творческая часть, и рецептов конкретных дать нельзя. Но, чем больше мы учли, тем проще делать эти выводы.Ну, в общем понятно, что не только алгоритмы поведения нужно включать.А что? А. Коберн по-своему отвечает - можно задать "варианты использования" (ВИ), подразумевая разных лиц (понятно, что одному лицу м.б. назначены разные ВИ). Важно, что в его понимании искусственная система - объект разработки (SuD) сама есть "действующее лицо" (персонаж) особого рода.
В общем понятно, что метод ВИ - это языково-независимая вещь. Хотя сам Коберн говорит: "прежде всего научитесь писать понятные тексты". Сам ВИ - это [пред]информодель функции, выделенной на основании определения целей пользователя. Как можно понять в терминах "доказательного программирования", ВИ включает алгопроцесс (включая учтённые исключительные ситуации исполнения как "расширения"), его контракты (предусловие, постусловие как "гарантию успеха"), актив-модель (изначально - как перечисление сущностей и их "интересов"), деклар-модель (изначально - через употребление объектов в тексте ВИ).

Как же нам двигаться от этого к спецификации задачи (желательно формальной)? Коль скоро описываем функции - возникает мысль составить функциональную модель. Она м.б. визуальной - скажем на ФМ-языке IDEF0. Что м.б. проиллюстрированоэтим примером.
Однако сей пример также иллюстрирует критику такого подхода, скажем, alexus. Ведь переход от обобщённой, "интегральной" модели к "дифференциальной" неочевиден. Вот и тут использованы некие "общие соображения", как воплотить ФМ контроля датчиков в программно-аппаратную систему контроля. Сочинитель-то (при известных усилиях) сможет их сформулировать - но вне ФМ и часто специфично для задачи - так что читателю надо будет объяснять отдельно...

А есть и иной подход - сразу идти от взаимодействия системы и пользователя. Скажем, представляя их динамику как графы переходов между состояниями. Подобно этому:Вложение:
СТА-АСУпрИМ-ст(сх_реж_работы).gif [ 897.28 КБ | Просмотров: 8144 ]
По сути, имеем информатизацию персонажей - в виде обобщённой модели, но для которой известны методики перехода к "дифференциальной" с программной строгостью. Нетрудно догадаться, что речь прежде всего об"автоматном программировании"...

Ну и вопрос - как можно переходить с сохранением визуальной формы? У"безоглядных сторонников", наверное, прежде всего возникнут в памяти схемы из /Паронджанов, 2001, с. 262/. Но и здесь целесообразней исходить из синтеза "доказательного" и "автоматного" - поэтому оптимальной формой импер-части будетдейкстрал. Ну и остальные части забывать не следует - как не забывают и "автоматчики" - см. /Поликарпова, Шалыто, 2010, п. 2.2.1/ как ориентир для актив-визуализации.

Вот такие соображения. Возможно, у кого-то найдётся ещё что сказать?..