Документ Microsoft Office Word. Метод функционального моделирования sadt

Название	Метод функционального моделирования sadt
Дата	10.04.2022
Размер	0.62 Mb.
Формат файла
Имя файла	Документ Microsoft Office Word.docx
Тип	Документы #459414

Метод функционального моделирования SADT

На основе метода SADT, предложенного Д. Россом, разработана методо- логия IDEF0 (Icam DEFinition), которая является основной частью програм- мы ICAM (Интеграция компьютерных и промышленных технологий), прово- димой по инициативе ВВС США. Методология IDEF0 является наиболее признанным эффективным средством анализа, конструирования и отображе- ния бизнес-процессов, применяемым также и широко за пределами США

Контрольные вопросы:

Раскройте принципы структурного и объектно-ориентированного подхода?

Объе́ктно-ориенти́рованное программи́рование (ООП) — методология программирования, основанная на представлении программы в виде совокупностиобъектов, каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования.

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

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

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

абстракция для выделения в моделируемом предмете важного для решения конкретной задачи по предмету, в конечном счёте — контекстное понимание предмета, формализуемое в виде класса;
инкапсуляция для быстрой и безопасной организации собственно иерархической управляемости: чтобы было достаточно простой команды «что делать», без одновременного уточнения как именно делать, так как это уже другой уровень управления;
наследование для быстрой и безопасной организации родственных понятий: чтобы было достаточно на каждом иерархическом шаге учитывать только изменения, не дублируя всё остальное, учтённое на предыдущих шагах;
полиморфизм для определения точки, в которой единое управление лучше распараллелить или наоборот — собрать воедино.

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

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

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

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

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

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

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

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

Рисунок 1.1 – Структура модели Описание системы с помощью SADT называется моделью.

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

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

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

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

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

Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть детализирован диаграммой нижнего уровня, которая, в свою очередь, также может детализироваться с помощью необходимого числа диа- грамм. Таким образом, формируется иерархия диаграмм. Для того чтобы ука- зать положение любой диаграммы или блока в иерархии, им присваивают уникальные обозначения. Например, А41 (A сокр. от Activity) является диа- граммой, которая детализирует блок 1 на диаграмме А4. Аналогично, А4 де- тализирует блок 4 на диаграмме А0, которая является самой верхней (роди- тельской) диаграммой модели.

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

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

«туннель» расположен в месте соединения дуги с блоком « t», то данные этой дуги не обязательны на следующем уровне детализации. Если же «тун- нель» находится на противоположном конце дуги «¹—¹ – это значит, что данные дуги не описываются на родительской диаграмме.

Рисунок 1.2 – Структура SADT-модели. Иерархия и декомпозиция диаграмм
Граничные дуги должны продолжаться (дублироваться) на родительской диаграмме, делая ее полной и непротиворечивой (рисунок 1.3).

Для упрощения понимания приведенных диаграмм, следует расшифро- вать применяемую в IDEF систему обозначений, позволяющую аналитику точно идентифицировать и проверять по дугам связи между диаграммами. Эта схема кодирования дуг – «ICOM» – получила название по первым бук- вам английских эквивалентов слов вход (Input), управление (Control), выход (Output), механизм (Mechanism).

Рисунок 1.3 – Соответствие дуг родительской и дочерней диаграмм

Разработка модели IDEF0 в системе Ramus Educational

Программное обеспечение «Ramus» предназначено для использования в проектах, в которых необходимо описание бизнес-процессов предприятия.

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

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

Перечень основных ограничений по сравнению с коммерческой локаль- ной версией:

ограничен перечень доступных атрибутов классификаторов;
отсутствует функциональность для работы с матричными проекциями классификаторов;
отсутствует редактор отчётов;
отсутствует навигатор по модели.

Тем не менее, Ramus Educational поддерживает единый формат файлов с локальной версией Ramus. Таким образом, файл созданный в Ramus Educational можно редактировать в локальной версии Ramus, и, наоборот, (за исключением атрибутов поддерживаемых только в локальной версии Ramus).

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

Разрабатываемая система предназначена для того, чтобы помочь студен- ту устроиться на работу уже в процессе его обучения в ВУЗе. Подав заявле- ние в систему, студент становится её клиентом и начинает обслуживаться на протяжении всего обучения в Вузе. Система предлагает профессиональные (основанные на изучаемых предметах) и психологические тестирования. Тес- тирования проводятся регулярно – раз в семестр.

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

Создание контекстной диаграммы

При запуске системы Ramus Educational появляется окно вида (рисунок 1.4).

Рисунок 1.4 – Окно «Начало работы»
Выберем опцию «Создать новый файл» и нажмем кнопку «ОК».

В появившемся "Мастере свойств проекта внесите:

Автор– свое имя;
Названиепроекта– Служба занятости в рамках ВУЗа;
Названиемодели– не пишем;
Выберите нотацию IDEF0.

^После^{заполнения}^{необходимых}^{сведений}^{нажмите}^кнопку и перейдите к следующему шагу.

Укажите, что модель используется в Управление кадров. Студенческий отдел.

На следующем шаге в описании проекта укажите: «Учебная модель функционирования системы служба занятости ВУЗа».

Цель моделирования – подготовить описание функционирования систе- мы службы занятости, которое было бы понятно её пользователю, не вдава- ясь в подробности, связанные с реализацией.

Раздел «классификаторы» оставьте незаполненным и нажмите

.

^{В следующем диалоговом окне нажмите}^{и перейдите к рабо-}чему интерфейсу программы.

В дальнейшем через меню Диаграмма -> Свойства модели можно отре- дактировать мета-данные модели, а именно: название модели, описание, ме- сто ее использования.
Активируйте окно модели, кликнув на область моделирования.

Начнем с построения контекстной IDEF0-диаграммы. Создайте контекст- ^ную^{диаграмму,}^нажав^на^кнопку^.

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

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

В появившемся окне «Свойства функционального блока» в закладке

«Название» введите «Обслуживание клиента системы» (рисунок 1.5).

Рисунок 1.5 – Окно свойств функционального блока

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

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

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

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

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

Процесс обработки запросов будет выполнять «Пользователь системы»

под контролем «Администратор системы».

Управляющей стрелкой будут являться «Уровни доступа».

Результат построения контекстной диаграммы будет иметь вид (рисунок 1.6).

Рисунок 1.6 – Контекстная диаграмма системы

Создание декомпозиции контекстной диаграммы

Проведем декомпозицию контекстной диаграммы описав последователь- ность обслуживания клиентов:

^{Выберите}^кнопку^{перехода}^на^{уровень}^ниже^в^панели^{инструментов.}

В диалоговом окне укажите число работ на диаграмме нижнего уровня –

«4», а нотацию декомпозиции – IDEF0, затем нажмите «ОК». Автоматически будет создана диаграмма декомпозиции (рисунок 1.7).

Рисунок 1.7 – Диалоговое окно создания новой диаграммы
Правой кнопкой мыши щелкните по 1-ой работе, выберите «Редактиро- вать активный элемент» и на вкладке «Название» укажите имя работы. Повторите операцию для всех четырех работ, используя следующую после- довательность обслуживания клиента:

определение уровня доступа в систему;
обращение к подсистеме;
изменение БД (при необходимости);
обработка запроса клиента.

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

Рисунок 1.8 – Построение дочерней диаграммы

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

Обязательно создайте стрелку обратной связи (по управлению) Запросы на изменение БД, идущую от работы Обработка запроса клиента к Изме- нение БД. Изменить стиль стрелки – толщину (правая кнопка мыши – Ре- дактировать активный элемент – вкладка Линия).

Методом drag&drop возможно переносить стрелки и их названия. При необходимости, возможно установить «тильду» (опция контекстного меню при нажатии на стрелке правой кнопкой мыши) для явной связи стрелки и подписи к ней.

В результате получится представление вида (рисунок 1.9).

Рисунок 1.9 – Вид построенной диаграммы декомпозиции системы

Создание дальнейших диаграмм декомпозиций

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

Декомпозируем последовательно все блоки полученной диаграммы.

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

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

Определение уровня доступа в систему будет выглядеть следующим об- разом (рисунок 1.10).

Рисунок 1.10 – Определение следующего уровня декомпозиции системы Декомпозиция работы «Обращение к подсистеме» не отвечает цели и

точки зрения модели. Пользователя системы не интересуют внутренние ал- горитмы её работы. Поэтому декомпозиция данного блока не проводится. Аналогично обстоит дело с работой «Изменение БД».

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

Рисунок 1.11 – Вид декомпозиции блока «Обработка запроса клиента»
Необходимо отметить, что в блок «Выполнение запроса» включается работа различных подсистем. Например, если запрос включает в себя тести- рование, то его будет исполнять подсистема профессиональных и психологи- ческих тестов. При анализе полученной диаграммы возникает вопрос, по ка- ким правилам проводится генерация отчетов. Необходимо наличие заранее сформированных шаблонов, по которым будет производиться выборка из БД. Причем эти шаблоны должны соответствовать запросам и должны быть за- ранее определены. Клиенту же предоставляется возможность выбора формы отчета.

Скорректируем диаграмму, добавив в неё стрелку «Шаблоны отчетов»

(рисунок 1.12).

Рисунок 1.12 – Добавление стрелки «Шаблоны отчетов»
Эта стрелка автоматически не попадает в диаграмму верхнего уровня и имеет квадратные скобки у окончания (тунелирование), поэтому необходимо щелкнуть правой кнопкой мыши по квадратным скобкам и выбрать в контек- стном меню пункт «Тунель». Система предложит остановиться на одной из двух опций (рисунок 1.13).

Рисунок 1.13 – Окно «Туннелирования стрелки» Тунелирование применяется для того, чтобы не выносить на верхнеуров-

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

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

Декомпозиция процесса «Обработка запроса клиента» после корректи- ровки примет вид (рисунок 1.14).

Рисунок 1.14 – Декомпозиция процесса «Обработка запроса клиента» после корректировки
Вернемся на диаграммы верхних уровней и сделаем необходимые изме- нения (рисунок 1.15).

Рисунок 1.15 – Внесенные изменения на диаграмме декомпозиции системы