ЧАСТЬ 2. МЕТОДОЛОГИЯ И ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА РЕИНЖИНИРИНГА БИЗНЕС-ПРОЦЕССОВ

ТЕМА 10. КЛАССИФИКАЦИЯ CASE-СРЕДСТВ И МОДЕЛЕЙ

1. Современная концепция разработки информационных систем

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

 

2. Модель "asis" (как есть) - позитивная модель

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

На этапе анализа, прежде всего, необходимо тщательное изучение текущей деятельности клиента, построение и исследование модели "как есть". Для построения используется функциональное подмножество технологии SADT— IDEFO и, для построения информационной модели, IDEF1X. Так как вопросы построения информационной модели выходят за рамки данной статьи, ограничимся рассмотрением только функциональных моделей.

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

1.      модель бизнес-процессов, дающую общую картину деятельности;

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

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

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

3. Модель "tobe"- нормативная модель

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

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

4. CASE моделирование бизнес-процессов

Если это “средства”, то они должны к чему-то быть примененными. Так оно и есть. Они и создавались первоначально как специализированные методы решения специализированных задач. Нас они интересуют в первую очередь как средства анализа бизнес процессов. Для того, чтобы понять, что скрывается за этим понятием, лучше обратиться к совершенно конкретной области, например, области проектиро­вания автоматизированных информационных систем (АИС), где CASE - средства как раз эффективно и применяются.

В проектировании АИС выделяют обычно два направления:

1.      собственно проектирование АИС конкретных организаций на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки;

2.      проектирование упомянутых компонентов АИС и инструментальных средств, ориентированных на многократное применение при разработке многих информационных систем.

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

Второе направление относится к области разработки математического и программного обеспечения для реализации функций АИС - моделей, методов, алгорит­мов, программ на базе знания системотехники, методов анализа и синтеза проектных решений, технологий программирования, операционных систем и т. п.

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

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

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

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

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

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

Для решения задач концептуального моделирования за последнее десятилетие сформировалась новая технология - CASE. Используется двоякое толкование аббре­виатуры CASE, соответствующее двум направлениям использования CASE-систем. Первое из них, более узкое, - Computer-AidedSoftwareEngineering– переводится как автоматизированное проектирование программного обеспечения. Соответствующие CASE-системы часто называют инструментальными средами быстрой разработки ПО (RAD– RapidApplicationDevelopment).

Второе, более широкое, - Computer-AidedSystemEngineering– подчеркивает направленность на поддержку концептуального проектирования сложных систем вообще. Такие CASE-системы часто называют системами BPR (BusinessProcessReengineering) и нас в данном случае интересуют в первую очередь.

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

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

Ядром CASE-инструмектария являются технологии анализа и проектирования, такие, например, как объектно-ориентированный анализ, структурное проектирование Джексона, методология структурного анализа Йордана/де Марко и Геина-Сарсона, технология структурного анализа и проектирования систем - SADT (StructuredAnalysisandDesignTechnique). Такие технологии обеспечивают строгое и наглядное описание проектируемой системы в форме графов, диаграмм, таблиц и схем, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру с все большим числом уровней.

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

Заметим в заключение этого раздела, что подмножество SADT принято в качест­ве стандарта на разработку ПО (IDEFO) Министерством обороны США. Отсюда и используемая далее аббревиатура “SADT - IDEF”

В качестве CASE-средства реализующего методологию SADT в пособии рассматривается программный комплекс BPWin фирмы Platinum (см. рис. 10.1).

Рис. 10.1. Инструментальная панель PLATINUMBPWin

5. Типы CASE-моделей

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

Взаимная совокупность методик и моделей концептуального проектирования IDEF (IntegratedDEFfimtion) разработана по программе IntegratedComputer-AidedManufactunng в США. В этой совокупности имеются методики функционального информационного и поведенческого моделирования и проектирования в ее состав в настоящее время входят IDEF- модели отмеченные в табл. 10.1.

Таблица 10.1

Совокупность моделей концептуального проектирования IDEF

Прокомментируем содержимое представленной таблицы.

IDEFO реализует методику функционального моделирования сложных систем. Наиболее известной является методика SADT (StructuredAnalysisandDesignTechnique), предложенная в 1973 году Д.Россом и впоследствии ставшая основой стан­дарта IDEFO. Эта методика рекомендуется для начальных стадий проектирования сложных искусственных систем управления, производства, бизнеса, включающих лю­дей, оборудование, программное обеспечение

IDEF1X и IDEF1 реализуют методики инфологического проектирования баз данных. В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях - так называемый язык диаграмм "сущность-связь" (ERD - Entity-RelationsDiagrams) Разработка информационной модели по IDEF1X выполняется в несколько этапов.

• Выясняются цели проекта, составляется план сбора информации. Обычно ис­ходные положения для информационной модели следуют из IDEFO-модели.
• Выявление и определение сущностей.
• Выявление и определение основных отношений. Результат представляется или графически в виде так называемых ER-диаграмм. или в виде матрицы от­ношений.
• Детализации неспецифических отношений, определение ключевых атрибутов, установление внешних ключей. Детализация отношений заключается в заме­не связей "многие ко многим" на связи "многие к одному" и "один ко многим" введением сущности – посредника.
• Определение атрибутов и их принадлежности сущностям.

IDEF2 и IDEF3 реализуют поведенческое моделирование. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос "Что делает система?", то в этих методиках детализируется и конкретизируется ответ на вопрос "Как система это делает". В основе поведенческого моделирования лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, возможно применение модели конечного автомата, описывающей поведение системы как последовательности смен состояний.

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

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

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

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

IDEF8 предназначена для проектирования диалога человека с технической системой.

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

IDEF14 предназначена для представления и анализа данных при проектировании вы­числительных сетей на графическом языке с описанием конфигураций, очередей, се­тевых компонентов, требований к надежности и тому подобное. Основные положения стандартов IDEFO и IDEF1X использованы также в комплексах стандартов ISO 10303, задающих технологию STEP для представления в компьютерных средах информации, относящейся к промышленному производству.

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

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

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

Информационная модель отображает отношения между элементами системы в виде структур данных (состав я взаимосвязи).

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

Сочетания типов моделей образуют стандартные CASE-модели. В табл. 10.2 перечислены основные методологические стандартные модели, ис­пользуемые при CASE-моделировании.
Таблица 10.2

Основные типы CASE-МОДЕЛЕЙ

На рынке программных продуктов имеется много CASE-систем для концептуального проектирования систем, поддерживающих перечисленные модели. Чаще всего речь идет о поддержке методологии IDEF. В России достаточно широко известны продукты BPWin, ERWin, OOwin, фирмы Platimum, Design/IDEF фирмы MetaSoftware, CASE-Аналитик фирмы Эйтэкс, Silverun фирмы CSA, ParadigmPlus и др.

Система BPWin (BusinessProcessing) предназначена для разработки функциональных моделей по методике IDEFO.

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

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

1. SADT-модели

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

SADT-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Это назначение, называемое целью модели, вытекает из формального определения модели в SADT:

Определение 1. Модель М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.

Определение 2. SADT –модели, ориентированные на функции системы, называются функциональными моделями

Определение 3. SADT – модели, ориентированные на объекты системы, называются моделями данных

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

Таким образом, целью модели является получение ответов на некоторую совокупность вопросов. Эти вопросы неявно присутствуют (подразумеваются) в процессе анализа и, следовательно, они руководят созданием модели и направляют его. Это означает, что сама модель должна будет дать ответы на эти вопросы с заданной степенью точности. Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели. Определяя модель, таким образом, SADT закладывает основы практического моделирования.

Смысл и трактовка этого определения оказали существенное влияние на практические применения SADT. Обычно вопросы для SADT-модели формулируются на самом раннем этапе проектирования, при этом основная суть этих вопросов должна быть выражена в одной-двух фразах. На рис.11.1 показана работа автора модели, использующего SADT для определения цели модели экспериментального механического цеха (ЭМЦ). Обратите внимание на то, что, познакомившись с постановкой задачи и кратким описанием процесса, автор составил список вопросов и свел этот список в одно предложение. Это предложение становится целью модели, а список вопросов сохраняется как детализация этого предложения. После завершения работы над моделью информация, содержащаяся в модели, будет отвечать на поставленные вопросы.

Какая степень точности приемлема для модели экспериментального механического цеха?

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

1. SADT-модели

Рис 11.1. Определение цели и точки зрения модели ЭМЦ

 

ТЕМА 11. ВВЕДЕНИЕ В SADT-МОДЕЛИРОВАНИЕ

 

2. Свойства SADT-модели

 

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

 

• SADT – модель имеет цель, представляющую набор вопросов, на которые должна ответить модель
• SADT – модель, будучи некоторым толкованием системы, имеет единственный субъект. Субъект определяет, что включать в модель, а что исключить из нее.
• SADT – модель имеет только одну точку зрения – позицию, с которой описывается система. Точка зрения диктует автору модели выбор нужной информации о субъекте и форму ее подачи
  • левая - для входа;
  • верхняя - для управления (ограничения или условия выполнения преобразований);
  • правая - для выхода;
  • нижняя - для механизмов (кто, что и как выполняет функции).
  • непомеченные ветви содержат все объекты, указанные в метке дуги перед разветвлением (т.е. объекты принадлежат этим ветвям)
  • ветви, помеченные после точки разветвления, содержат все объекты или их часть, указанные в метке дуги перед разветвлением (т.е. каждая метка ветви уточняет, что именно содержит ветвь).
  • непомеченные ветви содержат все объекты, указанные в общей метке дуги после слияния (т.е. все объекты исходят из всех ветвей);
  • помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния (т.е. метка ветви ясно указывает, что содержит ветвь).
• представьте себе рисунок новой диаграммы внутри разлагаемого блока. Продлите внешние дуги почти до края диаграммы. Зрительно соедините каждую внешнюю дугу диаграммы с соответствующей граничной дугой декомпозируемого блока (на рис. 13.3 в некоторых местах мы используем пунктирные линии для изображения процесса зрительного соединения).
• присвойте код каждой зрительной связи. Используйте I для входных дуг, С - для связей между дугами управления, О - для связей между выходными дугами, М - для связей между дугами механизма.
• добавьте после каждой буквы цифру, соответствующую положению данной дуги среди других дуг того же типа, касающихся родительского блока. Причем входные и выходные дуги пересчитываются сверху вниз, а дуги управлений и механизмов пересчитываются слева направо (см. рис. 13.3). Теперь запишите каждый код около окончания каждой внешней дуги.

 

Определение: SADT- моделирование – процесс, конечным результатом которого является набор тщательно взаимоувязанных описаний (SADT – диаграмма ), начиная с описания самого верхнего уровня всей системы и кончая подробным описанием деталей или операций системы

 

3. Модель имеет единственный субъект

 

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

 

4. У модели может быть только одна точка зрения

 

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

 

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

 

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

 

5. Модели как взаимосвязанные наборы диаграмм

 

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

 

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

 

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

 

Рис. 11.2. Две взаимосвязанных SADT-модели

 

6. Резюме

 

Сложности, связанные с описанием многих искусственных систем, объясняются тем, что эти системы слишком велики для того, чтобы можно было просто перечислить все их компоненты. С другой стороны, они могут быть упрощены за счет обобщающих предположений. Методология SADT создана специально для представления таких сложных систем путем построения моделей. SADT-модель - это описание системы, у которого есть единственный субъект, цель и одна точка зрения. Целью служит набор вопросов, на которые должна ответить модель. Точка зрения - позиция, с которой описывается система. Цель и точка зрения - это основополагающие понятия SADT. Описание модели SADT организовано в виде иерархии взаимосвязанных диаграмм. Вершина этой древовидной структуры представляет собой самое общее описание системы, а ее основание состоит из наиболее детализированных описаний.

 

ТЕМА 12. СИНТАКСИС SADT-ДИАГРАММ

 

1. SADT-диаграмма

 

SADT- диаграмма – основной рабочий элемент при создании моделей, имеющие собственные синтаксические правила.

 

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

 

SADT - диаграммы содержат блоки и дуги. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними. На рис. 12.1 приведен пример типичной SADT-диаграммы. 

 

Рис. 12.1. Типичная SADT-диаграмма

 

2. Блоки и дуги

 

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

 

Стороны блока:

 

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

 

1 - наибольшее доминирование;

 

2 - на следующее после наибольшего и т.д.

 

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

 

Пять типов взаимодействия между блоками для описания их отношений:

 

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

 

2.    по входу - возникает тогда, когда выход одного блока становится входом для блока с меньшим доминированием;

 

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

 

4.    обратная связь по входу - когда выход одного блока становится входом другого блока с большим доминированием;

 

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

 

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

 

3. Разветвление и слияние дуг

 

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

 

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

 

4. Идентификация версий диаграмм С-номерами

 

При создании SADT-модели одну и ту же диаграмму вместе с ее блоками и дугами перечерчивают несколько раз, что приводит к появлению различных ее вариантов. Чтобы различать разные версии одной и той же диаграммы, в SADT используется схема контроля конфигурации диаграмм, основанная на хронологических номерах, или С-номерах. С-номерные коды образуются из инициалов автора и последовательных номеров. Эти коды ставятся в нижнем правом углу SADT-бланка. Например, DAM010 – это С-номер для диаграммы выполнить задание на рис. 12.1 Если диаграмма заменяет более старый вариант, то автор помещает предыдущий С-номер в скобках, чтобы указать на связь с предыдущей работой. Например, диаграмма DAM010 заменяет предыдущую версию DAM009. Каждый автор проекта SADT ведет реестр всех созданных им диаграмм, нумеруя их последовательными целыми числами. Для этого используется бланк реестра С-номеров SADT.

 

5. Резюме

 

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

 

ТЕМА 13. СИНТАКСИС МОДЕЛЕЙ И РАБОТА С НИМИ

 

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

 

1. Система представляется одним блоком

 

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

 

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

 

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

 

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

 

Рис 13.1. Контекстная диаграмма модели

 

2. Идентификация декомпозиции номерами узлов

 

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

 

Таким образом, каждая диаграмма представляет собой некоторую законченную часть всей модели. В методологии SADT идентифицируется каждая диаграмма данной модели посредством того, что называется "номер узла". Номер узла для контекстной диаграммы имеет следующий вид: название модели или аббревиатура, косая черта, заглавная буква A (Activity в функциональных диаграммах), дефис и ноль. Например, номером узла для контекстной диаграммы модели экспериментального механического цеха является ЭМЦ/А-0. Номером узла диаграммы, декомпозирующей контекстную диаграмму, является тот же номер узла, но без дефиса (например, ЭМЦ/АО). Все другие номера узлов образуются посредством добавления к номеру узла родительской диаграммы номера декомпозируемого блока. На рис. 13.2 показаны две диаграммы модели экспериментального механического цеха. Номер узла на первой диаграмме - ЭМЦ/АО, а номер узла на второй диаграмме - ЭМЦ/А1. Диаграмма ЭМЦ/А1 декомпозирует блок 1 диаграммы ЭМЦ/АО. (Первый ноль при образовании номера узла принято опускать, поэтому вместо ЭМЦ/А01 пишется ЭМЦ/А1.)

 

3. Связывание декомпозиции с помощью С-номеров

 

Помимо использования для идентификации версий диаграмм, С-номера применяются для связки диаграмм при движении как вверх, так и вниз по иерархии модели. Обычно С-номер диаграммы, декомпозирующей некоторый блок, впервые появляется непосредственно под этим блоком на родительской диаграмме. Это образует "направленную вниз" связь от родительской диаграммы к диаграмме-потомку. На рис. 13.2 С-номер DAM008 диаграммы управлять выполнением задания размещен ниже блока 1 на диаграмме изготовить нестандартную деталь. Это указывает на то, что функция управлять выполнением задания была декомпозирована.

 

Рис 13.2. Связь между родительской диаграммой и диаграммой потомком

 

Как только образуется направленная вниз связь, на диаграмме-потомке формируется ссылка на родительскую диаграмму. В области контекста SADT-бланка (правый верхний угол) автор изображает каждый блок родительской диаграммы маленькими квадратиками, заштриховывает квадратик декомпозируемого блока и размещает С-номер родительской диаграммы возле заштрихованного квадратика. Это образует "направленную вверх" (к родительской диаграмме) связь. Метод соединения диаграмм посредством однозначно определенных номеров гарантирует, что именно нужная версия диаграммы станет частью модели. Другими словами, при использовании С-номеров осуществляется тщательный контроль за введением новых диаграмм в иерархию модели. На рис. 13.2 область контекста бланка диаграммы управлять выполнением задания содержит три квадратика - по одному для каждого блока диаграммы изготовить нестандартную деталь. Первый блок заштрихован. Это указывает на то, что данная диаграмма декомпозирует первый блок диаграммы DAM008.

 

4. Коды ICOM гарантируют стыковку диаграмм

 

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

 

В SADT принята система обозначений, позволяющая аналитику точно идентифицировать и проверять связи по дугам между диаграммами. Эта схема кодирования дуг -"ICOM" - получила название по первым буквам английских эквивалентов слов вход (Input), управление (Control), выход (Output), механизм (Mechanism). Коды ICOM чрезвычайно эффективны, поскольку они позволяют аналитику быстро проверять согласованность внешних дуг диаграммы с граничными дугами соответствующего блока родительской диаграммы. Они также обеспечивают согласованность декомпозиции, поскольку все дуги, входящие в диаграмму и выходящие из нее, должны быть учтены. На рис. 13.2дуга требования по срокам выполнения задания может быть отслежена от ее начала (С1 блока 0 диаграммы ЭМЦ/ А-0) на границе модели через верхнюю часть диаграммы ЭМЦ/АО к блоку управлять выполнением задания (СЗ блока 4 диаграммы ЭМЦ/ А1).

 

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

 

На рис. 13.3 приведены субъект и его границы (блок и прилегающие дуги) и декомпозирующая его диаграмма. Обратите внимание, что граница субъекта изображена жирной линией для того, чтобы подчеркнуть, как внешние дуги связаны с соответствующими граничными дугами. В этом примере на диаграмме пунктирными линиями изображены зрительные связи только между выходными дугами и соответствующими им граничными дугами. (Другие связи легко определить зрительно.) В соответствии со схемой кодирования для рис. 13.3 были получены коды ICOM: II, 12, Cl, C2, 01, 02, Ml. Кодирование дуг ICOM-метками произведено в зависимости от того, к какой стороне родительского блока примыкает данная дуга.

 

При следовании схеме кодирования ICOM создается совокупность неявных связующих звеньев между страницами, которые можно быстро изменить при изменении границ. (Сравните схему кодирования ICOM/SADT с альтернативной схемой, в которой внешние дуги просто помечаются определенным образом, скажем, буквами от А до Я.) Эти неявные межстраничные связующие звенья облегчают процесс чтения и рецензирования SADT-диаграмм, а также проверку, насколько согласованно произведена декомпозиция. Коды ICOM упрощают также работу, связанную с внесением вручную локальных изменений в диаграмму, и объединяют различные варианты диаграмм так, что они хорошо стыкуются в модели. По нашему мнению, коды ICOM являются одним из наиболее важных вкладов SADT в технологию графического моделирования. Они обеспечивают требуемую строгость, позволяя в то же время авторам работать независимо, чертить разборчиво и выбирать без ущерба для предыдущей работы подходящую терминологию на последующих уровнях детализации.

 

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

 

Номера узлов, С-номера и коды ICOM управляют подавляющим большинством ситуаций внутренних связей в модели. Однако между родительскими диаграммами и диаграммами-потомками могут возникать некоторые специфические ситуации, в которых разумное использование синтаксиса модели улучшает описание модели, а именно: (1) при разветвлении и соединении внешних дуг; (2) при изменении входных дуг на управляющие и наоборот; (3) когда дуги "входят в тоннель". Необходимо предупредить, что такие средства изображения следует использовать только в особых ситуациях для прояснения и упрощения описания системы. Их следует применять для удобства, а не как прикрытие плохого анализа систем. Во всех этих случаях данные при пересечении границ диаграмм сохраняются, т. е. все входные данные некоторым образом используются для образования всех выходных данных. Ключом для понимания таких ситуаций является то, что дуги SADT изображают иерархические наборы данных.

 

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

 

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

 

Две другие особые ситуации возникают, когда дуги "входят в тоннель" между диаграммами. Дуга "входит в тоннель", либо (1) если она является внешней дугой, которая отсутствует на родительской диаграмме (имеет скрытый источник), либо (2) если она касается блока, но не появляется на диаграмме, которая его декомпозирует (имеет скрытый приемник). Тоннельные дуги от скрытого источника начинаются скобками, чтобы указать, что эти дуги идут из какой-то другой части модели или прямо извне модели. На рис. 13.2 дуга незанятый рабочий С1 блока получить задание и назначить исполнителя на диаграмме ЭМЦ/А1 входит в тоннель и поэтому она не касается блока управлять выполнением задания на родительской диаграмме ЭМЦ/АО. Тоннельные дуги, имеющие скрытый приемник, кончаются скобками, чтобы отразить тот факт, что такая дуга идет к какой-то другой части модели или выходит из нее или что она не будет более в этой модели рассматриваться. На рис. 13.3 все дуги механизмов диаграммы изготовить нестандартную деталь являются тоннельными и указывают на то, что они не будут показаны при декомпозиции соответствующих блоков.

 

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

 

Рис 13.2. Связь между родительской диаграммой и диаграммой потомком

 

Рис 13.3. Кодирование связей между SADT-диаграммами

 

6. Резюме

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