Резервы программирования деятельности. Терминология
Программирование является одним из видов моделирования деятельности. Имеются следующие возможности повышения его эффективности: 1) ревизия и уточнение понятийно-терминологического аппарата в рассматриваемой предметной области; 2) расширение возможностей создания и использования программных моделей д...
Gespeichert in:
| Datum: | 2010 |
|---|---|
| 1. Verfasser: | |
| Format: | Artikel |
| Sprache: | Russian |
| Veröffentlicht: |
Інститут проблем математичних машин і систем НАН України
2010
|
| Schriftenreihe: | Математичні машини і системи |
| Schlagworte: | |
| Online Zugang: | http://dspace.nbuv.gov.ua/handle/123456789/47426 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Zitieren: | Резервы программирования деятельности. Терминология / О.В. Малышев // Мат. машини і системи. — 2010. — № 1. — С. 150-161. — Бібліогр.: 28 назв. — рос. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| id |
irk-123456789-47426 |
|---|---|
| record_format |
dspace |
| spelling |
irk-123456789-474262013-07-15T03:06:58Z Резервы программирования деятельности. Терминология Малышев, О.В. Моделювання і управління великими системами Программирование является одним из видов моделирования деятельности. Имеются следующие возможности повышения его эффективности: 1) ревизия и уточнение понятийно-терминологического аппарата в рассматриваемой предметной области; 2) расширение возможностей создания и использования программных моделей деятельности за счет применения специальных систем; 3) создание и использование n -мерных программных метамоделей деятельности. Статья посвящена рассмотрению первой из указанных возможностей – терминологии. Програмування є одним із видів моделювання діяльності. Існують такі можливості підвищення його ефективності: 1) ревізія й уточнення понятійно-термінологічного апарату в даній предметній області; 2) розширення можливостей створення і використання програмних моделей діяльності за рахунок застосування спеціальних систем; 3) створення та використання n -мірних програмних метамоделей діяльності. Стаття присвячена розгляду першої із зазначених можливостей – термінології. Programming is one of types of activity modeling. There are the followings possibilities to increase the efficiency of activity programming: 1) a revision and clarification of concepts and terminology in the examined subject domain; 2) expansion of possibilities of creation and use of programmatic activity models due to application of the special systems; 3) creation and use of the n-dimensional programmatic activity metamodels. The article is devoted to consideration of the first of indicated directions – terminology. 2010 Article Резервы программирования деятельности. Терминология / О.В. Малышев // Мат. машини і системи. — 2010. — № 1. — С. 150-161. — Бібліогр.: 28 назв. — рос. 1028-9763 http://dspace.nbuv.gov.ua/handle/123456789/47426 004.4'23 ru Математичні машини і системи Інститут проблем математичних машин і систем НАН України |
| institution |
Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| collection |
DSpace DC |
| language |
Russian |
| topic |
Моделювання і управління великими системами Моделювання і управління великими системами |
| spellingShingle |
Моделювання і управління великими системами Моделювання і управління великими системами Малышев, О.В. Резервы программирования деятельности. Терминология Математичні машини і системи |
| description |
Программирование является одним из видов моделирования деятельности. Имеются следующие возможности повышения его эффективности: 1) ревизия и уточнение понятийно-терминологического аппарата в рассматриваемой предметной области; 2) расширение возможностей создания и использования программных моделей деятельности за счет применения специальных систем; 3) создание и использование n -мерных программных метамоделей деятельности. Статья посвящена рассмотрению первой из указанных возможностей – терминологии. |
| format |
Article |
| author |
Малышев, О.В. |
| author_facet |
Малышев, О.В. |
| author_sort |
Малышев, О.В. |
| title |
Резервы программирования деятельности. Терминология |
| title_short |
Резервы программирования деятельности. Терминология |
| title_full |
Резервы программирования деятельности. Терминология |
| title_fullStr |
Резервы программирования деятельности. Терминология |
| title_full_unstemmed |
Резервы программирования деятельности. Терминология |
| title_sort |
резервы программирования деятельности. терминология |
| publisher |
Інститут проблем математичних машин і систем НАН України |
| publishDate |
2010 |
| topic_facet |
Моделювання і управління великими системами |
| url |
http://dspace.nbuv.gov.ua/handle/123456789/47426 |
| citation_txt |
Резервы программирования деятельности. Терминология / О.В. Малышев // Мат. машини і системи. — 2010. — № 1. — С. 150-161. — Бібліогр.: 28 назв. — рос. |
| series |
Математичні машини і системи |
| work_keys_str_mv |
AT malyševov rezervyprogrammirovaniâdeâtelʹnostiterminologiâ |
| first_indexed |
2025-07-04T07:18:11Z |
| last_indexed |
2025-07-04T07:18:11Z |
| _version_ |
1836699868800745472 |
| fulltext |
150 © Малышев О.В., 2010
ISSN 1028-9763. Математичні машини і системи, 2010, № 1
УДК 004.4'23
О.В. МАЛЫШЕВ
РЕЗЕРВЫ ПРОГРАММИРОВАНИЯ ДЕЯТЕЛЬНОСТИ. ТЕРМИНОЛОГИЯ
Abstract. Programming is one of types of activity modeling. There are the followings possibilities to increase its
efficiency: 1) a revision and clarification of concepts and terminology in the examined subject domain; 2) expansion of
possibilities of creation and use of programmatic activity models due to application of the special systems; 3) creation
and use of the n -dimensional programmatic activity metamodels. The article is devoted to consideration of the first of
indicated possibilities – terminology.
Key words: activity, action, model, metamodel, process, operation, operand, operator, method of implementation of
operation, program, activity programming.
Анотація. Програмування є одним із видів моделювання діяльності. Існують такі можливості підвищення
його ефективності: 1) ревізія й уточнення понятійно-термінологічного апарату в даній предметній
області; 2) розширення можливостей створення і використання програмних моделей діяльності за рахунок
застосування спеціальних систем; 3) створення та використання n -мірних програмних метамоделей
діяльності. Стаття присвячена розгляду першої із зазначених можливостей – термінології.
Ключові слова: діяльність, дія, модель, метамодель, процес, операція, операнд, оператор, спосіб
виконання операції, програма, програмування діяльності.
Аннотация. Программирование является одним из видов моделирования деятельности. Имеются
следующие возможности повышения его эффективности: 1) ревизия и уточнение понятийно-
терминологического аппарата в рассматриваемой предметной области; 2) расширение возможностей
создания и использования программных моделей деятельности за счет применения специальных систем;
3) создание и использование n -мерных программных метамоделей деятельности. Статья посвящена
рассмотрению первой из указанных возможностей – терминологии.
Ключевые слова: деятельность, действие, модель, метамодель, процесс, операция, операнд, оператор,
способ выполнения операции, программа, программирование деятельности.
1. Введение
В настоящее время научно-технологический и социальный прогресс немыслим без того, что
повсеместно принято называть «моделированием бизнес-процессов». Думается, истоками этого
вида человеческой деятельности являются:
1) желание/необходимость усовершенствовать совместную целенаправленную
деятельность людей путем разработки соответствующих правил, регламентов, норм, должностных
инструкций и т.д., устанавливающих, что и как должно выполняться, а также права, обязанности и
ответственность участников деятельности;
2) изобретение компьютера, обеспечившее принципиальную возможность автоматизации
некоторых «фрагментов» человеческой деятельности, а также создания программируемого
оборудования, решающего совершенно новые задачи.
Отсюда проистекают соответственно две составляющие моделирования бизнес-процессов
как вида деятельности. Эволюция первой составляющей, в отсутствие научной информатики и ее
прикладных направлений, достигла своего промежуточного апогея к середине ХХ-го века,
удовлетворив многие насущные практические потребности, и на некоторое время
приостановилась. Однако с возникновением повышенных требований к качеству деятельности
(Международные стандарты (МС) ISO серии 9000 – версии 1987, 1994, 2000 и 2008 гг.) интерес к
средствам описания деятельности вновь усилился. Наиболее мощным импульсом для этого
послужило требование, которое можно связать с МС ISO серии 9000:2000, следовать при создании
систем менеджмента качества (СМК) т.н. «процессному подходу».
ISSN 1028-9763. Математичні машини і системи, 2010, № 1 151
В ходе эволюции второй составляющей очень скоро выяснилось, что развитие
программирования самого по себе – от программирования в кодах машины через алгоритмические
и др. языки к различным дисциплинам программирования (модульное, структурное,
композиционное, объектно-ориентированное и т.д.) – плохо справляется с фундаментальной
проблемой: отсутствие общего языка между, условно говоря, «заказчиком» и «программистом».
Языка, на котором можно было бы описать модель деятельности, нуждающейся в автоматизации.
Осознание этого факта послужило толчком для создания соответствующих специализированных
языков моделирования1 и средств их поддержки, например, стандарты Integrated Definition IDEF [1],
Unified Modeling Language (UML) [2], Event-Driven Process Chains (EPC) [3, 4], Business Process
Modeling Notation (BPMN) [5]. Их появление обеспечило принципиальную возможность, если и не
совсем устранить «пропасть непонимания» между «заказчиком» и «программистом», то
существенно уменьшить риски, связанные с ее преодолением.
Возвращаясь к первой составляющей, отметим, что МС ISO 9001:2000 [6] и его «преемник»
МС ISO 9001:2008 [7] содержат такую конфигурацию требований к описанию идентифицированного
в системе процесса, что в настоящее время ни один язык моделирования не может удовлетворить
все потребности, инспирированные стандартом. В этом легко убедиться, если предпринять попытку
по материалам стандарта сформировать шаблон описания «процесса» [8, 9]. С другой стороны,
например, из того же UML, который, в сущности, является конгломератом различных нотаций,
рассчитанных на различные аспекты моделирования систем, конструкторы СМК могут
использовать на практике совсем немногое. В настоящее время моделирование фактически
осуществляется по двум основным направлениям2:
1) функциональное моделирование, заключающееся в идентификации выполняемых
функций, их входов/выходов, средств выполнения и управления, а также декомпозиции функций.
Наиболее распространенным инструментом функционального моделирования являются
диаграммы IDEF0 [10], поддерживаемые с помощью, например, AllFusion Process Modeler (старое
название – BPwin) [11];
2) «алгоритмическое» моделирование, заключающееся в описании последовательностей
действий, которые необходимо выполнить в связи с возникновением определенных событий.
Широко используемыми инструментами такого моделирования являются, например, IDEF3 [12],
EPC [3] и т.д. вплоть до нотации BPMN3, развиваемой в настоящее время консорциумом OASIS
1 Мы используем термин «язык моделирования», хотя можно говорить также о «нотациях» и «стандартах».
2 Данная констатация основана на личных наблюдениях автора, а также на том, каким средствам
моделирования уделяется основное внимание в литературе, посвященной вопросам бизнес-моделирования
[13].
3 Первоочередная (по замыслу разработчиков) цель BPMN – предоставить нотацию, легко понимаемую всеми
деловыми потребителями, от бизнес-аналитиков, создающих первоначальные проекты процессов, до
технических разработчиков, ответственных за осуществление технологии, которая будет выполнять эти
процессы, и, наконец, до деловых людей, которые будут управлять этими процессами. Поэтому BPMN
рассматривается как стандартизированный мост через пропасть между разработкой проекта бизнес-процесса
и его внедрением. Разработчики BPMN претендуют на то, что развиваемая ими нотация станет нотацией
следующего поколения, которая обеспечит читабельность, гибкость и расширяемость (наращиваемость),
вобрав в себя лучшее из других известных нотаций, таких как, например, UML Activity Diagram, UML EDOC
Business Processes, IDEF, ebXML BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM, and Event-
Process Chains (EPCs). Другая цель, не менее важная, – обеспечить средствами визуализации языки XML,
предназначенные для выполнения бизнес-процессов, как, например, BPEL4WS [16].
ISSN 1028-9763. Математичні машини і системи, 2010, № 1 152
(Organization for the Advancement of Structured Information Standards) [14]4. Для того, чтобы
нарисовать блок-схему, можно воспользоваться, например, MS Visio, поддерживающим множество
известных нотаций.
Слово «алгоритмическое» взято в кавычки, поскольку оно лишь образно отражает суть
вопроса. На мой взгляд, более уместным в данном случае было бы говорить о «программировании
деятельности», которое в свое время попытался ввести в обиход А.Л. Фуксман в работе [15],
описавший, пожалуй, первый язык программирования деятельности АКТ.
Разумеется, попытка реанимировать понятие «программирование деятельности» требует,
как минимум, соотнести его с другими понятиями, применяемыми в данной предметной области,
например, «моделирование бизнес-процессов», а как максимум – построить стройную понятийно-
терминологическую систему.
Что же касается самих программ деятельности, опыт показывает:
1) разрабатываемые для конкретных предметных областей модели деятельности могут
быть достаточно сложными. Если они разрабатываются с целью последующей автоматизации, то
борьба с этой сложностью ложится на плечи «программистов», которые «переводят» модель в
коды машины. Если же автоматизация по каким-либо причинам не предусматривается, то
возникает следующая ситуация: с одной стороны, есть корректные, но сложные модели, с другой –
люди, обязанные действовать согласно этим моделям. Но люди – не машины; их, конечно, можно
заставлять выполнять сложные программы, но нельзя при этом гарантировать, что это будет
осуществляться корректно и не будет сопряжено с возникновением различных нежелательных
побочных эффектов. В связи с этим возникает вопрос: а нельзя ли сделать так, чтобы
разработанная «алгоритмическая» модель деятельности являлась не полуфабрикатом,
нуждающимся в дополнительном программировании, а конечным продуктом, частично или
полностью обеспечивающим автоматизацию описываемой им деятельности? Наверное, да, если
поддержать создание и использование программ деятельности соответствующими средствами;
2) при построении программных моделей систем иногда остро ощущается необходимость
выхода за рамки одного измерения. Это происходит, например, тогда, когда данными,
обрабатываемыми одной программой, является информация о процессе выполнения другой
программы.
Таким образом, на данном этапе, на наш взгляд, практическую отдачу от программирования
деятельности можно существенно увеличить, исследовав и активизировав его скрытые резервы по
таким направлениям:
• совершенствование понятийно-терминологического аппарата в данной предметной
области;
• обеспечение создания и использования программ деятельности соответствующими
средствами поддержки;
• исследование, создание и использование типовых метамоделей систем деятельности,
основанных на программировании.
4 Разработка и совершенствование нотаций (языков) для моделирования бизнес-процессов – настолько
актуальная тема, что является предметом не только широкомасштабной коллективной, но и осуществляемой
в инициативном порядке индивидуальной деятельности [17].
ISSN 1028-9763. Математичні машини і системи, 2010, № 1 153
Данная статья является первой из запланированного автором небольшого цикла статей,
цель которого – исследование каждого из выделенных направлений отдельно и в их взаимосвязи, и
посвящена рассмотрению первого из них – терминологии.
2. «Моделирование деятельности» vs5 «Моделирование бизнес-процессов»
Одной из необходимых составляющих процесса развития какого бы то ни было научного
направления является формирование и совершенствование соответствующего понятийно-
терминологического аппарата. Язык развивается с развитием представлений человека об
объектах, явлениях, деятельности и т.д. Как тут не вспомнить известный пример со снегом. Для
жителя «цивилизованной» страны снег – он и есть снег, ну, может быть, снабжаемый иногда каким-
нибудь прилагательным типа «мягкий», «пушистый», «липкий» и т.д. Для обитателя же Крайнего
Севера, для которого снег – существенный фактор его существования, он имеет десятки
наименований.
Но известен и феномен «местничества», когда автор, в основном, по незнанию, пытается
взамен устоявшихся понятий и терминов использовать свои, нетрадиционные. Разумеется, это
явление отрицательное. Но отрицательное не абсолютно. Что делать специалисту, который там,
где другие не видят проблем, все-таки смог увидеть что-то новое, плохо выразимое или вовсе не
выразимое на принятом профессиональном (научном) диалекте?
Выше (во введении к статье) мы попеременно, практически как синонимы, использовали
понятия «моделирование деятельности» и «моделирование бизнес-процессов». Попытаемся
разграничить их для целей дальнейшего изложения, для чего обратим внимание на
основополагающее понятие «бизнес-процесс». Не претендуя на полноту обзора, тем не менее,
отметим, что авторы многочисленных публикаций, спецификаций и т.д. как бы избегают
определения этого понятия, используя его как некоторую данность. Там же, где можно было бы
ожидать определения, приходится сталкиваться с довольно странными конструкциями. Например,
в глоссарии, сопровождающем спецификацию нотации BPMN, статья «Business Process» гласит: «A
Business Process is displayed within a Business Process Diagram (BPD). A Business Process contains
one or more Processes» [5].
Пожалуй, единственным, заслуживающим внимания, является определение из Википедии:
«A business process or business method is a collection of related, structured activities or tasks that
produce a specific service or product (serve a particular goal) for a particular customer or customers. It
often can be visualized with a flowchart as a sequence of activities» [18].
Однако какую нагрузку несет слово «бизнес» в словосочетании «бизнес-процесс»? Вряд ли
можно было бы согласиться с утверждением, что объектом моделирования может быть только
«деловая» деятельность. Насколько мне известно, никто этого и не утверждает. Но, может быть,
любая деятельность является «деловой»? Вряд ли… Если исходить из того, что любая
деятельность может стать объектом моделирования, вплоть до процессов, протекающих в неживой
природе [19], решительный отказ от слова «бизнес» представляется вполне обоснованным.
5 vs – общепринятое сокращение от англ. «versus» (против). Мы используем здесь «vs», учитывая
происхождение термина «business-processes modeling».
ISSN 1028-9763. Математичні машини і системи, 2010, № 1 154
Остается термин «процесс». В таком авторитетном источнике, как [20], он определяется
следующим образом: «Set of interrelated or interacting activities which transforms inputs into outputs»6.
В стандарте [7] также можно увидеть такую трактовку: «An activity or set of activities using
resources, and managed in order to enable the transformation of inputs into outputs, can be considered as
a process»7. Нетрудно заметить, что перевод этих формулировок на русский язык был сопряжен с
некоторым трудностями, обусловленными присутствием слова «activity». В словаре [21] можно
найти такие варианты перевода: активность; проявление работы каких-либо органов, сил природы;
работа; действие; деятельность; функция; процесс; операция; вид деятельности; оживление
(спроса, рынка); мероприятия; организация; учреждение; интенсивность действия;
жизнедеятельность; вещество, обладающее какой-либо активностью; функционирование;
действенность. Для множественного числа (activities): деятельность; мероприятие, мероприятия в
какой-либо области; меры; виды деятельности. Как видим, профессиональные переводчики из всех
возможных вариантов, большинство из которых явно не подходит в данном случае8, выбрали
«деятельность» и «вид деятельности», т.е. «процесс» определяется через «деятельность».
Целесообразно поинтересоваться, как толкуют слово «процесс» русскоязычные источники.
Словарь Даля [22] отсылает нас к слову «процедура» (шествие, ход; | всякое длительное,
последовательное дело, порядок, обряд. Процессия – торжественный ход, шествие. Процесс –
тяжба, судебный ход дела.). Очевидно, что на это определение в нашем случае вряд ли можно
опереться. А вот в словаре Ожегова [23] мы находим то, что нам нужно и что отвечает нашим
интуитивным представлениям: «Ход, развитие какого-нибудь явления, последовательная смена
состояний в развитии чего-нибудь». Именно представление о процессе как о реальном объекте,
существующем и изменяющемся в пространстве-времени, должно, на наш взгляд, приниматься за
основу нашего отношения к термину «процесс». Сопоставляя понятия «процесс» и «деятельность»,
можно констатировать, что процесс – уникальная реальная сущность, деятельность же – это некая
абстракция.. Отсюда следует, что пытаться определить процесс через деятельность, равно как и
наоборот, – значит совершать методологическую ошибку, чреватую нежелательными
последствиями. О «взаимоотношениях» процесса и деятельности мы можем сказать, что в
реальном мире можно различать, инициировать, наблюдать, описывать, имитировать и т.д.
некоторые процессы, которые по каким-либо причинам могут рассматриваться только как процессы
осуществления некоторой деятельности.
Можно констатировать, что в сложившейся англоязычной традиции термин «process»
используется для обозначения деятельности (абстракция). Переход от абстракции к реальности
осуществляется с помощью термина «instance» (пример, случай). Попав однажды в ловушку
«кальки» с английского, «instance» пришлось бы назвать, например, «экземпляром процесса», но
достигаемая при этом формальная корректность оборачивается некорректностью онтологической –
процесс как уникальный объект не может иметь экземпляров.
6 Совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующая входы в выходы
[24].
7 Деятельность, использующая ресурсы и управляемая с целью преобразования входов в выходы, может
рассматриваться как процесс [25].
8 Например, вряд ли было бы корректным определить «процесс» через «процесс».
ISSN 1028-9763. Математичні машини і системи, 2010, № 1 155
Сделав одно исключение9, мы приостанавливаем критику расхожих терминов и переходим к
сопоставлению объемов понятий деятельности (действий) и процессов. В основе изображенной на
рис. 1 структуры находятся реальные объекты (РО), характеризующиеся местоположением,
объемом и временем существования. Отдельные РО, с точки зрения некоторого субъекта, могут
рассматриваться как носители информации, т.е., информационные объекты. Все остальное мы
получаем путем абстрагирования, совершая переходы от одного уровня абстракции к другому.
РО могут относиться к тем или иным типам РО. Типы РО суть элементы некоторой системы
типов. Мы различаем два фундаментальных типа РО: псевдо-неизменные («константные») РО и
процессы.
Для рассмотрения деятельности (действий) мы воспользуемся четверкой
фундаментальных понятий/терминов: событие, операция, операнд, преобразователь (в каком
случае, что, над чем и с помощью чего делается). В нашем представлении операция – это
абстрактная «единица» деятельности. Операнды и преобразователи мыслятся как типовые РО.
Операнды могут быть постоянными, переменными, внешними, внутренними, входными,
выходными, вспомогательными и т.д.
Действия (операции) могут типизироваться. Типы действий (операций) образуют некоторую
систему типов.
РО могут описываться. Для описания может использоваться план (метамодель). Описание
(модель) РО зависит от избранной метамодели и собственно объекта.
Сверху мы ограничились типами действий. Но наши построения можно было бы
продолжить. Так, в рассмотрение можно ввести виды деятельности. Вид деятельности не сводится
к операции, процесс его осуществления квази-бесконечен и включает в себя процессы выполнения
различного рода операций. Виды деятельности, в свою очередь, также можно типизировать.
3. Модели и метамодели процессов
Модель процесса – это информационный образ уникального реального объекта. Например, мы
можем пронаблюдать некий процесс и запомнить нечто о нем. Можно отснять процесс на видео.
Если нас интересует только звуковой аспект процесса, мы можем ограничиться аудиозаписью.
Какие-то процессы мы отображаем текстами на естественном или структурированном
естественном языке. Информация о процессе может быть как «случайной», т.е. зависеть от
способностей, предпочтений, настроения, целей субъекта-наблюдателя, так и «организованной»,
что предполагает заведомое (до начала наблюдаемого процесса) наличие плана его описания,
механизмов сбора нужных данных и умение наблюдателя ими пользоваться.
9 Еще одним серьезным, на наш взгляд, недостатком является крепко укоренившаяся тенденция называть
одно и то же разными терминами, в зависимости от некоторых не очень существенных условий. Например, в
[5] для различения уровней осуществления деятельности параллельно с термином «процесс» используется
термин «подпроцесс» («subprocess»). Процесс может рассматриваться как совокупность подпроцессов.
Подпроцессы могут в свою очередь иметь подпроцессы. Но тут же вводится и термин «задача» («task») –
процесс, не имеющий подпроцессов. Нам такая практика поиска «оригинальных» наименований для
различных уровней осуществления деятельности представляется необоснованной, малопродуктивной и
чреватой всевозможными недоразумениями.
ISSN 1028-9763. Математичні машини і системи, 2010, № 1 156
Рис. 1. От реальных объектов к деятельности
В общем случае в описании процесса должны различаться:
• план (описание того, как предполагается процесс осуществить);
• факт (отображение реального хода процесса).
Не лишним будет заметить, что важность формирования, сохранения и использования
информационных образов процессов отображена в стандартах ISO серии 9000 на концептуальном
уровне в виде требования вести т.н. «записи» (англ. «records»).
Номенклатура отбираемых для модели характеристик процесса определяет метамодель
процесса.
4. Абстрактные и реальные операции
Будем различать абстрактные и реальные операции. В качестве примера рассмотрим
арифметическую операцию «Перемножение целых положительных чисел» ( )NNNM →×: . Это
– абстрактная операция, которая описывает лишь принципиальную сторону вопроса (функция с
бесконечными областями определения и значения).
Если же мы имеем в виду реальную операцию умножения, то должны конкретизировать ее
описание; при этом могут быть получены разные варианты (табл. 1).
В зависимости от типов операндов – материальный объект (М), носитель информации (И) –
и типов преобразователей – человек (Ч), механизм (М), компьютер (К), робот (Р) – можно различать
некоторые типы реальных операций (табл. 2).
ISSN 1028-9763. Математичні машини і системи, 2010, № 1 157
Таблица 1. Примеры реальных операций умножения
Вариант реализации
№ Аспект
1 2 3 4
1 Области
определения и
значения
Например,
до 106
Условно не
ограничена
Например, 107 Ограничена
потребностью
2 Вход(ы) «С голоса» «С голоса» «С голоса» Компьютерное
представление
3 Выход «С голоса» «С голоса» «С голоса» Компьютерное
представление
4 Преобразователи Человек Человек Человек +
калькулятор
Компьютер
5 Вспомогательные
объекты -
Бумага,
карандаш
Электроэнергия Электроэнергия
6 Способ выполнения «В столбик»10
7 Длительность
выполнения
Например,
секунды,
минуты
Мин. и более
(функция от
входов)
Основное время
занимает ввод
данных
Например,
микросекунды
8 Вероятность
получения
правильного
результата
100 %
< 100 %
(функция от
входов)
< 100 %
(возможны
ошибки ввода)
100 %
Примечание: большинство ячеек таблицы, касающихся способа выполнения операции,
остались не заполненными (по разным причинам).
Таблица 2. Типизация реальных операций в зависимости от преобразователей
Операнды
№
Вход(ы) Выход(ы)
Преобразо-
ватель(и)
Условное
наименование
1 М М Ч Ручная
2 М М Ч+М Механизированная
3 М М М Механическая
4 М М Р Роботизированная
5 М И Ч ?11
6 И И Ч Умственная
7 И И Ч+К Автоматизированная
8 И И К Автоматическая
новые и новые названия для различных уровней декомпозиции деятельности, а договориться о
том, что операция декомпозируется на операции, вспомогательные для нее, которые оперируют с
исходными или вспомогательными операндами.
Вспомогательная операция также, при необходимости, может быть декомпозирована на
какие-то другие операции и т.д.
В зависимости от типов декомпозируемых операций и типов вспомогательных операций
можно различать некоторые типы реальных декомпозируемых операций (табл. 3).
10 Заметим, что умножение «в столбик» – это не всеобщий и не единственный «ручной» метод; в некоторых
странах, например, в Китае, используется весьма своеобразный графический метод [26].
11 Автор затрудняется предложить подходящее название. Как, например, назвать операцию пересчитывания
материальных объектов?
5. Операционная деком-
позиция деятельности
Используя термин «операция»
для обозначения условной
единицы деятельности и
сопутствующий ему термин и
«операнд», мы получаем
возможность не искать все
ISSN 1028-9763. Математичні машини і системи, 2010, № 1 158
Таблица 3. Типы реальных декомпозируемых операций
Операнды
№
В
х
о
д
(ы
)
В
ы
х
о
д
(ы
)
Т
и
п
д
е
ко
м
-
п
о
зи
р
у
е
-
м
о
й
о
п
е
р
а
ц
и
и
Т
и
п
(ы
)
в
с
п
о
м
о
га
-
те
л
ь
н
ы
х
о
п
е
р
а
ц
и
й
Комментарий
1 И, М М К Ч, Ч+М,
Ч+Р
Компьютер сообщает человеку, что нужно сделать, где
находятся входы и куда нужно поместить результат
2 И, М М К Р Компьютер сообщает роботу, что нужно сделать, где
находятся входы и куда нужно поместить результат
3 И И К К Компьютер ставит задачу (задает вопрос) компьютеру
4 И И К Ч Компьютер ставит задачу (задает вопрос) человеку
5 И И Ч К Человек в рамках выполнения основной операции
пользуется компьютером для решения частных задач
Одним из важных аспектов управляемого осуществления деятельности является ее
протоколирование – формирование ее информационного «следа» (описание процесса). Однако,
если декомпозиция исходной операции дала многоуровневое дерево операций, можно
предположить, что по мере продвижения по уровням декомпозиции значимость операций и
описаний процессов их выполнения постепенно уменьшается и, начиная с некоторого уровня,
необходимость/целесообразность протоколирования отпадает. В связи с этим введем понятие
«опорной» операции (тип “О”), процесс выполнения которой нуждается в протоколировании. Для
опорной операции должны быть определены метамодель и механизмы формирования моделей
процессов выполнения. Опорную операцию, способ выполнения которой выражается в терминах
также опорных операций, будем называть опорно-детализируемой операцией (тип “ОД”).
6. Способ выполнения операции
Очевидно, что способ выполнения является ключевым аспектом описания многих операций. Для
некоторых операций, совершаемых людьми, например, творческих, получение такого описания –
практически не выполнимая задача. Однако для многих видов человеческой деятельности
получение таких описаний, фиксирующих «лучшую практику», является не только возможным, но и
необходимым. Конечно, здесь речь не идет о поощрении стагнации в том или ином виде
деятельности из-за навязывания способов, показавших себя когда-то лучшими, но устаревшими к
определенному моменту с появлением новых. Нам важно понимать, что качество способа прямо
зависит от степени определенности, однозначности его описания.
Очевидно, что описанию способа выполнения операции может быть присуща различная
степень определенности. В табл. 4 мы попытались охарактеризовать эти степени определенности
путем перебора сочетаний присутствия в описании отдельных «опций», основанных на идее
декомпозиции.
В привязке к пронумерованным от 1 до 9 колонкам «присутствия опций» дадим
необходимый комментарий:
1 – какое бы то ни было описание отсутствует. Как выполнять операцию, решает
исполнитель в каждом конкретном случае;
ISSN 1028-9763. Математичні машини і системи, 2010, № 1 159
2 – имеется описание (скажем, в текстовом виде), но из него практически невозможно
«извлечь» представление о вспомогательных операндах и/или операциях;
3 – имеется нечеткое описание, но по нему можно идентифицировать некоторые
вспомогательные операнды;
4 – имеется нечеткое описание, но по нему можно идентифицировать некоторые
вспомогательные операции;
5 – имеется нечеткое описание, но по нему можно идентифицировать некоторые
вспомогательные операнды и операции;
6 – исполнителю предлагаются вспомогательные операнды и операции. Как использовать
эту информацию, он решает сам;
7 – все операции выстроены в строгую линейную последовательность12;
8 – имеются операции, порождающие альтернативные или параллельные ветви, состоящие
из линейно упорядоченных операций;
9 – имеются операции, дающие возможность «прервать» линейный порядок и
«перескочить» на определенную операцию.
Таблица 4. Степени определенности способа выполнения операции
Присутствие опции в описании способа
Опция
1 2 3 4 5 6 7 8 9
Описание отсутствует +
Имеется простое вербальное
описание
+ + + +
Идентифицированы
операнды
13
+ + + + + +
Идентифицированы
операции
14
+ + + + + +
Операции линейно
упорядочены
+ + +
Порождаются альтернативы
и параллелизмы
+ +
Порождаются циклы +
Итак, перед нами целый спектр степеней определенности описания способа, в котором
«затененный» участок (колонки 7–9) можно назвать программами деятельности15, или просто
программами.
Программа – описание способа осуществления определенного вида деятельности,
связанной с преобразованием реальных объектов определенного типа, выполненное в терминах
типовых вспомогательных объектов и операций, каждая из которых рассчитана на использование
определенных типовых объектов в качестве преобразователей входа в выход.
12 Для простоты мы пропускаем случай, когда операции лишь частично упорядочены.
13 Имеются в виду вспомогательные операнды.
14 Имеются в виду вспомогательные операции.
15 В данном случае можно применить к программам понятие «мерности». Так, простую последовательность
операторов (вариант 7) можно рассматривать как 1-мерную программу. Поскольку альтернативные и
параллельные цепочки (вариант 8) «не умещаются» на одной линии, такие описания можно рассматривать как
2-мерные программы. «Скачки» вперед, назад, в сторону (вариант 9) возможны лишь через 3-е измерение.
ISSN 1028-9763. Математичні машини і системи, 2010, № 1 160
Ясно, что такое описание может быть осуществлено лишь в определенном контексте,
составляющими которого могут быть: типизация объектов реального мира и операций,
осуществляемых над ними, соглашения по организации порядка выполнения операций, правила
идентификации экземпляров объектов определенного типа и т.д.
При этом компьютерные программы – это особый вид программ, описывающих способы
преобразования информационных объектов с помощью компьютеров.
Таким образом, мы расширяем понятие «программа», фактически отталкиваясь от понятия
«компьютерная программа» и допуская присутствие в ней операций, операндами для которых
служат не только информационные объекты, а преобразователями – не только компьютеры. В
результате мы жертвуем таким свойством компьютерных программ, как однозначность результата
[27], но получаем возможность описывать целые технологии для многих областей человеческой
деятельности [28].
Опорно-детализируемой операции (тип “ОД”), имеющей программу, которая устанавливает
порядок выполнения вспомогательных опорных операций, присвоим тип “ОДП”. Следует обратить
внимание на то, что если такая программа отсутствует, то ее все равно нужно будет начать строить
(до начала выполнения операции) из имеющихся «кирпичиков» – вспомогательных опорных
операций, а в процессе выполнения, возможно, еще и «достраивать».
7. Модели и метамодели операций
Описание реальной операции можно назвать ее моделью. Модель операции может включать
описания входов/выходов, вспомогательных операндов, преобразователей, способы выполнения
(вспомогательные операции, программа), метамодель процессов выполнения операции и описание
способов получения описаний процессов (моделей), критерии оценки процессов и т.д. Выбор
номенклатуры компонентов модели операции в каждом конкретном случае обусловлен
практическими потребностями и определяет метамодель операции.
8. Выводы
Подытожим все вышесказанное:
1. Программирование деятельности является одним из самых востребованных на практике
направлений моделирования деятельности. При этом слово «программирование» отражает саму
суть данного вида моделирования, в отличие от «моделирования бизнес-процессов» – модного, но,
как оказывается, малосодержательного и внутренне противоречивого понятия.
2. Последовательно осуществляемое программирование деятельности в конкретной
предметной области должно приводить к ситуации, когда человеку отводится выполнение лишь тех
действий, которые не способен выполнить компьютер (принятие нестандартных решений,
творчество и т.д.). При этом в идеале полностью исключается навязывание человеку выполнения
каких-либо программ.
3. Программирование деятельности должно быть поддержано средствами создания и
использования программ деятельности. Вооруженный идеей и средствами программирования
деятельности моделер (фактически, профессиональный программист) работает не в терминах
ISSN 1028-9763. Математичні машини і системи, 2010, № 1 161
каких-то «процессов», а в привычных ему терминах «операнд» и «операция», которые в программу
деятельности вписываются с помощью привычных ему «операторов». От программирования
отстраняется дилетант, смутно представляющий себе идею «моделирования бизнес-процессов» и
осуществляющий свободный дрейф в открытом море доступных нотаций.
СПИСОК ЛИТЕРАТУРЫ
1. Integrated Definition Methods. – Режим доступу: http://www.idef.com.
2. OMG Unified Modeling Language (OMG UML) V 2.2 (Infrastructure & Superstructure). – Режим доступу:
http://www.omg.org.
3. Event-Driven Process Chain. – Режим доступу:
http://www.google.com.ua/search?hl=uk&q=event-driven+process+chain&meta=&aq=f&oq.
4. Репин В. В. Сравнительный анализ нотаций ARIS eEPC /IDEF0, IDEF3/ – Режим доступа:
http://idefinfo.ru/content/view/43/25/.
5. Business Process Modeling Notation (BPMN). Version 1.2 OMG Document Number: formal/2009-01-03 Standard
document URL: http://www.omg.org/spec/BPMN/1.2.
6. ISO 9001:2000. Quality management systems – Requirements.
7. ISO 9001:2008. Quality management systems – Requirements.
8. Малышев О.В. Реконструкция мета-модели процесса по стандартам ISO серии 9000:2000 / О.В. Малышев //
Методы менеджмента качества. – 2004. – № 9. – С. 17 – 20.
9. Малышев О.В. Моделирование процессного подхода в проекте СМК / О.В. Малышев // Корпоративные
системы. – 2004. – № 6. – С. 10 – 16.
10. Function Modeling Method IDEF0. – Режим доступу: http://www.idef.com/idef0.html.
11. Маклаков С.В. Моделирование бизнес-процессов с AllFusion Process Modeler (BPwin 4.1) / С.В. Маклаков. –
М.: ДИАЛОГ-МИФИ, 2003. – 240 с.
12. Process Description Capture Method IDEF3. – Режим доступу: http://www.idef.com/IDEF3.html.
13. Репин В.В. Процессный подход к управлению. Моделирование бизнес-процессов (серия «Практический
менеджмент») / В.В. Репин, В.Г. Елиферов. – М.: РИА «Стандарты и качество», 2004. – 408 с.
14. Organization for the Advancement of Structured Information Standards. – Режим доступу: http://www.oasis-
open.org/who/.
15. Фуксман А.Л. Технологические аспекты создания программных систем / А.Л. Фуксман. – М.: Статистика,
1979. – 184 с.
16. Web Services Business Process Execution Language Version 2.0. OASIS Standard. 11 April 2007. – Режим
доступу: http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf.
17. Тупкало В.М. Мова моделювання бізнес-процесів ММТ / В.М. Тупкало // Всеукраїнський науково-практичний
журнал «Світ якості України». – 2005. – № 6–7(10–11). – Режим доступу:
http://tupkalo.com.ua/jazik_modelirovanija_biznes-processov_jamt_ua.html.
18. Business process (From Wikipedia, the free encyclopedia). – Режим доступу:
http://en.wikipedia.org/wiki/Business_process.
19. Малышев О.В. Моделирование деятельности организации: от онтологии к технологии / О.В. Малышев //
Математичні машини і системи. – 2005. – № 1. – С. 68 – 78.
20. ISO 9000:2005. Quality management systems – Fundamentals and vocabulary.
21. Электронный словарь ABBYY Lingvo. – www.Lingvo.ru.
22. Словарь Даля (процесс). – Режим доступа: http://lib.deport.ru/slovar/dal/p/protsess.html.
23. Словарь Ожегова (процесс). – Режим доступа: http://lib.deport.ru/slovar/ojegov/p/protsess.html.
24. ISO 9000:2005. Системы менеджмента качества – Основные положения и словарь.
25. ISO 9001:2000. Системы менеджмента качества – Требования.
26. Графический способ умножения чисел. – Режим доступа: http://ru.youtube.com/watch?v=zfpx3Z7idks.
27. Котов В.Е. Введение в теорию схем программ / В.Е. Котов. – Новосибирск: Наука, Сибирское отделение,
1978. – 258 с.
28. Малышев О.В. Типовая Р-технология программирования. Основные проектные решения / О.В. Малышев,
И.Е. Щетинин // УСиМ. – 1989. – № 3. – С. 40 – 44.
Стаття надійшла до редакції 02.08.2009
|