WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 17 | 18 || 20 | 21 |   ...   | 33 |

С определением модели тесно связана позиция, с которой наблюдается система и создается ее модель. Поскольку качество описания системы резко снижается, если оно не сфокусировано ни на чем, SADT требует, чтобы модель рассматривалась все время с одной и той же позиции. Эта позиция называется «точкой зрения» данной модели. Точку зрения лучше всего представлять себе как место человека или объекта, в которое надо встать, чтобы увидеть систему в действии.

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

На рис. 1 показано, как автор модели подразделения разработки программного обеспечения, которое называется «Лаборатория АВР», перечисляет претендентов, с точки зрения которых можно было бы описывать подразделение. Если в модели работы программирующего подразделения не зафиксировать определенную точку зрения, то легко можно смешать проблему инженерного обслуживания компьютеров с тем, какие будут применяться отступы при кодировании на С++. Если это произойдет, то читатель модели столкнется с трудностями при определении конкретных обязанностей персонала.

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

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

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

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

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

Корпоративные стандарты Разработка Программный продукт программного Требования продукта Персонал Цель:

Понять, какие функции должны быть включены в процесс изготовления программного продукта и как эти функции взаимосвязаны между собой с тем чтобы написать должностные инструкции Точка зрения: заведующий лабораторией NODE: АВР А0 TITLE: Разработка программного продукта NO.: ФАН Рис. 2 Представление функции верхнего уровня Корпоративные стандарты План Подготовка Модель Архитекторы Требования Код Разработка Программисты Выпуск Программный продукт Тестеры Персонал NODE: АВР А1 TITLE: Разработка программного продукта NO.: ФАН Рис. 3 Детализация функции На рис. 3 показано также взаимное влияние трех функций нижней диаграммы, обозначенное дугами, которые символизируют объекты.

Видно, что некоторые дуги доходят до границы диаграммы и что имена этих дуг совпадают с теми, что указаны на дугах верхней диаграммы.

Это пример того, как SADT соединяет диаграммы в модели через объекты системы.

Процесс создания SADT-модели итеративный: модели создаются и проходят серию последовательных улучшений до тех пор, пока они в точности не будут представлять объект моделирования. В частности, одна и та же диаграмма может рассматриваться неоднократно, что приводит к появлению различных ее вариантов. Чтобы различать разные версии одной и той же диаграммы, в SADT используется схема контроля конфигурации диаграмм, основанная на хронологических или Сномерах (от Chronological Number). С-номерные коды обычно образуются из инициалов автора и последовательных номеров. Эти коды ставятся в нижнем правом углу SADT-бланка. Например, ФАН 001 – это С-номер для диаграммы «Разработка программного продукта» на рис. 3.

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

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

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

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

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

Бланк диаграммы Диаграммы IDEF0 изображаются на специальных бланках. Вся диаграмма располагается в средней части бланка, а в верхней части («Заголовок») и в нижней части («Подвал») располагается служебная информация. Диаграмме дается название, которое располагается в центре нижней части ее бланка. В верхней части бланка диаграммы располагается стандартная идентифицирующая диаграмму информация:

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

Таблица 1.

Элементы «Заголовка» и «Подвала» диаграммы IDEF0.

Поле Перевод Назначение Элементы заголовка диаграммы Used At Используется Используется для внешних ссылок на В диаграмму Author, Автор, проект, Содержит имя автора диаграммы, даты project, date, дата, создания и последнего внесения revised пересмотр изменений, название проекта Notes 1…10 Замечания При ручном редактировании очередная цифра зачеркивается при внесении изменений Status: Состояние: Отражает состояние разработки или утверждения диаграммы Working Рабочая версия Новая диаграмма, глобальные изменения или новый автор Draft Эскиз Диаграмма достигла уровня готовности представления на утверждение Recommended Рекомендовано Диаграмма одобрена и утверждена Publication Публикация Диаграмма готова для печати и публикации Reader Читатель Имя читателя Date Дата Дата знакомства читателя с диаграммой Context Контекст Схематическое изображение функциональных блоков на родительской диаграмме Элементы подвала диаграммы Node Узел Title Название C-Number Номер Функциональная декомпозиция Каждая IDEF0-диаграмма содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки и отображают взаимодействия и взаимосвязи между ними.

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

Рис. 4 Типичная IDEF0-диаграмма.

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

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

Дуги на диаграмме изображаются одинарными линиями со стрелками на концах. Для IDEF0-диаграмм дуга представляет множество объектов и описывается существительным или существительным с определениями. Здесь используется общее понятие «объекты», поскольку дуги в SADT могут представлять планы, данные в компьютерах, машины, информацию или что-то другое — материальное или нематериальное. Поскольку дуги представляют наборы объектов, они могут иметь множество начальных и конечных точек. Поэтому дуги могут различными способами разветвляться и соединяться.

Между объектами и функциями возможны четыре отношения:

вход (input), управление (control), выход (output), механизм (mechanism). Каждое из этих отношений изображается дугой, связанной с определенной стороной блока: левая сторона блока предназначена для входов, верхняя – для управления, правая – для выходов, нижняя – для механизмов. Такое обозначение отражает определенные системные принципы: входы преобразуются в выходы, управление ограничивает или предписывает условия выполнения преобразований, механизмы показывают, какие ресурсы необходимы для выполнения функции.

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

В методологии SADT определены пять типов взаимосвязей между блоками для описания их отношений:

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

приготовления должны быть завершены до начала работы).

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

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

Разделение такого объекта на его структурные части (блоки и дуги, составляющие диаграмму) называется декомпозицией.

Декомпозиция формирует границы новой диаграммы.

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

Принцип ограничения объекта встречается на каждом уровне.

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

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

Pages:     | 1 |   ...   | 17 | 18 || 20 | 21 |   ...   | 33 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.