Пояснение с помощью рисунков

Хотя для определения терминологии и изложения содержания используются текстовые описания, слова следует употреблять экономно. Мы советуем для пояснения тонких моментов и того, что трудно выразить словами, использовать, где это возможно, и рисунки. В SADT любое изо­бражение, которое не является строго диаграм­мой, считается дополнительным рисунком. SADT-рисунки - это обычно либо картинки, либо диаграммы с дополнительными изображениями, связанные с конкретной диаграммой модели. Связь указывается с помощью добавления к номеру узла поясняемой диаграммы буквы Р и порядкового номера, как показано на рис. 18-4.

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

Рис. 18-4. Рисунок, показывающий, что представляет собой дуга СТАНОК, ГОТОВЫЙ К РАБОТЕ

 

мени (например, график поступления заданий). На рис. 18-4 показано, как выглядит типичное готовое рабочее место.

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

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

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

Дополнение моделей

Иерархические наборы SADT-диаграмм, называемые "моделями", вводят объект описания и уточняют его регулярным, управляемым и по­нятным образом. Это обеспечивается тем, что диаграммы модели всегда организованы в соответ­ствии с порядком нумерации узлов. Это означает, что первым идет узел А-0, вторым - узел АО, третьим - узел А1, четвертым - узел All и т. д. Такой порядок расположения SADT-диаграмм является копией "древовидной" структуры, часто встречающейся в математике и информатике. Полная SADT-модель обычно читается двумя спо­собами. Первый способ - обзорное чтение, когда читаются все диаграммы верхнего уровня, прежде чем перейти к диаграммам следующего. Это на­зывается чтением "в ширину". Второй способ -детальное чтение, когда читают отдельную ветвь дерева вплоть до диаграмм самого нижнего уров­ня. Это называется чтением "в глубину".

Чтобы помочь читателям правильно двигать­ся по древовидному набору диаграмм, разработа­ны дополнительные средства. Примерами таких средств могут служить указатель диаграмм и ука­затель узлов. Они представляют собой составлен­ные с отступами списки узлов или диаграмм (по типу оглавления), определяющих содержание модели. В указателе диаграмм перечисляются все диаграммы модели с приведенными в отдельной строке названием и номером узла каждой диа­граммы. В указателе узлов перечисляются все бло­ки модели, причем в каждой отдельной строке записываются название и номер узла соответству­ющего блока. Таким образом, указатель узлов является просто более подробным, чем указатель диаграмм, списком. Указатели диаграмм для мод­елей обсуждаются в части VI. Обратите внимание на то, что оглавления (таблицы содержаний) слу­жат как кратким конспектом системы, так и средством быстрого поиска при рассмотрении конкретного функционального фрагмента системы.

Рис. 18-5. На диаграмме показан основной путь

Резюме

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 Engineer­ing, Van Nostrand Reinhold, New York, 1983.

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

 

Marca, D.: Applying Software Engineering Prin­ciples, Little Brown, Boston, 1984.

 

Martin, J., and McClure, C.: Diagramming Tech­niques for Analysts and Programmers, Prentice-Hall, Englewood Cliffs, N.J., 1985.

 

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

Глава 19. Примечания на диаграммах и моделях

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

Информация о свойствах

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

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

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

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

 

Рис. 19-1. Добавление меток, описывающих свойства моделируемой системы

Правила действия

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

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

 

[Модель/] блок * действие: предусло­вия--> постусловия

 

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

Рис. 19-2. Функция, имеющая единственное правило действия

 

Для функции блок правило действия дейст­вие определяется так: если истинны предусловия, выполняется функция блок и делает истинными постусловия.

Как предусловия, так и постусловия пред­ставляют собой логические выражения, построен­ные с помощью ICOM-кодов, где каждый ICOM-код идентифицирует единичную дугу управления, входную или выходную дугу конкретного блока. Логические операторы AND, OR и NOT вместе со скобками представляют средства для записи различных сложных логических выражений. Например, на рис. 19-2 показан блок диаграммы ЭМЦ/А2, у которого только одно правило дей­ствия. Это правило утверждает, что функции. подготовить рабочее место необходимы выбран­ное инструменты, станки в цехе, чертеж и указа­ния, чтобы рабочий подготовил оборудованное рабочее место. Это пример правила действия, которое утверждает необходимость участия всех входных дуг, дуг управления и выходных дуг в действии конкретного блока.

Часто возникают ситуации, в которых для правильного действия блока необходимо отсут­ствие одной или нескольких дуг. Дуги, не участ­вующие в конкретном действии, отмечаются горизонтальным штрихом (символизирующим NOT) над ICOM-кодом, если они входят в пред­условие. Это означает, что объекты, представля­емые этой дугой, должны отсутствовать для того, чтобы действие было выполнено. Например, дей­ствие 3 на рис. 19-3 утверждает, что план выпол­нения заданий не должен быть представлен в мо­мент оценки задания, который предшествует приемке.

Рис. 19-3. Функция, имеющая несколько правил действия

 

Встречаются также ситуации, когда только некоторые из дуг используются в процессе дей­ствия для производства выходов. Если входная дуга или дуга управления не участвуют в дей­ствии, они просто опускаются в предусловии. Аналогично если только часть выходов блока производится во время действии, то ICOM-коды для этих не создаваемых выходов опускаются в постусловиях. Например, отсутствие 02 и 03 в действии 4 означает, что в процессе этого дей­ствия вырабатывается только статус задания.

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

Генерация правил действия

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

Действие каждого блока описывается таб­лицей истинности, представляющей собой декар­тово произведение всех возможных сочетаний присутствия (отмечаемого с помощью "true" или Т) и обязательного отсутствия (отмечаемого с помощью "false" или F) входных дуг, дуг управ­ления и выходных дуг. Каждый столбец такой таблицы становится тогда потенциальным прави­лом действия. (Иногда не имеет значения, при­нимает ли конкретная дуга участие в действии. В этих случаях представляется разумным использо­вание буквы D. Однако запомните, что для пол­ного отражения декартова произведения потре­буется существенное увеличение размера таб­лиц.)

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

 

Условия	Варианты действий
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Выбранные инструменты Станки в цехе Чертежи и указания Оборудованное рабочее место	T F T F T F T F T F T F T F T F T T F F T T F F T T F F T T F F T T T T F F F F T T T T F F F F T T T T T T T T T F F F F F F F

 

Таблица 19-1. Все возможные действия блока "Подготовить рабочее место"

 

прием, когда вы точно не знаете, как выполня­ется конкретная функция моделируемой вами системы.

Резюме

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

 

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

 

Dickover, M., and С. McGowan: "Software Design Using SADT", SofTech Technical paper TP061, August 1977.

 

Mendelson, E.: Introduction to Mathematical Logic, Van Nostrand Reinhold, New York, 1964.

 

Martin, J., and C. McClure: Diagramming Tech­niques for Analysts and Programmers, Prentice-Hall, Englewood Cliffs, N.J., 1985.

 

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

 

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

 

Ross D.: "Structured Analysis (SA): A Language for Communicating Ideas", IEEE Transactions on Software Engineering, vol. 3, no. 1, January 1977.

 

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

 

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

 

Savith, W.: Abstract Machines and Grammars, Little, Brown, Boston, 1982.

 

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

 

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

Глава 20. Управление проектом

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

Начало проекта

Успешный проект всегда имеет хороший старт, который обычно включает формирование технического задания на проектирование, исход­ный выбор создаваемых моделей, организацию группы аналитиков, выбор Комитета техническо­го контроля и составление графика работ. Такое начало приводит к созданию плана проекта, ко­торый координирует усилия многих людей и де­лает проект управляемым.

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

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

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

Рис. 20-1. Типичная структура SADT-проекта

 

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

⇐ Предыдущая18192021222324252627Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: