А Использование кладовой

Обзор

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

Упаковка

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

Хранение

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

Извлечение

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

Проверка

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

Подсчет

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

Оглавление

А-Питание семьи (контекст)

Все члены семьи в будние дни питаются дома два раза в день (завтрак и ужин), обедая в школе или на работе, и три раза в день по субботам и воскресеньям (завтрак, обед и ужин). На деньги, которые мы дали, покупайте продукты. Старайтесь уложиться в бюджет, чтобы вы смогли питаться в течение всей недели. Держите "малышей" в порядке, следуя обычным семейным правилам. В этом случае им будет труднее спорить с вами. И не забудьте, что мусоросборочная машина приезжает в семь часов утра по средам. Чтобы выбросить мусор, вам придется проснуться рано, поскольку его нельзя оставлять на ночь снаружи.

А Поддержание запасов

Обзор

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

Хранение

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

Планирование

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

Покупки

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

АО Питание семьи (обзор)

Обзор

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

Планирование

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

Запасание продуктов

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

Приготовление

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

Еда

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

Уборка

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

Беседа автор/читатель

Иногда возникают серьезные разногласия, существенное взаимное непонимание или остается непонятым важное замечание. В подобных случаях запишите эти проблемы на титульном листе в форме замечания. Мы рекомендуем в конце каждого такого замечания писать заглавными буквами слова ДАВАЙТЕ ПОБЕСЕДУЕМ. Это укажет читателю на ваше желание провести диалог автор/читатель для более тщательного обсуждения разногласий. Сделав это, вы продемонстрируете читателю ваше желание к интенсификации обратной связи. Но прежде чем вы встретитесь, подготовьте список вопросов, которые следует обсудить в ходе беседы автор/читатель. Проведите встречу и рассмотрите последовательно все вопросы один за другим. Выработайте решение каждой проблемы и запишите его в папке в виде замечания "с кружком".

Во время встречи придерживайтесь запланированной тематики и старайтесь уложиться в один час. Может оказаться, что встреча затянется из-за того, что вопросы потребуют дополнительного обдумывания или возникнут новые проблемы. Запишите новые проблемы и быстро вернитесь к исходной теме. Если потребуются дополнительные размышления, мы не советуем вам продолжать встречу намного дольше часа. Наш опыт показывает, что после часа интенсивных размышлений над сложной проблемой начинает падать продуктивность беседы. Лучше договоритесь о новой встрече и составьте к ней новый список вопросов. Такой стиль концентрированного взаимодействия очень эффективен, потому что: (1) цикл автор/читатель позволяет разрешать небольшие проблемы без дополнительных обсуждений, (2) ваша беседа будет короткой и насыщенной благодаря заранее подготовленному перечню вопросов.

Блоки имеют доминирование

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

Рис 2-1 Типичная SADT-диаграмма

другие функции (такая, как определить степень выполнения задания на рис. 2-1).

Наиболее доминирующий блок обычно размещается в верхнем левом углу диаграммы, а наименее доминирующий - в правом нижнем углу. В результате получается "ступенчатая" схема, подобная представленной на рис. 2-1 для блоков 1, 2, 3.

Расположение блоков на странице отражает авторское определение доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные. Чтобы подчеркнуть это, SADT-аналитик может перенумеровать блоки в соответствии с порядком их доминирования. Порядок доминирования может обозначаться цифрой, размещенной в правом нижнем углу каждого прямоугольника: 1 будет указывать на наибольшее доминирование, 2 - на следующее после наибольшего, и т.д. На рис. 2-1 показано, что блок определить степень выполнения задания влияет на все остальные шаги по обработке детали через следующий шаг задания и поэтому этот блок пронумерован единицей. Поскольку блок подготовить рабочее место должен быть перед блоком обработать на станке и собрать, этим блокам присвоены номера 3 и 4.

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

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

Блоки представляют функции

Функциональные блоки на диаграммах изображаются прямоугольниками. Блок представляет функцию или активную часть системы, поэтому названиями блоков служат глаголы или глагольные обороты. Например, названиями блоков диаграммы выполнить задание являются: определить степень выполнения задания, выбрать инструменты, подготовить рабочее место, обработать на станке и собрать, как показано на рис. 2-1.

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

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

Часть II Создание функциональных моделей и диаграмм

Часть II Создание функциональных моделей и диаграмм

Оглавление

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

В главе 7 обсуждаются навыки, которыми надо обладать, чтобы получить у экспертов информацию, необходимую для создания модели. В главе 8 описан этап анализа, на котором делают первую попытку создать модель. Глава 9 посвящена второму этапу анализа, на котором декомпозируется часть модели, созданной в главе 8. В главе 10 показано, как оценить собственную работу, прежде чем послать ее на рецензирование. В главе 11 приведен основной набор стандартных графических обозначений для упрощения SADT-диаграмм. В процессе изложения материала в этих главах обсуждаются способы опроса и методы анализа и синтеза. Модель экспериментального механического цеха используется для иллюстрации синтаксических правил диаграмм и моделей, процесса создания диаграмм и построения моделей. Таким образом, последовательно изучив материал этих глав, вы получите представление о том, как мыслит системный аналитик в процессе создания модели системы по методологии SADT.

Оглавление

Часть III Рецензирование диаграмм и моделей

Часть III Рецензирование диаграмм и моделей

Оглавление

В этой части книги описано,

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

Основные этапы цикла автор/читатель изложены в пяти главах. В главе 12 дан общий обзор процесса рецензирования. В главе 13 приведено определение SADT-папки и описаны методы ее формирования. В главе 14 показано как нужно читать папки, что необходимо делать всем, кто работает над SADT-проектом. В главе 15 показано, как должен читатель записывать свои замечания, пожелания и сообщения, возникающие в процессе чтения материалов папки. В главе 16 обсуждаются ответы автора на замечания рецензентов и их обобщения. На протяжении этих глав полностью прослеживается цикл автор/читатель на примере папки, содержащей некоторую часть материалов модели экспериментального механического цеха. В процессе изложения иллюстрируется: (1) как на титульном листе папки отмечается ее продвижение по циклу автор/читатель, (2) как читатель изучает папку, (3) как читатель записывает в ней комментарии, (4) как автор письменно отвечает на комментарии читателей. Проследив этот цикл, вы получите четкое представление о том, какие нужны специалисты для участия в нем, а также о методах и процедурах для быстрого получения полезных рецензий на документы папки.

Оглавление

Часть IV Завершение моделирования Руководство моделированием

Оглавление

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

В главе 17 приведен набор эвристик, которыми пользуются опытные SADT-авторы для определения достижения полноты модели и момента окончания моделирования. В главе 18 показано, как можно дополнить модель определением технических терминов, письменными материалами и рисунками. В главе 19 рассматривается техника сопровождения SADT-диаграмм примечаниями, которые позволяют уточнить количественные и качественные характеристики описываемой системы. В главе 20 дается обзор типичного процесса выполнения SADT-проекта. В главе 21 обсуждаются возможности доступных в настоящее время средств автоматизации проектирования в SADT и приводятся примеры их применения.

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

Оглавление

Часть V Создание функциональной модели

Часть V Создание функциональной модели и спецификации. Уроки

Оглавление

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

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

Модель "Питание семьи"

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


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

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

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

Рекомендации для преподавателей

Изложенный ниже материал предназначен для преподавателей, желающих примерно за 5 дней обучить SADT класс, состоящий не более чем из 20 учащихся.


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

глава 22. уроки 1-7

Все семь уроков проработайте со всем классом. Ходите по аудитории и настойчиво добивайтесь по возможности участия в работе каждого учащегося. Записывайте примечания, составляйте списки и делайте наброски диаграмм у всех на виду, чтобы класс мог следить за развитием идей. Вы, как главный автор, разрешайте все конфликты, касающиеся содержания диаграмм и интерпретации терминологии. Потратьте время на очень аккуратное построение диаграмм А-0 и АО из урока 7, поскольку они де-факто станут образцом до конца курса обучения. При построении диаграмм используйте самую простую графику и наиболее нужные, но краткие названия. Избегайте соединительных линий между дугами и их метками,

глава 23. уроки 8-10

Эти уроки выполняются группами. Разделите класс на 3-6 групп, по одной на каждый блок диаграммы АО. Попытайтесь сбалансировать состав каждой группы по уровню подготовке учащихся. Постарайтесь, чтобы в каждый группе был хотя бы один опытный участник и один начинающий. Затем выделите каждой группе по одному блоку диаграммы. Учащиеся сами должны решать проблемы организации работы и распределения обязанностей (например, кто будет записывать, а кто - руководить). Постарайтесь привлечь к участию каждого. Напомните, что целью каждой группы, являются построение диаграммы, затем ее критическая оценка, и, наконец, создание папки. Во время занятий не надо обмениваться информацией с другими группами. Время обмена результатами наступит позже.

глава 24. уроки 11-14

Эти уроки выполняют те 3-6 групп, которые создавали декомпозицию первого уровня. Напомните, что наступило время обмена информацией. Ограничьте диалоги между группами. Для усиления дискуссии в некоторый момент вы можете обсудить с классом диаграмму АО.


Укажите, что группы должны совместно улучшать диаграммы АО. Следите, чтобы ни одна из групп не давала ненужных заданий другой группе. Будьте главным арбитром при решении интерфейсных проблем.

глава 25. уроки 15-17

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

глава 26. уроки 18-21

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

глава 27. уроки 22-25

Проработайте урок 22 всем классом. Урок 23 группы выполнят самостоятельно. Урок 24 учащиеся должны выполнить индивидуально. Текст к уроку 25 учащиеся пишут индивидуально на основе своих диаграмм Ахх. Если будет время, группы могут составить текст для своих диаграмм Ах, а преподаватель написать текст для диаграмм А-0 и АО, а также оформить титульный лист спецификации. Напомните классу, что его целью является составление единого спецификационного документа, отражающего коллективные усилия на протяжении курса обучения. После завершения курса размножьте этот документ и разошлите его всем. Это поможет каждому запомнить изученное, в особенности соотношение между индивидуальной работой и работой в группе.

Оглавление

Чтение и ответы на замечания

Вначале бегло просмотрите папку, отмечая замечания и фиксируя их количество. Вы получите представление о тех частях папки, которые в общем не вызывают сомнения, и о тех, к которым много претензий. Кроме того, посмотрите, сколько времени затратил читатель. Это позволитвам оценить, насколько трудно было комментировать папку. Продолжительность своей работы тоже отметьте на титульном листе. Просмотрев все замечания, вернитесь назад и ответьте на каждое из них. Старайтесь понять, что хотел сказать читатель. Сделайте вывод. Если вы согласны, поставьте галочку, если нет, поставьте крестик. Например, на диаграмме ЭМЦ/А2 (рис. 16-2) автор обозначил согласие с замечаниями 1-5 и несогласие - с замечанием 6.

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

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

Рис. 16-1. Титульный лист и родительская диаграмма с ответами автора

Рис. 16-2. Диаграмма и дополнительный материал с ответами автора

Что нужно помнить при опросе

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

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

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

Цикл автор/читатель

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

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

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

Декомпозиция ограниченного объекта

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

Шаги 1-3 представляют созидательную часть процесса. Выполняя их, аналитик концентрирует свои усилия, связанные с выявлением новой информации об объекте, на более высоком уровне детализации, чтобы достичь ясности изложения. Шаги 4-7 составляют этап саморецензирования, в ходе которого аналитик, создав новую диаграмму, проверяет, какую она несет информацию и в каком она находится отношении с родительской диаграммой. Затем в созданную диаграмму и соответственно в связанные с ней диаграммы вносятся изменения, чтобы достичь ясности для других. В этой главе мы подробнее рассмотрим шаги 1-3. Шаги, связанные с саморецензированием и последующими изменениями, обсуждаются в главе 10.

9.1.1. Выбор блока

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

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

9.1.2. Объект, определяемый блоком

Блок 2, выполнить задание, становится теперь самостоятельным объектом декомпозиции. Для выполнения этой декомпозиции вначале бегло осмотрим обобщающую диаграмму (посмотрите, пожалуйста, диаграмму А-0 на рис. 8-4) и вспомним цель и точку зрения модели. Сделав это, мы увидим, что должны описать блок выполнить задание с точки зрения начальника цеха, чтобы можно было разработать инструкции для обучения нового персонала цеха. Кроме того, мы изучим блок 2 диаграммы АО и соединенные с ним дуги, чтобы выявить его особенности. Например, дуга механизма с названием рабочий указывает, что мы можем, декомпозировав этот блок, выявить, чем занимаются рабочие.

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


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

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

9.1.3. Создание новой диаграммы

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

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


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

Рис. 9-1. Диаграмма АО готова к декомпозиции

Рис. 9-2. Предварительные наброски для декомпозиции функционального блока

Декомпозиция в ходе моделирования

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

Следуя правилам SADT, автор производит вначале анализ и синтез системных объектов, записывая, как именно подверглись разбиению объекты, входящие в ограниченный объект. На рис. 6-5 показано, что список данных начинается со всех граничных дуг и их ICOM-кодов, а заканчивается их составляющими. Затем автор просматривает список данных и, возможно, объединяет эти составляющие, чтобы выделить те объекты, которые будут выступать в качестве управляющих.

Затем автор выполняет подобный анализ и синтез функций системы, но делает это в соответствии со списком данных. В процессе свободного объединения и введения новых управляющих дуг создается список функций для дальнейшей детализации. Например, указания и чертеж заставляют автора подумать о функциях выбрать инструменты и подготовить рабочее место. Функции вносятся в список до тех пор, пока поток идей не иссякнет. Затем эти функциональные части объединяются в разумные (сбалансированные) наборы из 3-6 блоков. (Важно заметить, что применение правила "от трех до шести блоков" вынуждает автора использовать абстракцию и декомпозицию для постепенного представления деталей системы.) После определения функциональных частей список данных и список функций используются для чернового варианта диаграммы. Снова выполняются анализ и синтез, в результате чего формируются наборы объектов, которые представляются дугами, соединяющими блоки.

Такая последовательность выполнения декомпозиции имеет большое значение, поскольку

Рис. 6-4. Терминология, связанная с изготовлением нестандартных деталей

Рис. 6-5. Пример анализа и синтеза в процессе декомпозиции

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

Правило "от трех до шести" блоков на одной диаграмме - тоже уникальная особенность SADT. Хорошо известно, что мощность краткосрочной памяти человека ограничена восприятием примерно семи категорий, каждая из которых может содержать около семи отдельных единиц информации. SADT придерживается консервативной точки зрения, разрешая в качестве верхнего предела шесть блоков - по одному на категорию. Имя блока и его граничные дуги представляют собой единицы информации, помещаемые в категории в процессе чтения диаграммы. Таким образом, SADT-диаграммы создаются так, чтобы не подвергать испытанию пределы краткосрочной памяти человека. Однако способности к запоминанию у различных людей различны. Наш опыт показывает, что диаграммы из 4-5 блоков с не более чем пятью дугами, касающимися каждого блока, приближаются к оптимальным по объему информации, которые можно быстро донести до широкой аудитории.

Диаграммы содержат блоки и дуги

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

Документирование полученных знаний

Создание модели (блок 2 на рис. 4-1) - это второй важный этап в процессе моделирования, на котором аналитик документирует полученные им знания о данной проблемной области, представляя их в виде одной или нескольких SADT-диаграмм. Процесс создания модели осуществля-

Рис. 4-1. Процесс создания SADT-модели

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

Дополнения к диаграммам и моделям

 

Глава 18. Дополнения к диаграммам и моделям

Оглавление

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

18.1. Дополнения к диаграммам

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

SADT-диаграммы могут быть дополнены информацией в виде текстов, рисунков и глоссариев. Текст обычно представляет собой рассказ об одной из частей диаграммы. Рисунки - это картинки, поясняющие отдельные моменты. Глоссарий - набор определений объектов и функций, представленных на диаграмме. Чтобы показать, как SADT-аналитики дополняют диаграмму, мы напишем текст, составим глоссарий и сделаем рисунок для диаграммы подготовить рабочее место модели экспериментального механического цеха, приведенной на рис. 18-1.
Мы выбрали в качестве образца диаграмму, находящуюся на самом нижнем уровне модели экспериментального механического цеха, хотя дополнения обычно приводятся для всех диаграмм модели. Дополнительная информация записывается или представляется на стандартных SADT-бланках. Поскольку дополнения уточняют конкретную диаграмму модели, для идентификации и связывания дополнительной страницы с диаграммой, к которой она относится, используется принятая в SADT схема нумерации узлов. К номеру узла диаграммы добавляется буква и целое число. Буква определяет тип дополнения (Т - текст, Р -рисунок и Г - глоссарий), а число означает порядковый номер этой текстовой страницы среди других дополнительных страниц данной диаграммы. Обратите внимание, как номера узлов привязывают страницы с дополнениями на рис. 18-2, 18-3 и 18-4 к диаграмме подготовить рабочее место. 18.2. Определение терминологии с помощью глоссария Глоссарий используется для того, чтобы собрать вместе и определить новые понятия, которые вводятся диаграммой, декомпозирующей блок, особенно если это первая декомпозиция родительского блока. Для функциональных SADT-диаграмм такими понятиями могут быть либо новые функции, либо новые объекты, представляемые дугами, либо декомпозиция внешних дуг. На рис. 18-2 представлена страница глоссария, который определяет некоторые из новых объектов, введенных на диаграмме подготовить Рис. 18-1. Диаграмма, которую необходимо дополнить глоссарием, текстом и рисунками Рис. 18-2 Глоссарий новых терминов рабочее место. Например, дуга выбранный станок проходит только между блоками диаграммы выбрать станок и наладить станок и ранее в модели экспериментального механического цеха не появлялась, поэтому выбранный станок рассматривается как новое понятие и, следовательно, требует определения. 18.3. Пояснение содержания с помощью текста Текстовые страницы, дополняющие диаграммы, пишут обычно для того, чтобы изложить основное содержание диаграммы, помочь согласовать ориентацию читателя с ориентацией автора и описать, как функции самого нижнего уровня модели преобразуют свои входы в выходы под влиянием управлений.


Текст помогает читателям изучать диаграмму в том порядке, который уменьшает вероятность неправильного понимания и уточняет детали системы. Например, на рис. 18-3 текст описывает последовательность действий, выполняемых при подготовке рабочего места. Этот текст находится на уровне детализации, достаточном для рассмотрения его в качестве учебного руководства для персонала механического цеха. Подготовка хорошего текста требует времени, даже если текст относится к одному блоку. Поэтому обычно текст пишется, когда диаграмма перестает подвергаться изменениям. Иногда текст используется для уточнения важных моментов в процессе создания диаграммы. Мы настоятельно рекомендуем по мере возможности использовать графику и цикл автор/читатель, чтобы избавиться от неясностей и построить диаграмму точно описывающую реальность. После этого вы сможете без труда обобщить или уточнить диаграмму при помощи хорошо организованного и насыщенного фактами текста. Например, если бы мы написали текст сразу после первого наброска диаграммы выполнить задание, представленного на рис. 9-2, нам пришлось бы его несколько раз переписывать, потому что, как показано в части III, диаграмма подверглась существенным изменениям в результате рецензирования. Хороший текст должен быть кратким. Несколько тщательно подобранных слов могут прояснить диаграмму, в то время, как избыточное их количество может совершенно затуманить ее смысл. Обычно все, что нужно для пояснения диаграммы, можно изложить на одной странице текста. Превышение одной страницы снижает качество за счет лишних деталей. Например, текст на рис. 18-3 поясняет, как оператор готовит станок и место вокруг него. Обратите внимание, что текст не затрагивает дополнительных (например, правил безопасности) и исключительных ситуации (например, отсутствия контейнеров для отходов). При таких обстоятельствах разумнее написать отдельные страницы текста, с пояснением как важных, так и второстепенных вопросов, а также с описанием экстремальных ситуаций и путей выхода из них. Текст может быть использован для объяснения, почему выбрана именно эта декомпозиция или точка зрения, для сообщения о том, как осуществляются сложные операции, или для описания допущений, сделанных автором при создании диаграммы.


Однако ни при каких обстоятельствах текст не должен описывать то, что можно прочесть на диаграмме, уточнять уже декомпозированный блок, идентифицировать компоненты декомпозированной дуги, описывать функции блоков или определять названия блоков и дуг (эти названия содержатся на странице глоссария). Следуйте этим рекомендациям и ваши текстовые дополнения будут всегда краткими, четкими, информативными и, самое важное, они будут прочитаны. Рис. 18-3 Подготовка рабочего места
 
  18.4. Пояснение с помощью рисунков Хотя для определения терминологии и изложения содержания используются текстовые описания, слова следует употреблять экономно. Мы советуем для пояснения тонких моментов и того, что трудно выразить словами, использовать, где это возможно, и рисунки. В SADT любое изображение, которое не является строго диаграммой, считается дополнительным рисунком. SADT-рисунки - это обычно либо картинки, либо диаграммы с дополнительными изображениями, связанные с конкретной диаграммой модели. Связь указывается с помощью добавления к номеру узла поясняемой диаграммы буквы Р и порядкового номера, как показано на рис. 18-4. Рисунок-дополнение - это любое изображение, сделанное для дополнения модели. Рисунки часто служат для того, чтобы показать, как выглядит конкретная часть системы (например, станок, готовый к работе), как соединяются две части системы (например, как зажимают в тисках заготовку перед началом обработки), как правильно использовать часть системы, (например, как обрабатывать алюминий на токарном станке). Рисунки также могут отражать конкретное событие в процессе работы системы (например, пуск станка) или развитие событий во вре- Рис. 18-4. Рисунок, показывающий, что представляет собой дуга СТАНОК, ГОТОВЫЙ К РАБОТЕ мени (например, график поступления заданий). На рис. 18-4 показано, как выглядит типичное готовое рабочее место. Хорошие картинки незаменимы, но их нужно долго рисовать. Автор всегда должен иметь под рукой достаточный запас картинок, готовых к использованию - диаграммы самой SADT-модели.


SADT- авторы обычно выделяют некоторые фрагменты изображения на нескольких диаграммах модели, чтобы подчеркнуть отдельные важные моменты. Диаграмма с дополнительной графикой может уточнить какие-либо детали, показывая различные группы дуг, описывая варианты действия блока или функционирование системы при изменяющейся окружающей среде, показывая основной поток данных, детализируя роли обратных связей, описывая принципиально неверные ситуации и случаи ошибочной трактовки или просто документируя важные изменения в диаграмме. На рис. 18-5 выделены преобразования, которые происходят с оборудованием (т.е. станками и инструментами), при превращении их в оборудованное рабочее место. Сравните это с текстовым описанием подготовки рабочего места, приведенным на рис. 18-3. Для выделения каких-либо частей диаграммы чаще всего используют жирные линии. Мы, однако, при любой возможности пользуемся цветом. Цвет может отразить в диаграмме еще одну важную характеристику информации - разделение ее по типам. Попробуйте раскрасить дуги диаграммы подготовить рабочее место следующим образом: планы изобразите красным, оборудование - синим, остальную информацию -зеленым. Обратите внимание, как цвет по-новому осветил диаграмму, разбив представленные дугами объекты на типы. Раскрасив таким образом всю модель, можно описать влияние определенных данных на функции системы (например, на каких этапах нужен чертеж), а также указать те функции, которым необходим определенный тип данных (например, на каких этапах обрабатываются заготовки). Цвет - не универсальное, но очень эффективное средство, когда имеется не более 10 категорий. Учтите, что хотя типичные SADT-рисунки - это картинки или диаграммы с SADT - графикой, в принципе для создания рисунка можно воспользоваться любым языком. Мы, например, использовали языки таблиц решений и конечных автоматов для уточнения SADT-моделей систем телефонной коммуникации и графики системы PERT для преобразования SADT-модели, открывающей процесс планирования, в формат, понятный менеджерам очень большого правительственного проекта.


Поэтому мы рекомендуем использовать все доступные вам изобразительные средства для дополнения SADT-моделей. 18.5. Дополнение моделей Иерархические наборы SADT-диаграмм, называемые "моделями", вводят объект описания и уточняют его регулярным, управляемым и понятным образом. Это обеспечивается тем, что диаграммы модели всегда организованы в соответствии с порядком нумерации узлов. Это означает, что первым идет узел А-0, вторым - узел АО, третьим - узел А1, четвертым - узел All и т. д. Такой порядок расположения SADT-диаграмм является копией "древовидной" структуры, часто встречающейся в математике и информатике. Полная SADT-модель обычно читается двумя способами. Первый способ - обзорное чтение, когда читаются все диаграммы верхнего уровня, прежде чем перейти к диаграммам следующего. Это называется чтением "в ширину". Второй способ -детальное чтение, когда читают отдельную ветвь дерева вплоть до диаграмм самого нижнего уровня. Это называется чтением "в глубину". Чтобы помочь читателям правильно двигаться по древовидному набору диаграмм, разработаны дополнительные средства. Примерами таких средств могут служить указатель диаграмм и указатель узлов. Они представляют собой составленные с отступами списки узлов или диаграмм ( по типу оглавления) , определяющих содержание модели. В указателе диаграмм перечисляются все диаграммы модели с приведенными в отдельной строке названием и номером узла каждой диаграммы. В указателе узлов перечисляются все блоки модели, причем в каждой отдельной строке записываются название и номер узла соответствующего блока. Таким образом, указатель узлов является просто более подробным, чем указатель диаграмм, списком. Указатели диаграмм для моделей обсуждаются в части VI. Обратите внимание на то, что оглавления (таблицы содержаний) служат как кратким конспектом системы, так и средством быстрого поиска при рассмотрении конкретного функционального фрагмента системы. Рис. 18-5. На диаграмме показан основной путь 18.6.


Резюме SADT-диаграммы иногда нуждаются в дополнительной информации для описания подробностей, важных для понимания систем. В SADT применяются три типа дополнений к диаграммам: глоссарии, тексты и рисунки. Страницы глоссария содержат определения и часто структурное описание данных системы. Страницы глоссария используются для составления словаря данных модели. Текстовые страницы излагают содержание диаграмм, что часто имеет большое значение при детализации диаграмм самого нижнего уровня модели. Страницы рисунков содержат иллюстрации, поясняющие важные аспекты системы (например, законченную часть, область хранения, карту). Хотя дополнения в определенных ситуациях могут быть очень полезны, мы настоятельно рекомендуем никогда не использовать их вместо диаграмм для декомпозиции модели. Они должны только обеспечивать соответствие диаграмм цели модели. Указатели диаграмм и указатели узлов - это списки (оглавления) с отступами, которые играют роль как краткого конспекта системы, так и средства быстрого поиска при рассмотрении конкретной функциональной области системы. Дополнительная литература Berlin, J.: Semiology of Graphics, University of Wisconsin Press, Madison, 1983. DeMarco, Т.: Structured Analysis and System Specification, Yourdon Press, New York, 1978. Hurley, R.: Decision Tables in Software Engineering, Van Nostrand Reinhold, New York, 1983. Lannon, J.: Technical Writing, Little, Brown, Boston, 1982. Marca, D.: Applying Software Engineering Principles, Little Brown, Boston, 1984. Martin, J., and McClure, C.: Diagramming Techniques for Analysts and Programmers, Prentice-Hall, Englewood Cliffs, N.J., 1985. Weinberg, G.: Rethinking Systems Analysis and Design, Little Brown, Boston, 1982.
 

Оглавление

Дополнительная литература

Brackett, J., and C. McGowan: "Applying SADT to Large System Problems", SofTech Technical Paper TP059,January 1977.

Connor, M.: "Structured Analysis and Design Technique - SADT", Auerbach portfolio 32-04-02, 1979.

Freeman, P.: "Requirements Analysis and Specification: The First Step", Advances in Computer Technology - 1980, August 1980.

Hori, S.: "Human-Directed Activity Cell Model", CAM-1 Long Range Planning Final Report, CAM-1, Inc., 1972.

Miller, J.: Living Systems, McGraw-Hill, New York, 1978.

Ross, D.: "PLEX1: Sameness and the Need for Rigor", SofTech Deliverable no. 9031-1.1, December 1975.

Ross, D.: "PLEX2: Sameness and Type", SofTech Deliverable no. 9031-2.0, December 1975.

Ross, D.: "Reflections on Requirements", IEEE Transactions on Software Engineering, vol. SE-3, no. 1,January 1977.

Ross, D.: "Doug Ross Talks about Structured Analysis", IEEE Computer, July 1985.

Ross, D. and K. Schoman: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January 1977.

SofTech, Inc.: "Introduction to IDEFO", SofTech Deliverable no. 7500-14, September 1979.

Weinberg, G.: An Introduction to General Systems Thinking, John Wiley, New York, 1975.

Connor, M.: "Structured Analysis and Design Technique - SADT", Auerbach portfolio 32-04-02, 1979.

Ross, D., and Bracket, J.: "An Approach to Structured Analysis", Computer Decisons, September 1976.

Ross, D.: "Structured Analysis (SA): A Language for Communicating Ideas", IEEE Transactions on Software Engineering, vol. 3, no. 1, January 1977. Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January 1977.

SofTech, Inc.: "IDEFO Author's Guide to Creating Activity Diagrams", SofTech Deliverable no. 7500-13, September 1979.

SofTech, Inc.: "Integrated Computer-Aided Manufacturing (ICAM) Report: Function Modeling Manual (IDEFO)", contract no. F33612-78-C-5158, SofTech, Inc., 1981.

Оглавление

Mihram, A.: "The Modeling Process", IEEE Transactions on Systems, Man and Cybernetics, vol. 2, no. 5, November 1972.

Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January 1977.

SofTech, Inc.: "Introduction to IDEFO", SofTech Deliverable no. 7500-14, September 1979.

SofTech, Inc.: "Integrated Computer-Aided Manufacturing (ICAM) Report: Function Modeling Manual (IDEFO)", contract no. F33612-78-C-5158, SofTech, Inc., 1981

Оглавление

Ross, D.: "Removing the Limitations of Natural Language (with Principles behind the RSA Language)", SofTech Deliverable no. 9061-25, July 1979.

SofTech, Inc.: "IDEFO Author's Guide to Creating Activity Diagrams", SofTech Deliverable no. 7500-13, September 1979.

SofTech, Inc.: "Introduction to IDEFO", SofTech Deliverable no. 7500-14, September 1979.

SofTech, Inc.: "Integrated Computer-Aided Manufacturing (ICAM) Report: Function Modeling Manual (IDEFO)", contract no. F33612-78-C-5158, SofTech,Inc., 1981.

Оглавление

Miller, J.: Living Systems, McGraw-HiIl, New York, 1978.

Ross, D.: "An Essay on Activity Diagramming", SofTech Technical Report no. 7104, November, 1976.

SofTech, Inc.: "IDEFO Author's Guide to Creating Activity Diagrams", SofTech Deliverable no. 7500-13, September 1979.

SofTech, Inc.: "Integrated Computer-Aided Manufacturing (ICAM) Report: Function Modeling Manual (IDEFO)", contract no. F33612-73-C-5158, SofTech, Inc., 1981.

Оглавление

Alexander, С.: Notes on the Synthesis of form, Harvard University Press, Cambridge, Mass., 1964.

Jackson, M.: System Development, Prentice-Hall, Englewood Cliffs, N.J., 1983.

Orr, K.: Structured Systems Development, Yourdon Press, New York, 1977.

Miller, G.: "The magical Number Seven, Plus Or Minus Two: Some Limits on Our Capacity for Information Processing", The Psychology Review, vol. 63, no. 2, March 1956.

Marca, D., and McGowan, C.: "Static and Dynamic Data Modeling for Information System Design", 6th International Conference on Software engineering Proceedings, September 1982.

Parnas, D.: "On the Criteria to be Used in Decomposing Systems into Modules", CACM, December 1972.

Pirsig, R.: Zen and the Art of Motorcycle Maintenance, Bantam Books, New York, 1974.

Ross, D.: "An Essay on Activity Diagramming", SofTech Technical Report no. 7104, November, 1976.

SofTech, Inc.: "IDEFO Author's Guide to Creating Activity Diagrams", SofTech Deliverable no. 7500-13, September 1979.

SofTech, Inc.: "Integrated Computer-Aided Manufacturing (ICAM) Report: Function Modeling Manual (IDEFO)", contract no. F33612-78-C-5158, SofTech, Inc., 1981.

Оглавление

Bravoco, R.: "Supplementary Information Concerning Interview Standards and Techniques", SofTech, June 1976.

FitzGerald, J., and A. Fitz Gerald: Fundamentals of Systems Analysis, John Wiley, New york, 1973.

Freeman, P.: "Why Johnny Can't Analyze", Systems Analysis and Design: A Foundation for the 1980s Workshop Proceedings, September 1980.

Gorden, R.: Interviewing: Strategy, Techniques and Tactics, Dorsey Press, 1980.

Hartman, Matthes, and Proeme: Management Information Systems Handbook, McGraw-Hill, New York, 1968.

Kahn and Cannel: The Dynamics of Interviewing Theory, Techniques and Cases, John Wiley, New York, 1966.

Mumford, E.: Designing Human Systems for New Technology, Manchester Business School, Manchester, England, 1983.

Parkin, A.: Systems Analysis, Little Brown, Boston, 1980.

SofTech, Inc.: "Practical Aspects Of Data Collection, IDEFO Architects Guide", SofTech Deliverable no. 7500-10, September 1979.

Weinberg, G.: Rethinking Systems Analysis and Design. Little Brown, Boston, 1982.

Оглавление

DeMarco, Т.: Structured Analysis and System Specification, Yourdon Press, New york, 1978.

DeMarco, Т.: "Specification modeling", Guide50 Proceedings, 1980.

Greenspan, S., and J. Mylopoulos: "Capturing More World Knowledge in the Requirements Specification", 6th International Conference on Software Engineering Proceedings, September 1982

Jackson, M.: System Development, Prentice-Hall, Englewood Cliffs, N.J., 1983.

Marca, D.: Applying Software Engineering Principles, Little Brown, Boston, 1984.

Orr, K.: Structured Systems Development, Yourdon Press, New York, 1977.

Ross D.: "Some Further Observations about Structured Analysis", SofTech Technical Report no. 9031-6, January 1976

Ross, D.: "An Essay on Activity Diagramming", SofTech Technical Report no. 7104, November, 1976.

Rubinsteine, M.: Patterns of Problem Solving, Prentice-Hall, Englewood Cliffs, N.J., 1975.

SofTech, Inc.: "IDEFO Author's Guide to Creating Activity Diagrams", SofTech Deliverable no. 7500-13, September 1979.

SofTech, Inc.: "Integrated Computer-Aided Manufacturing (ICAM) Final Report: Function Modeling Manual (IDEFO)", contract no. F33612-78-C-5158, SofTech, Inc., 1981.

Weinberg, G.: Rethinking Systems Analysis and Design, Little Brown, Boston, 1982.

Оглавление

Alexander, С.: Notes on the Synthesis of form, Harvard University Press, Cambridge, Mass., 1964.

Miller, G.: "The magical Number Seven, Plus Or Minus Two: Some Limits on Our Capacity for Information Processing", Tbe Psychology Review, vol. 63, no. 2, March 1956.

Parnas, D.: "On the Criteria to be Used in Decomposing Systems into Modules", CACM, December 1972.

Ross, D.: "An Essay on Activity Diagramming", SofTech Technical Report no. 7104, November, 1976.

Ross, D.: "Principles of Structuring", SofTech Technical Paper no. 082, November 1978.

Rubinsteine, M.: Patterns of Problem Solving, Prentice-Hall, Englewood Cliffs, N.J., 1975.

SofTech, Inc.: "IDEFO Author's Guide to Creating Activity Diagrams", SofTech Deliverable no. 7500-13, September 1979.

SofTech, Inc.: "Integrated Computer-Aided Manufacturing (ICAM) Report: Function Modeling Manual (IDEFO)", contract no. F33612-78-C-5158, SofTech,Inc., 1981.

Thomas, M.: Functional Decomposition: SADT", InfoTech State of the Art Repotr on Structured Analysis and Design, 1978.

Оглавление

Cohen, G.: "A New Way to Test Writing", 22nd International Technical Communications Conference, 1975.

Elbow, P.: Writing with Power, Oxford University Press, Oxford, England, 1982.

Freedman, D., and G. Weinberg: "Walkthroughs, Inspections, and Technical Reviews", Little Brown, Boston, 1982.

Freedman, D., and G. Weinberg: "Reviews, Walkthroughs, and Inspections", IEEE Transactions on Software Engineering, vol. 10, no. 1, January 1984.

Hale, R.: "Inspections in Application Development - Introduction and Implementation Guidelines", IBM Report TNL GN20-3814, August 1978.

IBM: "Code Reading, Structured Walkthroughs, and Inspections", IBM Report GE-19-5200, 1976.

Kohli, R.: "High Level Design Inspection Specification", IBM Report TR21.601, July 1975.

Lannon, J.: Technical Writing, Little, Brown, Boston, 1982.

Yourdon, E.: Structured Walkthroughs, Yourdon Press, New York, 1977.

Оглавление

Cohen, G.: "A New Way to Test Writing", 22nd International Technical Communications Conference, 1975.

Elbow, P.: Writing with Power, Oxford University Press, Oxford, England, 1982.

Freedman, D., and Weinberg, G.: "Walkthroughs, Inspections, and Technical Reviews", Little Brown, Boston, 1982.

Freedman, D., and Weinberg, G.: "Reviews, Walkthroughs, and Inspections", IEEE Transactions on Software Engineering, vol. 10, no. 1, January 1984.

Hale, R.: "Inspections in Application Development - Introduction and Implementation Guidelines", IBM Report TNL GN20-3814, August 1978.

IBM: "Code Reading, Structured Walkthroughs, and Inspections", IBM Report GE-19-5200, 1976.

Kohli, R.: "High Level Design Inspection Specification", IBM Report TR21.601, July 1975.

Lannon, J.: Technical Writing, Little, Brown, Boston, 1982.

Yourdon, E.: Structured Walkthroughs, Yourdon Press, New York, 1977.

Оглавление

Connor, M.: "Structured Analysis and Design Technique - SADT", Auerbach portfolio 32-04-02, 1979.

King, L: "Guidelines for an SADT Chief Author", SofTech Deliverable no. 9595-2, 1980.

Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January 1977.

SofTech, Inc.: "IDEFO Forms and Procedures Guide", SofTech Deliverable no. 7500-11, September 1979.

Оглавление

Curtis, В. (ed): "Human Factors in Software Development", IEEE Catalog no. EHO 185-9, IEEE Computer Society, 1981.

Connor, M.: "Structured Analysis and Design Technique - SADT", Auerbach portfolio 32-04-02, 1979.

Freedman, D., and Weinberg, G.: "Walkthroughs, Inspections, and Technical Reviews", Little Brown, Boston, 1982.

Kemmer, R.: "Testing Formal Specifications to Detect Design Errors", IEEE Transactions on Software Engineering, vol. 11, no. 1, January, 1985.

Mihram, A.: "The Modeling Process", IEEE Transactions on Systems, Man and Cybernetics, vol. 2, no. 5, November 1972.

Mumford, E.: Designing Human Systems for New Technology, Manchester Business School, MAnchester, England, 1983.

Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software engineering, vol. SE-3, no. 1, January 1977.

SofTech, Inc.: "IDEFO Forms and Procedures Guide", SofTech Deliverable no. 7500-11, September 1979.

Weinberg, G.: The Psychology of Computer Programming, Van Nostrand Reinhold, New York, 1971.

Yourdon, E.: Structured Walkthroughs, Yourdon Press, New York, 1978.

Оглавление

Elbow, P.: Writing with Power, Oxford University Press, Oxford, England, 1982.

Freedman, D., and Weinberg, G.: "Reviews, Walkthroughs, and Inspections", IEEE Transactions on Software Engineering, vol. 10, no. 1, January 1984.

Freedman, D., and Weinberg, G.: "Walkthroughs, Inspections, and Technical Reviews", Little Brown, Boston, 1982.

Macnamara, J.: Names of Things, MIT Press, Cambridge, Mass., 1982.

0 Rourke, J.: "Writing for the Reader", DEC, 1976.

SofTech, Inc.: "IDEFO Forms and Procedures Guide", SofTech Deliverable no. 7500-11, September 1979.

Оглавление

Freedman, D., and Weinberg, G/ : "Walkthroughs, Inspections, and Technical Reviews", Little Brown, Boston, 1982.

MacKay, D.: Information, Mecanism and Meaning, MIT Press, Cambridge, Mass., 1969.

Macnamara, J.: Names of Things, MIT Press, Cambridge, Mass., 1982.

0 Rourke, J.: "Writing for the Reader", DEC, 1976.

SofTech, Inc.: "IDEFO Forms and Procedures Guide", SofTech Deliverable no. 7500-11, September 1979.

Оглавление

Elbow, P.: Writing with Power, Oxford University Press, Oxford, England, 1982.

Lannon, J.: Technical Writing, Little, Brown, Boston, 1982.

Macnamara, J.: Names of Things, MIT Press, Cambridge, Mass., 1982.

Minsky, M.: "Form and Content in Computer Science", CACM, vol. 17, no. 2, April 1970.

O'Rourke, J.: "Writing for the Reader", DEC, 1976.

Freedman, D., and Weinberg, G.: "Reviews, Walkthroughs, and Inspections", IEEE Transactions on Software Engineering, vol. 10, no. 1, January 1984.

Weinberg, G.: Rethinking Systems Analysis and Design, Little Brown, Boston, 1982.

Weinberg, G.: Understanding the Professional Programmer, Little Brown, Boston, 1982.

Weizenbaum, J.: Computer Power and Human Rreason, W.H. Freeman, 1976.

Оглавление

Alexander, С.: Notes on the Synthesis of Form, Harvard University Press, Cambridge, Mass., 1964.

Connor, M.: "Structured Analysis and Design Technique - SADT", Auerbach portfolio 32-04-02, 1979.

Doczi, G.: "The Power of Limits", Shambhala Press, 1981.

Mihram, A.: "The Modeling Process", IEEE Transactions on Systems, Man and Cybernetics, vol. 2, no. 5, November 1972.

Nishio, Т., and Nogi, K.: "A Stepwise Composition TEchnique for User Requirements Definition", International Workshop on Models and Languages for Software Specification and Design, University of Laval, Laval, Canada, March 1984.

Ross, D.: "Principles of Structuring", SofTech Technical Paper no. 082, November 1978.

Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January 1977.

SofTech, Inc.: "IDEFO Author's Guide to Creating Activity Diagrams", SofTech Deliverable no. 7500-13, September 1979.

SofTech, Inc.: "The DWS/CS Emergency Preset Structured Specification", Technical Paper no. 1083-1, August 1981.

Оглавление

Brackett, J.: "Structuring the Analysis and Design Process", GUIDE Productivity Symposium, 1976

Burack, E., and Torda, F.: "The Manager's Guide to Change", Lifetime Learning Publications, 1979.

DeMarco, Т.: "Breaking the Language Barrier", Computerworld, August 1978.

DeMarco, Т.: "Controlling Software Projects, Yourdon Press, New York, 1982.

Parkin, A.: Data Processing Managment, Little, Brown, Boston, 1980.

Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January

1977.

Schoman, K.: "SADT and PERT", SofTech Deliverable no. CLIN#0-02AG, November 1977.

Weinberg, G.: "Understanding the Professional Pregrammer, Little, Brown, Boston, 1982.

Yourdon, E.: "How to Manage Structured Programming", Yourdon Press, New York, 1976.

Оглавление

Достаточная детализированность

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

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

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

Рис. 17-1. Блоки, для которых нет необходимости в дальнейшей декомпозиции.

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

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

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

Дуги имеют различное содержание

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

Дуги изображают объекты

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

Так как в SADT дуги изображают объекты, они описываются (помечаются) существительными или существительными с определениями, располагающимися достаточно близко к линии дуги. Мы настоятельно рекомендуем размещать описания дуг, называемые метками, как можно ближе к линиям дуг, не нарушая, однако, читабельность диаграмм. Это устраняет неопределенность в том, к какой дуге относится метка, и исключается необходимость в дополнительных графических связях (например, в "зигзагах", см. главу 19). Обратите внимание на то, что все метки дуг на диаграмме выполнить задание расположены вплотную к соответствующим дугам. Мы рекомендуем принять этот стиль описания дуг для того, чтобы ваши диаграммы были упорядоченными и простыми для чтения.

Дуги изображают взаимосвязи между блоками

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

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

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

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

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

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


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

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

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

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

Рассмотрим функцию собрать, описанную на рис. 5-3, но с дугой механизма, присоединенной к блоку снизу. Рассмотрим теперь, как может быть выполнен блок собрать, если дуга механизма имеет метку клей. Вы можете представить себе деревянные детали, сначала намазанные клеем, затем состыкованные вместе и высушенные. Если же к блоку собрать присоединена дуга механизма, помеченная словом отвертка, вы можете представить себе детали стула, содержащие винты и обладающие штифтовой схемой соединения, которая требует просто стыковки деталей и затягивания винтов. Сценарии существенно различаются всего лишь из-за изменения единственного слова на дуге механизма. Этот пример показывает, что дуги механизма выявляют средства, необходимые для выполнения функции.

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

Механизмы могут также указывать, что одни функции поддерживают выполнение других функций, поэтому они должны выполняться в требуемой последовательности.
На рис. 5- 4 показано, что блок подготовить рабочее место должен выполняться до блока обработать на станке и собрать, поскольку оборудованное рабочее место должно быть приготовлено до начала работы. В этом случае система требует определенной последовательности операций. На рис. 5-2 в диаграмме управлять выполнением задания исполнительская дуга механизма для блока 1 с меткой стеллаж входных заданий определяет, где искать вновь полученный рабочий комплект. В этом случае аналитик хотел подчеркнуть, что в экспериментальном механическом цехе стеллаж входных заданий важен для выполнения функции получить задание и назначить исполнителя. Все эти примеры свидетельствует о том, что при описании различных аспектов функционирования и реализации систем дуги механизмов имеют важное значение.

Рис. 5-4. Одни функции модели поддерживают выполнение других функций

Дуги могут быть декомпозированы

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

Рассмотрим дуги план выполнения задания и принятое задание на диаграмме рис. 5-1. Из диаграммы видно, что эти дуги представляют совокупности объектов, поскольку каждая из них разветвляется на две отдельные дуги с различными метками. Следуя структуре дуг, можно сказать, что чертеж - часть плана выполнения задания, а принятое задание либо формируется из детали с биркой и штампа "принято", либо является принятым, но незаконченным заданием. Это все, что можно узнать об этих дугах из диаграммы изготовить нестандартную деталь. Однако мы всегда можем посмотреть на декомпозицию блоков этой диаграммы для выяснения дополнительных подробностей содержания этих дуг. Например, на диаграмме выполнить задание (рис. 5-4) мы видим, что станки и инструмен-

Рис 5-1. SADT-диаграмма, содержащая разветвления и дополнения дуг

ты состоят из набора инструментов и станков в цехе.

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

Иногда функция разделяет дугу на ее компоненты точно так же, как призма разлагает свет на цвета. В этом случае для получения дополнительных сведений о содержании компонент и взаимосвязях между ними важно изучить, что выполняет эта функция. На рис. 5-4 дуга план выполнения заданий является дугой управления

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

Дуги могут быть "помещены в тоннель"

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

Рис. 5-2. Туннельные дуги позволяют спрятать¦ некоторые подробности и показать необходимые детали

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

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

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

Дуги представляют наборы объектов

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

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

2.6.1. Разветвление дуг

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

непомеченные ветви содержат все объекты, указанные в метке дуги перед разветвлением (т.е. все объекты принадлежат этим ветвям); ветви, помеченные после точки разветвления, содержат все объекты или их часть, указанные в метке дуги перед разветвлением (т.е. каждая метка ветви уточняет, что именно содержит ветвь).

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

2.6.2. Слияние дуг

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

Более глубокие концепции диаграмм

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

Более глубокие концепции моделей

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

Чтение диаграмм и моделей

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

Цикл автор/читатель

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

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

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

В цикле автор/читатель принимают участие специалисты с разными обязанностями: авторы создают модели, читатели читают и комментируют работу авторов, Комитет технического контроля утверждает результаты, а библиотекарь организует хранение и распространение материалов. Эти функции и их взаимодействие отражены на рис. 12-1. Ниже в этой главе приведено подробное описание этапов цикла автор/читатель.

Конструктивное комментирование

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

Начало моделирования

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

Ответы на комментарии и их обобщение

Оглавление

Подготовка папки

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

Процесс моделирования

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

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

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

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

Продолжение моделирования

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

Проверка диаграммы автором

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

Сбор информации

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

Синтаксис и применение диаграмм

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

Синтаксис моделей и работа с ними

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

Системы и модели

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

Под термином "моделирование" мы понимаем процесс создания точного описания системы. Особенно трудным оказывается описание систем средней сложности, таких, как система коммутаций в телефонных сетях, управление аэровоздушными перевозками или движением подводной лодки, сборка автомобилей, челночные космические рейсы, функционирование перерабатывающих предприятий. С точки зрения человека, эти системы описать достаточно трудно, потому что они настолько велики, что практически невозможно перечислить все их компоненты со своими взаимосвязями, и в то же время недостаточно велики для применения общих упрощающих предположений (как это принято в физике). Наша неспособность дать простое описание, а следовательно, и обеспечить понимание таких систем делает их проектирование и создание трудоемким и дорогостоящим процессом и повышает степень их ненадежности.
С ростом технического прогресса адекватное описание систем становится все более актуальной проблемой.
SADT (аббревиатура выражения Structured Analysis and Design Technique - методология структурного анализа и проектирования) - это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности. SADT была создана и опробована на практике в период с 1969 по 1973 г. Эта методология возникла под сильным влиянием PLEX, концепции клеточной модели человек-ориентированных функций Хори, общей теории систем технологии программирования и даже кибернетики. С 1973 г. сфера ее использования существенно расширяется для решения задач, связанных с большими системами, такими, как проектирование телефонных коммуникаций реального времени, автоматизация производства (САМ), создание программного обеспечения для командных и управляющих систем, поддержка боеготовности. Она с успехом применялась для описания большого количества сложных искусственных систем из широкого спектра областей (банковское дело, очистка нефти, планирование промышленного производства, системы наведения ракет, организация материально-технического снабжения, методология планирования, технология программирования). Причина такого успеха заключается в том, что SADT является полной методологией для создания описания систем, основанной на концепциях системного моделирования.

Соглашения по построению диаграмм

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

---

---