Ну, будем исходить из того, что "персонаж" - это экземпляр пользователя как части исполнителя нашей задачи. И нужен для решения этой задачи создания другой части - пользуемой искусственной системы:
Если не продумывать именно работу другого человека (и разных людей) и с программой, и с её документами с т. зр. эргономичности и не создавать программу от этого - то ...
Это называется разработкой
типовых сценариев работы пользователя с программой. Очень полезная вещщщь для продумывания и разработки интерфейса будущей программы.
С учётом порядка разработки как моделирования/формализации, основной вопрос - как мы от поведения персонажей приходим к спецификации системы? Возможен такой ответ:
И еще раз кратко остановлюсь на вопросе Геннадия:
Как осуществляется переход от персонажей к самому интерфейсу?
Во-первых, после формирования персонажей составляются подробные матрицы: что делают персонажи, чем они при этом пользуются, как часто они это делают и т.д. Причем, как вы понимаете, в описание включаются все данные, а не только непосредственно бизнес-сценарии и артефакты самой системы. Исходя из этих данных, затем можно сделать вывод, как именно реализовывать ту или иную функцию системы. Вот «деланье выводов», сиречь синтез интерфейсных решений – это самая творческая часть, и рецептов конкретных дать нельзя. Но, чем больше мы учли, тем проще делать эти выводы.
Ну, в общем понятно, что не только алгоритмы поведения нужно включать.
А что? А. Коберн по-своему отвечает - можно задать "варианты использования" (ВИ), подразумевая разных лиц (понятно, что одному лицу м.б. назначены разные ВИ). Важно, что в его понимании искусственная система - объект разработки (SuD) сама есть "действующее лицо" (персонаж) особого рода.
В общем понятно, что метод ВИ - это языково-независимая вещь. Хотя сам Коберн говорит: "прежде всего научитесь писать понятные тексты". Сам ВИ - это [пред]информодель функции, выделенной на основании определения целей пользователя. Как можно понять в терминах "доказательного программирования", ВИ включает алгопроцесс (включая учтённые исключительные ситуации исполнения как "расширения"), его контракты (предусловие, постусловие как "гарантию успеха"), актив-модель (изначально - как перечисление сущностей и их "интересов"), деклар-модель (изначально - через употребление объектов в тексте ВИ).
Как же нам двигаться от этого к спецификации задачи (желательно формальной
)? Коль скоро описываем функции - возникает мысль составить функциональную модель. Она м.б. визуальной - скажем на ФМ-языке IDEF0. Что м.б. проиллюстрировано
этим примером.
Однако сей пример также иллюстрирует критику такого подхода, скажем, alexus. Ведь переход от обобщённой, "интегральной" модели к "дифференциальной" неочевиден. Вот и тут использованы некие "общие соображения", как воплотить ФМ контроля датчиков в программно-аппаратную систему контроля. Сочинитель-то (при известных усилиях
) сможет их сформулировать - но вне ФМ и часто специфично для задачи - так что читателю надо будет объяснять отдельно...
А есть и иной подход - сразу идти от взаимодействия системы и пользователя. Скажем, представляя их динамику как графы переходов между состояниями. Подобно этому:
Вложение:
СТА-АСУпрИМ-ст(сх_реж_работы).gif [ 897.28 КБ | Просмотров: 7391 ]
По сути, имеем информатизацию персонажей - в виде обобщённой модели, но для которой известны методики перехода к "дифференциальной" с программной строгостью. Нетрудно догадаться, что речь прежде всего об
"автоматном программировании"...
Ну и вопрос - как можно переходить с сохранением визуальной формы? У
"безоглядных сторонников", наверное, прежде всего возникнут в памяти схемы из /Паронджанов, 2001, с. 262/. Но и здесь целесообразней исходить из синтеза "доказательного" и "автоматного" - поэтому оптимальной формой импер-части будет
дейкстрал. Ну и остальные части забывать не следует - как не забывают и "автоматчики" - см. /
Поликарпова, Шалыто, 2010, п. 2.2.1/ как ориентир для актив-визуализации.
Вот такие соображения. Возможно, у кого-то найдётся ещё что сказать?..