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

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

– Complete Instruction Set Computer (CISC-архитектура, компьютер на микропроцессоре с полным набором команд)

– Reduced Instruction Set Computer (RISC-архитектура, компьютер с сокращенным набором команд)

	CISC	RISC
Основоположник, модель	IBM, IBM/360	CDC6600 (Крэй)
Лидер, сегодня	x86	Alpha, PowerPC, SPARC
Рынок	Персональные ЭВМ (благодаря совместимости с программным обеспечением младших моделей, общая стоимость которого - в начале 90-х годов - составила несколько миллиардов долларов США)	Высокопроизводительные компьютеры (стоимость ПО не настолько существенна)
Реализация	Микропрограммная (интерпретация)	Аппаратная
Число регистров общего назначения	небольшое	большое
Формат команд	большое количество форматов команд различной разрядности	команды фиксированной длины и фиксированного формата
Адресация	большое количество методов адресации, преобладание двухадресного формата команд	простые методы адресации, трехадресный формат команд

Основоположник, модель

Организация первых моделей процессоров - i8086/8088 - была направлена, в частности, на сокращение объёма программ, критичного для систем того времени, отличавшихся малой оперативной памятью. Расширение спектра операций, реализуемых системой команд, позволило уменьшить размер программ, а также трудоёмкость их написания и отладки. Однако увеличение числа команд повысило трудоёмкость разработки их топологических и микропрограммных реализаций. Последнее проявилось в удлинении сроков разработки CISC-процессоров, а также в проявлении различных ошибок в их работе.

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

Лидер, сегодня

Процессоры Intel, начиная с 486-го, содержат ядро RISC, которое выполняет самые простые (и обычно самые распространенные) команды за один цикл тракта данных, а по обычной технологии CISC интерпретируются более сложные команды. В результате обычные команды выполняются быстро, а более сложные и редкие - медленно. Хотя при таком «гибридном» подходе работа происходит не так быстро, как у RISC, данная архитектура имеет ряд преимуществ, поскольку позволяет использовать старое программное обеспечение без изменений.

Первая модель процессора Intel, которая вплотную приблизилась к архитектуре RISC – PentiumPRO (Precision RISC Organization - Полноценная RISC-архитектура).

Реализация

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

Число регистров

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

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

Формат команд

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

Адресация

Простые методы адресации позволяют резко упростить декодирование команд. Организация регистровой структуры – основное достоинство и основная проблема RISC. Практически любая реализация RISC-архитектуры использует трехместные операции обработки, в которых результат и два операнда имеют самостоятельную адресацию – R1:= R2, R3. Это позволяет без существенных затрат времени выбрать операнды из адресуемых оперативных регистров и записать в регистр результат операции. Кроме того, трехместные операции дают компилятору большую гибкость по сравнению с типовыми двухместными операциями формата «регистр – память» архитектуры CISC. В сочетании с быстродействующей арифметикой RISC-операции типа «регистр – регистр» становятся очень мощным средством повышения производительности процессора.

Предыдущие части:

Создание архитектуры RISC

Как уже неоднократно упоминалось, все х86-процессоры, решения компании Motorola и подавляющее большинство выпущенных в 1980-е годы кристаллов имели архитектуру CISC (Complex Instruction Set Computing). Совокупность всех особенностей привела к тому, что чипы стали не только сложными и дорогими в производстве, но и достигли своего потолка производительности. Для дальнейшего увеличения быстродействия требовалось наращивать количество транзисторов, однако освоенные технологические нормы не позволяли создавать более сложные решения. С этим столкнулась Intel при выпуске семейства i486. Для поднятия производительности они внесли изменения в архитектуру процессоров, добавив кэш-память, множители и конвейеры. Словом, 486-е «камни» получили некоторые «фишки» архитектуры RISC. Тем не менее к созданию RISC-платформы американская компания никакого отношения не имеет. Своим созданием архитектура обязана американскому инженеру Дэвиду Паттерсону, который руководил проектом Berkeley RISC с 1980 по 1984 годы.

Дэвид Паттерсон - отец RISC

Первоначальной идеей, которая затем воплотилась в столь масштабный проект Berkeley RISC, стало исследование работы Motorola 68000. В ходе наблюдений выяснилось, что программы попросту не использовали подавляющее большинство инструкций, заложенных в процессор. Например, система Unix при компиляции использовала лишь 30% команд. Поэтому в рамках проекта Berkeley RISC планировалось создать такой процессор, который бы содержал лишь самые необходимые инструкции.

После нескольких лет исследований и разработки было выпущено несколько образцов процессоров, название которых и дало имя всей архитектуры. Сама аббревиатура RISC расшифровывается как Restricted (Reduced) Instruction Set Computer, что переводится как «компьютер с сокращенным набором команд». «Сокращенный набор команд» вовсе не означает, что количество инструкций меньше, чем число команд CISC-кристаллов. Разница состоит в том, что любая инструкция платформы RISC является простой и выполняется за один такт (по крайней мере, должна выполняться), тогда как на выполнение RISC-инструкции могло уходить несколько десятков тактов. При этом длина команды является фиксированной. Например, 32 бита. Также у RISC имеется гораздо больше регистров общего назначения. Плюс для этой архитектуры характерна конвейеризация. Именно ее использование (вкупе с упрощенными командами) позволяет эффективно наращивать тактовую частоту процессоров RISC.

Команда проекта Berkeley RISC

Дебютными решениями стали RISC I и RISC II - детища Паттерсона и проекта Berkeley RISC. Первый содержал более чем 44 000 транзисторов и работал на частоте 4 МГц. Такой процессор при выполнении небольших программ был в среднем в два раза быстрее VAX 11/780 и примерно в четыре раза производительнее, чем «камень» Zilog Z8000. RISC II отличался от предшественника большим количеством инструкций: 39 против 32. Он был более быстрым. Его преимущество над процессором VAX достигало 200%, а Motorola 68000 в некоторых программах был медленнее примерно в четыре раза.

Нужно отметить, что Berkeley RISC был частью большого проекта под названием VLSI. Сюда также входил проект Стэнфордского университета MIPS, который стартовал в 1981 году.

Процессоры MIPS

Главой проекта MIPS был ученый Стэнфордского университета Джон Хэннесси. Как и в случае с Berkeley RISC, задачей стартапа было исследование и создание такого процессора, который использовал бы конвейер и сокращенный набор команд. Архитектура MIPS-решений также предусматривала наличие вспомогательных блоков в составе кристалла: например, модулей для работы с памятью, целочисленного АЛУ (арифметико-логическое устройство) и декодеров команд. Отличием плана MIPS от Berkeley RISC было использование удлиненного конвейера. Архитектура RISC, в принципе, предполагает использование конвейера, но Хэннесси пошел дальше и предложил максимально удлинить конвейер в процессоре, то бишь еще больше «раздробить» выполнение одной операции. Такой подход открывал еще большие просторы по наращиванию тактовой частоты. При этом удлинение конвейера обеспечивало более эффективное распараллеливание выполнения команд. В то время распараллеливание являлось отличительной чертой RISC-архитектуры, поскольку ни в одном CISC-процессоре эта функция не была реализована вплоть до появления в них конвейеров. Например, в MIPS, так же как и в RISC, выполнение одной команды могло быть еще не завершено, когда начиналась выполняться другая. В процессорах CISC для старта выполнения одной инструкции было необходимо, чтобы была окончена обработка другой.

Джон Хэннесси - создатель архитектуры MIPS, а ныне президент Стэнфордского университета

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

В 1984 году Хэннесси покинул Стэнфордский университет и основал компанию MIPS Computer Systems, которая и занялась выпуском процессоров с одноименной архитектурой. Спустя год увидел свет первый продукт компании - 32-битный «камень» R2000. Он стал первой коммерчески доступной RISC-моделью в истории. В 1988 году появился процессор следующего поколения под названием R3000. В сравнении с R2000 он получил поддержку многопроцессорности и кэш-памяти инструкций и данных. «Трехтысячный» оказался коммерчески успешным. Процессор использовался в серверных системах и рабочих станциях таких компаний, как Silicon Graphics, DEC, Seiko Epson и многих других. Плюс R3000 стал сердцем игровой консоли Sony PlayStation.

Процессор MIPS R3000

На разработку следующего поколения MIPS-процессоров ушло три года. Процессор R4000 был представлен в 1991 году. Он получил 64-битную архитектуру, встроенный сопроцессор и работал на более высокой тактовой частоте, нежели предшественники. Так, минимальная частота R4000 составляла 100 МГц. Объем кэш-памяти инструкций и данных составлял 8 Кбайт каждый. Спустя два года была представлена доработанная версия процессора с индексом R4400. Новый кристалл обладал увеличенным вдвое кэшем и поддерживал кэш-память второго уровня большего объема. Помимо этого, были исправлены многочисленные ошибки при работе в 64-разрядном режиме.

Удивительно, что, несмотря на коммерческий успех своих процессоров, MIPS испытывала финансовые трудности и в конечном счете была куплена компанией SGI и переименована в MIPS Technologies. Следом начались выдаваться лицензии на производство клонов сторонним компаниям. Так, компания QED (Quantum Effects Devices) создала недорогие MIPS-процессоры, которые использовались в маршрутизаторах Cisco. А NEC занималась производством «камня» VR4300, который «прописался» в игровой консоли Nintendo 64.

Процессор NEC VR4300 использовался в приставке Nintendo 64

В 1994 году появился процессор R8000. Он стал первым MIPS-решением с суперскалярной архитектурой, которая подразумевает параллельное выполнение команд при условии, что исполнение одной команды не зависит от результата другой. Например, R8000 умел обрабатывать до четырех инструкций за такт.

В январе 1996 года MIPS представила процессор следующего поколения под названием R10000. «Десятитысячный» использовал такую же суперскалярную архитектуру, как и R8000, и, по сути, являлся доработанной версией предшественника. Также процессор имел кэш-память инструкций и данных объемом 32 Кбайт каждая и работал на частоте 175 МГц или 195 МГц. В 1997 году даже появилась версия чипа с частотой 250 МГц. Но даже при параметре 195 МГц R10000 был одним из быстрейших процессоров того времени.

Процессор R10000, произведенный компанией Toshiba

К сожалению, после запуска R10000 компания SGI забросила MIPS-архитектуру. Все последующие кристаллы основывались на ядре «десятитысячного» и не имели в сравнении с ним каких-то принципиальных отличий. Например, процессор R12000, представленный в 1998 году, получил дополнительную стадию в конвейер и улучшенную работу с очередями инструкций. Его тактовая частота составляла 270 МГц, 300 МГц или 360 МГц. После R12000 вышли еще два поколения процессоров MIPS: R14000 и R16000. Они получили поддержку более быстрых системных шин, увеличенные частоты и кэш-память большего объема. Например, R16000 мог работать на частоте 700 МГц и поддерживал 64 Кбайт кэш-памяти инструкций и данных.

После этого MIPS занялась продажей лицензий на 32-битную и 64-битную архитектуры MIPS32 и MIPS64.

Процессоры SPARC

Компания Sun Microsystems также решилась на разработку архитектуры - SPARC (Scalable Processor ARChitecture). Так, инженеры черпали вдохновение из проекта Berkeley RISC. А сам Дэвид Паттерсон даже привлекался к проекту в качестве консультанта. Тем не менее в результате SPARC больше напоминала MIPS-архитектуру. Например, в наборе команд платформы также отсутствовали инструкции умножения и деления. Особенностью архитектуры SPARC стало использование регистрового окна, с помощью которого был немного изменен процесс вызова функций в программах. Обычно при вызове программ процессор запоминал свое состояние (то есть запоминал состояние некоторых регистров общего и специального назначения), переходил к выполнению функции, а затем возвращался в свое исходное состояние до вызова функции. А в процессорах SPARC при вызове функции необходимые данные записывались в конец регистрового окна, а само регистровое окно перемещалось по файлу так, чтобы данные оказывались в начале окна. Такой подход в теории обеспечивал более высокую скорость работы.

Процессор SPARC V7, изготовленный компанией Fujitsu

Первая версия архитектуры получила название SPARC V7. Одноименный процессор на ее базе производился вплоть до 1992 года. Затем появилась следующая генерация архитектуры - SPARC V8. Она не претерпела каких-либо кардинальных изменений. Ключевыми отличиями стало добавление операций умножения и деления, а также улучшенное выполнение арифметики чисел с плавающей запятой. Как и SPARC V7, SPARC V8 оставалась 32-битной архитектурой, на базе которой был создан процессор microSPARC. Он принадлежал к Low-End-сегменту и использовался в небольших рабочих станциях и встраиваемых системах. Силами компаний Texas Instruments и Fujitsu также были выпущены улучшенные клоны. Более производительным решением стал процессор SuperSPARC.

Созданием следующего поколения архитектуры с именем SPARC V9 работала уже целая организация SPARC Architecture Committee, в состав которой, кроме самой Sun, входили такие компании, как Texas Instruments, Fujitsu, Philips и многие другие. Платформа была расширена до 64 бит и являлась суперскалярной с 9-стадийным конвейером. SPARC V9 предусматривала использование кэш-памяти первого уровня, разделенного на инструкции и данные объемом 16 Кбайт каждая, а также второго уровня емкостью 512-4096 Кбайт. Реализацией архитектуры стал процессор UltraSPARC с частотой 143-200 МГц.

Процессор UltraSPARC II

UltraSPARC не был единственным процессором с архитектурой SPARC V9. В 1997 году был представлен UltraSPARC II.

Процессоры ARM

История ныне популярных ARM-процессоров, а точнее самой архитектуры ARM, начинается с компании Acorn Computers и ее компьютера BBC Micro. В нем использовался «камень» MOS Technology 6502, однако его производительности было недостаточно, чтобы создать десктоп следующего поколения. По различным причинам другие доступные процессоры также не подходили под требования Acorn, поэтому в компании задумались о создании собственного чипа. После изучения различных архитектур, инженеры Acorn взяли за основу процессоры RISC и все тот же кристалл MOS Technology 6502.

Компьютер BBC Micro

У процессора MOS, например, была позаимствована архитектура доступа к памяти и набор инструкций. Каждая инструкция была дополнена специальным четырехбитным кодом условия. В зависимости от значения кода (true или false) инструкция могла выполняться или не выполняться. Это позволило сократить количество переходов при выполнение операций, которые негативно влияли на производительность конвейерной архитектуры. Также разработчики заложили в первоначальную ревизию архитектуры команды, которые выполняли несколько элементарных операций. Словом, немного отступили от правил RISC. Однако в конечном счете это лишь улучшило производительность процессора.

Разработка архитектуры была завершена в 1985 году созданием процессора ARM. Первые же коммерческие варианты появились в 1986 году и носили название ARM2. По сравнению с CISC-процессорами, ARM2 был очень простым - он содержал всего 30 000 транзисторов. При этом он потреблял очень мало энергии и в то же время был достаточно производительным. Несколько позже появились и ARM-процессоры, в которые были добавлены 4 Кбайт кэш-памяти, что еще больше повысило производительность кристаллов.

Процессор ARM2

К концу 1980-х годов Acorn занималась разработкой архитектуры ARM уже не в одиночку – к ней присоединилась Apple. В связи с этим подразделение, занимавшееся непосредственно ARM-процессорами, было преобразовано в отдельную компанию – Advanced RISC Machines. Первым продуктом новой компании стало процессорное ядро ARM6 и процессор ARM610, который использовался в одном из первых в мире КПК Apple Newton.

Однако ARM-процессоры уже не могли соперничать с CISC-решениями в плане производительности, а в RISC-сегменте господствовали процессоры с архитектурой MIPS. Тогда в ARM пошли иным путем. Компания начала позиционировать ARM6 как встраиваемое ядро, которое любой сторонний производитель мог использовать в своих процессорах за небольшие деньги. Такая политика принесла свои плоды, и ядро ARM стало очень популярным, а сама компания - коммерчески успешной.

Вместе с компанией DEC была разработана архитектура для более производительных ARM-решений под названием StrongARM, которое представляло собой классическую скалярную архитектуру с 5-стадийным конвейером. Архитектура имела блоки управления памятью и поддерживала кэш-память инструкций и данных объемом 16 Кбайт каждая.

Первый процессор на базе StrongARM - SA-110 - был представлен в феврале 1996 года. Он работал на тактовых частотах 100 МГц, 160 МГц или 200 МГц. «Камень» использовался в Apple MessagePad 2000, а также системах Acorn Computer Risc PC и Eidos Optima. На протяжении 1996 года SA-110 оставался самым производительным мобильным процессором.

Apple MessagePad 2000 использовал процессор SA-110

В 1997 году права на архитектуру StrongARM были проданы компании Intel, которая занялась разработкой следующего поколения платформы. В 2000 году оно было представлено, но архитектура (а точнее реализация архитектуры) носила другое название - Xscale. Платформа получила множество изменений. Например, длина конвейера была увеличена до 8 стадий. Объем кэш-памяти как для инструкций, так и для данных увеличился до 32 Кбайт. XScale использовался в таких устройствах, как RIM Blackberry, Dell Axim, мобильном телефоне Motorola A780 и других девайсах.

Процессоры PowerPC

Если быть уж совсем точным, то первой компанией, начавшей разработку RISC-архитектуры, стала IBM. Еще в 1974 году стартовала разработка процессора IBM 801, которая и заложила первые основы для этой платформы. А проект Berkeley RISC окончательно сформировал архитектуру.

В начале 80-х годов некоторые процессоры IBM для встраиваемых систем использовали архитектуру 801. Процессор на его базе также «прописался» в компьютере IBM 9370.

В 1985 году IBM начала разработку RISC-архитектуры следующего поколения. Проект получил название America Project. Разработка процессора и набора инструкций для него закончилась в 1990 году. Сам кристалл получил название POWER1 и использовался в серверах и рабочих станциях IBM. Он обладал достаточно высоким уровнем производительности, но имел многочиповую компоновку и состоял из 11 различных микросхем. В 1992 году IBM представила бюджетный вариант процессора POWER1, который умещался в одном чипе.

Процессор POWER1. Даже, скорее, чипсет

В 1993 году была представлена второе поколение архитектуры POWER2. В него было добавлено по одному дополнительному блоку арифметико-логических операций и вычислений с плавающей запятой. Также был расширен набор команд: например, была добавлена операция вычисления квадратного корня из числа на аппаратном уровне. Тактовая частота процессора варьировалась от 55 МГц до 71 МГц, а кэш-память данных и инструкций - 256 Кбайт и 32 Кбайт соответственно. Как и предшественник, новый процессор имел многочиповую компоновку. Но в мае 1994 года была выпущена и одночиповая версия.

Однако еще до выхода POWER2 IBM вместе с Apple и Motorola образовали альянс AIM и договорились о создании улучшенной архитектуры на основе POWER. В выигрыше остались все три компании, получив один из самых быстрых RISC-процессоров на рынке. Разработанная совместно архитектура получила название PowerPC. Помимо базового набора функций платформы POWER, в нее были добавлены поддержка работы в двух режимах (big-endian и little-endian), новые инструкции для вычислений с плавающей запятой и обратная совместимость с 32-битным режимом работы для 64-разрядной версии архитектуры.

Процессор PowerPC первого поколения

В отличие от других RISC-архитектур, которые занимали узкие ниши рынка, PowerPC позиционировалась как платформа-конкурент x86. Ее основным назначением являлись персональные компьютеры. Так, процессор на базе PowerPC довольно долгое время использовался в компьютерах Apple Macintosh - вплоть до 2006 года.

Архитектура конкурировала наравне с x86 до 2001 года, но после этого угнаться за процессорами Intel и AMD не смогла. Несмотря на это, процессоры на базе PowerPC использовались в игровых консолях Sony PlayStation 3 и Microsoft Xbox 360.

Консоли Sony PlayStation 3 и Microsoft Xbox 360 работают под управлением процессора PowerPC

В 90-е годы IBM успела выпустить третью генерацию процессоров под названием POWER3, которая, по сути, стала реализацией 64-разрядной архитектуры PowerPC. Чип создавался с прицелом на использование в серверах и рабочих станциях, но в итоге его главным применением стали системы IBM RS/6000.

Процессоры DEC Alpha

Архитектура DEC VAX безнадежно устаревала и в начале 90-х в компании задумались о разработке собственной RISC-платформы. Ей стала Alpha, выпущенная в 1994 году. Первым процессором стал Alpha 21064 с кодовым названием EV4. Это 64-разрядный суперскалярный кристалл с конвейерной архитектурой. То есть имел классический RISC-дизайн. Процессор DEC выгодно отличала отлаженная работа всех его блоков. Так, при равной с другими «камнями» частоте EV4 показывал более высокую производительность. Внешняя шина процессора была 128-разрядной. Он имел 16 Кбайт кэш-памяти данных и инструкций и изготавливался с помощью технологии CMOS-4. Тактовая частота EV4 составляла 150 МГц или 200 МГц. Несколько позже появилась модификация под названием 21064A, которая могла работать на скоростях вплоть до 300 МГц, что обеспечило кристаллу звание самого быстрого процессора того времени. Основным применением EV4 стали серверы и рабочие станции.

Процессор Alpha 21064

Alpha 21064A оставался топовой моделью DEC до выхода следующего поколения процессоров - 21164 (EV5). Он обладал двумя целочисленными блоками и двумя модулями вычислений с плавающей запятой. В EV5 было уже три уровня кэш-памяти: два располагались непосредственно в процессоре, а третий был внешним. Кэш-память первого уровня была разделена на две части: кэш данных и кэш инструкций объемом 8 Кбайт каждый. Объем кэш-памяти второго уровня составлял 96 Кбайт. Тактовая частота процессора варьировалась от 266 МГц до 333 МГц. Alpha 21164 перенял пальму первенства у Alpha 21064A и был быстрейшим процессором до выхода Pentium Pro. Тем не менее, ответ DEC не заставил себя долго ждать - компания выпустила более производительный процессор Alpha 21164A, работающий на более высоких тактовых частотах (до 666 МГц). Процессор использовался в рабочих станциях и серверных компьютерах таких компаний, как Digital, Network Appliance и Cray Research.

Процессор Alpha 21264

В 1996 году было представлено следующее поколение процессоров DEC - Alpha 21264 (EV6). Чип получил несколько важных изменений по сравнению с предшествующими моделями. Например, он поддерживал внеочередное исполнение инструкций, что повлекло за собой полную реорганизацию ядра. Целочисленные блоки и блоки загрузки/сохранения были объединены в единый модуль Ebox, а блоки вычислений с плавающей запятой выделены в модуль Fbox. Помимо самих блоков, эти юниты содержали еще и файлы регистров. Структура кэш-памяти опять стала двухуровневой - она пришла на смену трехуровневой организации кэша в Alpha 21164. Кэш первого уровня сохранил разделение на память для инструкций и для данных. Объем каждой части составлял 64 Кбайт. Что касается кэш-памяти второго уровня, то ее объем мог составлять от 1 Мбайт до 16 Мбайт. Плюс процессор получил поддержку предсказания ветвлений. С течением времени выпускались все новые и новые версии процессоров Alpha 21264, в которых, прежде всего, наращивалась тактовая частота. Последней модификацией стал Alpha 21264E, который работал на частоте 1250 МГц.

Увы, но линейка процессоров Alpha 21264 стала последней в истории «независимой» DEC. В начале 1998 года DEC признали банкротом, и она была поглощена компанией Compaq.

Архитектура Intel P5

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

Несмотря на то, что Intel вышла на рынок RISC-процессоров со своими решениями i860 и i960, основную ставку в компании все же делали на x86-кристаллы. Следующим поколением «камней» стали всем известные Pentium на базе архитектуры P5, выпущенные в 1993 году.

Была проделана большая работа. Во-первых, P5 стала суперскалярной. Архитектура работала с помощью двух конвейеров, каждый из которых мог выполнять две операции за такт. Во-вторых, шина данных стала 64-битной, что позволило передавать вдвое больший объем данных за цикл. В-третьих, кэш-память данных и инструкций была разделена на два отдельных блока объемом 8 Кбайт каждый. Помимо этого, в процессор был добавлен блок предсказания ветвлений, а модуль вычислений с плавающей запятой стал более производительным.

Первые процессоры линейки Pentium работали на частотах 60 МГц или 66 МГц. При этом для их работы требовалось напряжение 5 В, поэтому они сильно грелись. Также первые «пни» прославились неправильной работой блока вычислений с плавающей запятой, который в некоторых случаях при выполнении деления чисел выдавал неверный результат. Поэтому вскоре Intel запустила в продажу процессоры с исправленной архитектурой P54C.

Процессор Intel Pentium

P54C стала своего рода работой над ошибками. Производство новых процессоров было переведено на 0,6-мкм техпроцесс. Сами кристаллы теперь работали с напряжением 3,3 В, что позволило решить проблему с перегревом. Что касается изменений на уровне архитектуры, то в P54C был добавлен полуторный множитель - отныне процессоры работали на более высокой частоте, чем системная шина. Скорость работы процессоров составляла 75 МГц, 90 МГц или 100 МГц. Также P54C устанавливались в разъемы Socket 5 или Socket 7. В отличие от P5, которые поддерживали только Socket 4. Сама архитектура P54C еще раз получила обновление в 1995 году, когда была переведена на 350-нм техпроцесс. Это позволило вновь снизить энергопотребление кристаллов, а также увеличить их тактовую частоту до 200 МГц.

Стандарт IDEF0 является развитием классического DFD - подхо­да и предназначен для описания бизнес-процессов верхнего уровня. Для описания временной последовательности и алгоритмов выпол­нения работ стандарт IDEF0 не подходит. Для решения этой задачи стандарт IDEF0 получил дальнейшее развитие в результате чего был разработан стандарт IDEF3, который входит в семейство стандартов IDEF.

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

Отличием стандарта IDEF3 от классической методологии WFD яв­ляется также использование на схеме бизнес-процесса элемента «объект ссылки», который связывается с работами и перекрестками. С помощью объектов ссылки показывается прочая важная информа­ция, которую целесообразно зафиксировать при описании бизнес-процесса.

IDEF3 предполагает построение двух типов моделей: 1) модель, отражающая некоторые процессы в их логической по­следовательности, позволяющая увидеть, как функционирует пред­приятие;

2) модель, показывающая «сеть переходных состояний объекта», предлагающая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определен­ный процесс,

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

В отличие от классической методологии WFD в стандарте IDEF3 связи между работами делятся на три типа, обозначения, названия и смыл которых, приведены на рис. 3.16.

Существуют два типа диаграмм в стандарте IDEF3, представля­ющих описание одного и того же сценария технологического процес­са в разных ракурсах:

диаграммы Описания Последовательности Этапов Процес­са (Process Flow Description Diagrams, PFDD);

диаграммы Состояния Объекта и его Трансформаций в Процессе (Object State Transition Network, OSTN).

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

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

обработку.

Стрелки или линии являются отображением перемещения детали между иОВ-блоками в ходе процесса. Линии бывают следующих ви­дов:

Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз;

Отношения (Relational Link) - пунктирная линия, использу­ющаяся для изображения связей между UOB;

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

Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены пе­ред началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекре­сток не может использоваться одновременно для слияния и для раз­ветвления. При внесении перекрестка в диаграмму необходимо ука­зать тип перекрестка.

Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс «J».

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

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

Например, мы можем декомпозировать UOB «Окрасить Деталь», представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 3.18, а та, соответственно роди­тельской. Номера UOB дочерних диаграмм имеют сквозную нумера­цию, т.е., если родительский UOB имеет номер «1», то блоки UOB на его декомпозиции будут соответственно иметь номера «1.1». «1.2» и т.д. Применение принципа декомпозиции в IDEF 3 позволяет структу­рировано описывать процессы с любым требуемым уровнем детализа­ ции.

Если диаграммы PFDD технологический процесс «С точки зре­ния наблюдателя», то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс «С точки зрения объекта». Со­стояния объекта (в нашем случае детали) и Изменение состояния яв­ляются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линия­ми. Каждая линия имеет ссылку на соответствующий функциональ­ный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

Первой работой является «Обработка заявок». Эта работа использу­ет два объекта ссылок - «Заказы клиентов» и «Склад» - причем на диаграмме они показаны без деталей, т.к. не являются центральными для данной диаграммы. Работа «Обработка заявок» требует выпол­ нения одной из двух работ -либо «Оформление документов», либо «Дооформление заявок» (в случае, если заявка неверно оформлена). Ра­ бота «Дооформление заявок» использует ссылочный объект «Клиен­ты». Работа «Оформление документов» передает управление на две параллельные работы: «Формирование партии» и «Составление от­четности», причем работа «Формирование партии» также обраща­ется к ссылочному объекту «Заказы клиентов». Как видно, на диаграмме есть два перекрестка ветвления, перекре­ сток с ветвлением по логическому исключающему «ИЛИ», и перекре­ сток с ветвлением по «И», означающим выполнение двух работ парал­ лельно.

Методология ARIS

В настоящее время наблюдается тенденция интеграции разнооб­разных методов моделирования, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является программный продукт, носящий название ARIS (Architecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer.

ARIS поддерживает четыре типа моделей (и множество видов моделей в каждом типе), отражающих различные аспекты исследуе­мой системы:

организационные модели, представляющие структуру систе­мы - иерархию организационных подразделений, должностей и кон­кретных лиц, связи между ними, а также территориальную привязку структурных подразделений;

функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, не­обходимых для достижения поставленных целей;

информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;

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

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

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

Основная бизнес-модель ARIS - еЕРС (extended Event-driven Process Chain, расширенная модель цепочки процессов, управляемых событиями). Нотация ARIS еЕРС является расширением нотации IDEF3. Бизнес-процесс в нотации еЕРС представляет собой поток по­следовательно выполняемых работ (процедур, функций), располо­женных в порядке их выполнения. Реальная длительность выполне­ния процедур в еЕРС визуально не отражается. Для получения информации о реальной длительности процессов необходимо исполь­зовать другие инструменты описания, например, MS Project.

Модели в ARIS представляют собой диаграммы, элементами ко­торых являются разнообразные объекты - «функции», «события», «структурные подразделения», «документы» и т.д. Между объектами определённых видов могут быть установлены связи определённых видов («выполняет», «принимает решение», «должен быть проин­формирован о результатах» и т.д.). Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополни­тельную информацию о конкретном объекте.

Платформа ARIS является специализированным набором ин­струментов для структурированного описания и анализа бизнес-процессов. В состав системы входят функциональные модули для:

Проектирования и оптимизации бизнес-процессов (ARIS Easy Design, ARIS Toolset, ARIS Business Design, ARIS Business Architect, ARIS Business Server);

динамического анализа и оптимизации бизнес-процессов (ARIS Simulation);

разработки и внедрения системы менеджмента качества (ARIS Quality Management Scout);

мониторинга и контроля эффективности бизнес-процессов (ARIS Process Perfomance Manager);

управления процедурами, обеспечивающими работу системы внутреннего контроля за формированием финансовой отчетности (ARIS Audit manager):

разработки, внедрения и поддержания системы управления опе­рационными рисками (ARIS Process Risk Scout);

создания системы попроцессного калькулирования - Activity based costing (ARIS Process Cost Analyzer);

Проектирования системы сбалансированных показателей (ARIS

В ARIS существует более 130 различных способов графического представления моделей деятельности предприятия. Пример модели­рования в нотации ARIS представлен на рис. 3.20. и в Приложении Д.

Преимущества. ARIS-платформа обладает большим набором функций. В ней предусмотрена возможность анализа построенных моделей бизнес-процессов, определения «узких» мест и оптимизации бизнес-процессов на основе анализа «что-если». Иными словами, пользователь может изменять те или иные бизнес-процессы, к приме­ру, перераспределить полномочия сотрудников и оценить, насколько увеличится время на выполнение тех или иных операций или стои­мость работ. Модуль ARIS Process Cost Analyzer позволяет реализо­вать традиционную методологию Activity based costing для определе­ния стоимости бизнес-процессов, а результаты использовать в модуле стратегического управления предприятием (ARIS BSC). Применяя дополнительные модули и внутренний язык программирования, пользователь может сформировать любые регламенты и положения, а также управлять рисками компании, создать систему менеджмента качества и внутреннего контроля.

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

Например, ЕМ Tool Kit требуется пройти учебный курс длительно­ стью два-три дня, а для освоения основных функциональных возмож­ностей ARIS придется посетить несколько специализированных учеб­ ных курсов продолжительностью от пяти до пятнадцати дней.

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

Оплата безналичным расчетом

Рис. 3.20 - Модель верхнего уровня взаимосвязи ЗАТ НКМЗ с внешней средой в нотации AR1S Express

Моделирование бизнес-процессов -это

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

Целью моделирования является систе­ матизация знаний о предприятии и его биз­ нес-процессах в наглядной графической фор­ ме более удобной для аналитической обработки полученной информации.

Анализ бизнес-процессов предприятия с разных точек зрения называ­ется аудитом бизнес-процессов. Он проводится после создания и описа­ния модели предприятия.

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

Модель бизнес-процесса -прикладное представление (в заданной нотации) исполняемых предприятием работ.

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

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

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

Совокупность специальных графических элементов определяет нота­цию моделирования.

Методологии моделирования бизнес-процессов классифицируют по трем категориям: 1) Методологии ведения проекта; 2) Методологии использования программных продуктов для моделирования бизнес-процессов в проекте; 3) Методологии моделирования и анализа бизнес-процессов.

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

Методологии моделирования и анализа бизнес-процессов определя­ют руководящие указания для оценки и выбора проекта разрабатывае­мого программного продукта, шаги работы, которые должны быть вы-

полиены, их последовательность, правила распределения и назначения операций и методов.

SADT ( Structured Analysis and Design Tecchnique ) - методология структурного анализа и проектирования, которая породила целый ряд методов IDEFx . завоевавших особую популярность в задачах инжини­ ринга и реинжиниринга бизнес - процессов.

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

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

DFD ( Data Flow Diagrams ) - диаграммы потоков данных - методо­ логия структурного анализа, описывающая внешние по отношению к си­ стеме источники и адресаты данных, логические функции, потоки дан­ ных и хранилища данных к которым осуществляется доступ.

1. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация биз­нес- процессов [Текст]: учеб. посо­бие для студ. вузов, обучающихся по специальности 080801 «Прикладная информатика (по областям)» и др. экон. специальностям. - М. : Фи­нансы и статистика, 2007. - 240с.

Сериков А.В., Титов Н.В., Белоцерковский А.В., Лобанов А.В., Успаленко В.И. Компьютерное моделирование бизнес-процессов [Текст]: учеб. пособие для студ. вузов / Харьковский гос. техниче­ский ун-т строительства и архитектуры. - X. : Бурун Книга, 2007. -303 с.

Щенников С. Ю. Реинжиниринг бизнес-процессов. Экспертное моделирование, управление, планирование и оценка [Текст]. - М.:Ось-89, 2004. -288 с.

Робсон Майк, Уллах Филип. Реинжиниринг бизнес-процессов [Текст]: Практическое руководство / Л.Е. Долгова (пер.). - М. : ЮНИТИ, 2003. - 222 с.

Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов [Текст]. - М.: РИА «Стандар­ты и качество», 2004. - 408 с

а Шеер Август-Вильгельм. Моделирование бизнес-процессов [Текст]. - М.: Весть-МетаТехнология, 2000. - 206 с.

7 Виноградова О.В. Реінжиніринг бізнес-процесів торговельних підприємств [Текст]: Монографія. - Донецьк: ДонДУЕТ, 2006.- 183 с.

Виноградова О.В. Реінжиніринг бізнес-процесів у сучасному ме­неджменті [Текст]: Монографія. - Донецьк: ДонДУЕТ, 2005. - 195 с.

Ойхман Е.Г. Реинжиниринг бизнеса [Текст]/ Е. - М.: Финансы и статистика, 1997. - 336с.

Ю.Марка Д. Методология структурного анализа и проектирования.

[Текст] / Марка Д. - пер. с англ. - М. Финансы и статистика. -

2003. -240 с. H.Draheim, D. Business process technology: a unified view on business

processes, workflows and enterprise applications / Dirk

Draheim. - Berlin: Springer, 2010. - 323 p. 12.Holt, J. A Pragmatic guide to business process modelling / Jon

Holt. - British Informatics Society Ltd, 2009. - 246 p. 13.Laguna, M. Business process modeling, simulation and design /

Manuel Laguna, Johan Marklund. - Prentice Hall, 2005. - 429 p.

/. Что представляет собой процесс мо­делирования бизнес-процессов?

Назовите цель моделирования бизнес-процессов.

Перечислите преимущества моделиро­вания.

Что называется аудитом бизнес-процессов?

Перечислите причины, по которым принимается решение по моделирова­нию бизнес-процессов.

6 Что представляет собой модель в целом? 7 Раскройте сущность модели бизнес-процесса.

8 В чем состоит сущность нотации бизнес-процессов?

9- Перечислите виды моделей, которые могут применяться в дея­ тельности предприятия. Раскройте их сущность.

10. В каких формах может производиться описание бизнес-процесса? В чем их преимущества и недостатки? П. Что представляет собой методология?

По каким признакам классифицируют методологии моделирова­ния бизнес-процессов?

Раскройте сущность методологий ведения проектов.

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

В чем состоит сущность методологии моделирования и анализа бизнес-процессов?

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

В чем состоит многообразие «проекций» предприятия?

SADT . Охарактеризуйте ти­пы данных моделей.

Какие основные элементы используются в модели по SADT ?

Раскройте историю появления методологии IDEFO .

Какие основные понятия лежат в основе методологии IDEFO ? Раскройте их содержание.

Какие составляющие имеет функциональный блок?

Охарактеризуйте виды интерфейсных дуг.

В чем заключается сущность принципа декомпозиции и в каких случаях декомпозиция выполняется?

Для чего необходим глоссарий?

В каких случаях используются диаграммы потоков данных DFD (Data Flow Diagrams )?

Перечислите и раскройте сущность основных элементов DFD диаграмм.

Раскройте сущность методологии DFD в нотациях Гейна-Сарсона и Иордана-Де Марко. В чем их сходства и отличия?

Для каких целей был разработан стандарт IDEF 3?

Назовите основные отличия стандарта 1 DEF 3 от классической методологии WFD .

Какие два типа диаграмм используются в стандарте IDEF 3?

І.Что понимают под моделирова­нием бизнес-процессов?

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

б) это эффективное средство поиска путей оптимизации деятель­ ности предприятия, позволяющее определить, как оно работает в целом и как организована деятельность на каждом рабочем месте;

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

Моделирование бизнес-процессов с BPwin 4.0 Маклаков Сергей Владимирович

1.4.2. Метод описания процессов IDEF3

1.4.2. Метод описания процессов IDEF3

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа события, которые необходимо обработать за конечное время. Каждый тенарий сопровождается описанием процесса и может быть использован я документирования каждой функции.

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

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

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

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

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

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

Единицы работы - Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, "Изготовление изделия"). Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается п Ри создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.

Работа в IDEF3 требует более подробного описания, чем работа в IDEF0 Каждая UOW должна иметь ассоциированный документ, который включает текстовое описание компонентов работы: объектов (Objects) и фактов (Facts), связанных с работой, ограничений (Constraints), накладываемых на работу, и дополнительное описание работы (Description). Эта информация заносится во вкладку UOW диалога Activity Properties (рис. 1.4.4).

Рис. 1.4.4. Вкладка UOW диалога Activity Properties Пример значений свойств UOW приведен в табл. 1.4.1.

Таблица 1.4.1. Пример текстового описания компонентов UOW

ТunИспользование

NAMEПодготовка компонентов

"DefinitionПодготавливаются все компоненты компьютера согласно

спецификации заказа

"ObjectsКомпоненты: винчестеры, корпуса, материнские платы,

видиокарты, звуковые карты, дисководы CD-ROM

и флоппи, модемы, программное обеспечение

"Constrains Установка модема требует установки дополнительного пограммного обеспечения

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

Рис. 1.4.5. Вкладка Style диалога Arrow Properties

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

Стрелка отношения (Relational Link) - пунктирная линия, использующаяся для изображения связей между единицами работ (UOW), а также между единицами работ и объектами ссылок.

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

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

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

Старт работы Окончание работы Старт работы- Окончание-источника -источника цели работы -цели Старшая или поток объектов

Старт работы Старт работы- Окончание работы Окончание -источника цели -источника работы-цели "" Отношение

Старт работы Старт работы- Отношение Окончание работы -источника цели работы-цели -источника Отношение

Рис. 1.4.6. Временная диаграмма выполнения работ

Перекрестки (Junction). Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны завершены перед началом следующей работы. Различают перекрестки я слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для «ветвления. Для внесения перекрестка служит кнопка Щ (добавить ^диаграмму перекресток - Junction) в палитре инструментов. В диалоге junction Type Editor необходимо указать тип перекрестка. Смысл каждого типа приведен в табл. 1.4.2.

Таблица 1.4.2. Типы перекрестков

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Junction Properties (вызывается из контекстного меню). В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки. Рис. 1.4.7-1.4.11 иллюстрируют смысл перекрестков каждого типа.

Рис. 1.4.7. Перекрестки для слияния и разветвления типа синхронного "И". Здесь после завершения работы 1 одновременно запускаются работы 2 и 4. Для запуска работы 5 требуется одновременное завершение работ 3 и 4

Рис. 1.4.8. Перекрестки для слияния и разветвления типа асинхронного "И". Здесь после завершения работы 1 запускаются работы 2 и 4 (не обязательно одновременно). Для запуска работы 5 требуется завершение работ 3 и 4 (не обязательно одновременное)

Рис. 1.4.9. Перекрестки для слияния и разветвления типа асинхронного "ИЛИ". Здесь после завершения работы 1 запускается либо работа 2, либо работа 3, либо работа 4, либо их сочетание (не обязательно одновременно). Для запуска работы 5 требуется завершение любой из работ 2, 3 и 4 или их сочетания (не обязательно одновременное)

Рис. 1.4.10. Перекрестки для слияния и разветвления типа синхронного "ИЛИ". Здесь после завершения работы 1 запускается либо работа 2, либо работа 3, либо работа 4, либо их сочетание. Если запускается более одной работы, требуется их одновременный запуск. Для запуска работы 5 требуется завершение любой из работ 2, 3 и 4 или их сочетания. Если завершается более чем одна работа, требуется их одновременное завершение

Рис. 1.4.11. Перекрестки для слияния и разветвления типа исключающего "ИЛИ". Здесь после завершения работы 1 запускается только одна работа - либо работа 3, либо работа 4. Для запуска работы 5 требуется завершение только одной из работ, 3 или 4

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

Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.

Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа синхронного или асинхронного "ИЛИ" (рис. 1.4.12).

Действительно, после работы 1 может запускаться только одна работа - 2 или 3, а для запуска работы 4 требуется окончание обеих работ - 2 и 3. Такой сценарий не может реализоваться.

Рис. 1.4.12. Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления "ИЛИ"

Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ" (рис. 1.4.13).

Рис. 1.4.13. Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ"

4. Перекресток для слияния типа исключающего "ИЛИ" не может следовать за перекрестком для разветвления типа "И" (рис. 1.4.14). Здесь после завершения работы 1 запускаются обе работы - 2 и 3, а для запуска работы 4 требуется, чтобы завершилась одна и только одна работа -или 2, или 3.

Рис. 1.4.14. Неверное размещение перекрестков. Перекресток для слияния типа исключающего "ИЛИ" не может следовать за перекрестком для разветвления типа "И"

Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.

Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой (рис. 1.4.15). Для внесения объекта ссылки служит кнопка ШЗ (добавить в диаграмму объект ссылки - Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent Properties (пункт контекстного меню Name), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок - безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.

При внесении объектов ссылок помимо имени следует указывать л объекта ссылки. Типы объектов ссылок приведены в табл. 1.4.3.

Таблица 1.4.3. Типы объектов ссылок

Декомпозиция работ. В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т. е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Декомпозиция может быть сценарием или описанием. Описание включает все возможные пути развития процесса. Сценарий является частным случаем описания и иллюстрирует только один путь реализации процесса. По умолчанию при декомпозиции на диаграмму IDEF3 создается описание. Чтобы создать сценарий, необходимо перейти в меню Diagram/Add IDEF3 Scenario.

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

Рис. 1.4.16. Номер единицы работы (UOW)

Для описания номер декомпозиции равен 1. Для сценария номер декомпозиции всегда больше 1.

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

Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области.

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

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

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

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

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

Таблица 1.4.4. Диапазоны номеров работ

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

Работы, перекрестки и документирование объектов. IDEF3 позволяет внести информацию в модель различными способами. Например, логика взаимодействия может быть отображена графически в виде комбинации перекрестков. Та же информация может быть отображена в виде объекта ссылки типа ELAB (Elaboration). Это позволяет аналитику вносить информацию в удобном в данный момент времени виде. Важно учитывать, что модели могут быть реорганизованы, например для их представления в более презентабельном виде. Выбор формата для презентации часто имеет важное значение для организации модели, поскольку комбинация перекрестков занимает значительное место на диаграмме и использование иерархии перекрестков затрудняет расположение работ на диаграмме.

Из книги C++ автора Хилл Мюррей

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

Из книги Справочное руководство по C++ автора Страустрап Бьярн

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

Из книги Практика и проблематика моделирования бизнес-процессов автора Всяких Е И

8. Описания Описания используются для определения интерпретации, дваемой каждому идентификатору. Они не обязательно резервируют память, связанную с идентификатором. Описания имеют вид:описание: спецификаторы_описания opt список_описателей opt ; описание_имени

Из книги BPwin и Erwin. CASE-средства для разработки информационных систем автора

8.5 Описания Классов Класс есть тип. Его имя становится typedef-имя (см. #8.8), которое может быть использовано даже внутри самого спецификатора класса. Объекты класса состоят из последовтельности членов.спецификатор_класса: заголовок_класса (* список_членов opt *) заголовок_класса

Из книги Моделирование бизнес-процессов с BPwin 4.0 автора Маклаков Сергей Владимирович

8.10 Описания Перечислений Перечисления являются типами int с именованными констатами.enum_спецификатор: enum идентификатор opt (* enum_список *)enum_список: перечислитель enum_список, перечислительперечислитель: идентификатор идентификатор = константное_выражениеИдентификаторы в

Из книги Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ автора Борри Хелен

14.2 Описания описание: спецификаторы_описания opt список_описателей opt ; описание_имени asm-описаниеописание_имени: сост идентификатор; enum идентификатор;сост:class struct unionasm-описание: asm (строка) ;спецификаторы_описания: спецификатор_описания спецификаторы_описания

Из книги автора

R.17.5 Описания класса спецификация-класса: заголовок-класса { список-членов opt }заголовок-класса: служебное-слово-класса идентификатор opt спец-базовых opt служебное-слово-класса имя-класса спец-базовых optслужебное-слово-класса: class struct unionсписок-членов: описание-члена

Из книги автора

Из книги автора

1.5. Дополнение созданной модели процессов диаграммами DFD и Workflow (IDEF3) 1.5.1. Диаграммы потоков данных (Data Flow Diagramming) Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как

Из книги автора

1.4. Дополнение созданной модели процессов организационными диаграммами, диаграммами DFD и Workflow (IDEF3) 1.4.1. Диаграммы потоков данных (Data Flow Diagramming) Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD

Из книги автора

1.4.2. Метод описания процессов IDEF3 Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более

Из книги автора

4.14.4. Модификация диаграммы IDEF3 "Сборка продукта" с целью отображения новой информации Так же как в модели AS-IS, сборка продукта состоит из сборки компонентов и установки программного обеспечения. Однако теперь в работу "Сборка продукта" включена работа "Тестирование

Из книги автора

Структурные описания Метаданные- физические описания таблиц, их столбцов и атрибутов, так же как и описания всех других объектов - сами хранятся в обычных таблицах Firebird внутри базы данных. Сервер Firebird изменяет данные в этих таблицах, когда объекты базы данных создаются,