Норенков И.П. - Автоматизированное производство (1054022), страница 62
Текст из файла (страница 62)
6.)). IDEF4-диаграмма таксономии методов&.+.)$(*),$" . !"#$%!#&'&($"!))$*+($*,#&($"!)&*1625@!"! 6%*#$A&,&+($*,#&($"!)&P !"#$%!#&'&($"!))KH :&:#*%%+,. 6.)2. IDEF4-диаграмма клиентовтов и процессов вместе с их взаимосвязями. Для этого применяют символическиеобозначения (дескрипторы) объектов, ихассоциаций, ситуаций и схемный язык%+,. 6.)3. Символы графического языка IDEF5описания отношений (классификации,часть-целое, перехода и т.п.), составляют словарь дескрипторов. В методике имеются правила связывания объектов (термов) в правильные предложения, языковые механизмы для установления соответствия между объектами реального мира и их идентификаторами (дескрипторами).В IDEF5 имеются две части: 1) схемный язык; 2) язык разработки (elaboration). Основные символы схемного языка представлены на рис.
6.13, пример классификационной схемы — на рис. 6.14 ипример диаграммы перехода состояний с символикой IDEF5 — на рис. 6.15.%+,. 6.)4. Диаграмма классификации%+,. 6.)5. Диаграмма перехода состояний в IDEF5Развитие методик реинжиниринга (BPR Business Process Reenginiring) продолжается в США по программе IICE(Information Integration for Concurrent Engineering). Разработаны, но пока (1998 г.) не получили официального статуса оторганов стандартизации методики, имеющие индексы IDEF6, 8, 9, 14, разрабатываются методики IDEF7, 10, 12.IDEF6 (Design Rationale Capture) направлена на получение и представление решений по выбору стратегии проектирования и обоснованию предпринятых шагов.
В отличие от других методик IDEF, в которых фиксируются результаты проектирования, в IDEF6 главный упор сделан на пути получения этих результатов и обоснование промежуточных решений.Такой подход особенно важен при разработке сложных систем в недостаточно определенных ситуациях. Фиксация шагови обоснований помогает при дальнейших модернизациях систем, сохранению и использованию рационального опыта проектирования. Методика упорядочивает обнаружение и устранение неопределенностей, ошибок, неудовлетворенных ограничений.
Язык методики включает предложения, связывающие компоненты проекта с пунктами обоснования. Под компонентами проекта обычно подразумевают компоненты, отражаемые на диаграммах IDEF0-5, например, стрелки ICOM изIDEF0, сущности, атрибуты, отношения из IDEF1X, объекты, сообщения, события из IDEF4 и т.п. В качестве пунктовобоснования могут фигурировать стандарты, экспериментальные данные, ограничения и т.п.IDEF8 (Human-System Interaction Design) предназначена для проектирования взаимодействия человека с технической системой.
Эта методика не является методикой создания графического пользовательского интерфейса и потому обычно дополняется некоторой системой GUI (Graphic User Interface). Здесь определяется содержание (на абстрактном уровне)той части работы, которую выполняет человек. Создаваемые сценарии должны удовлетворять ряду оговоренных в методике принципов таких, как уменьшение нагрузки на человека, идентичность средств диалога в разных системах, наличиеобратной связи для исправления ошибок, хранение истории диалога, помощь советами по выполнению действий и т.д.IDEF9 (Business Constraint Discovery) нацелена на выявление разнообразных ограничений (технических, физических, юридических, политических, организационных), которые должны быть учтены при разработке системы, и для анализа их влияния на принимаемые решения в процессе реинжиниринга. Обычно в качестве систем фигурируют сложные информационные системы с ориентацией на экономические и управленческие приложения.
Ограничение — это отношение,&.+.)$(*),$" . !"#$%!#&'&($"!))$*+($*,#&($"!)&*1635@!"! 6%*#$A&,&+($*,#&($"!)&P !"#$%!#&'&($"!))KH :&:#*%которое должно соблюдаться. Ограничения делятся на контексты (группы родственных ограничений). Применение IDEF9заключается в выполнении нескольких шагов: 1) сбор свидетельств (фактов, указывающих на наличие ограничения); 2)классификация — определение контекстов, объектов, отношений; 3) прогнозирование — выявление ограничений на основе свидетельств; 4) отбор значимых ограничений; 5) определение экспертов для тестирования результатов; 6) детализация и фильтрация ограничений.
В методике даны рекомендации по выполнению этих шагов. Предлагается графическийязык, элементами которого являются система, блоки ограничений, контексты, линии связи, логические связки OR, AND,XOR (исключающее ИЛИ).IDEF14 (Network Design) предназначена для проектирования корпоративных вычислительных сетей, их представления на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т.п.Чаще всего методика применяется для модернизации уже существующих сетей.
Поэтому в ней предусматривается разработка моделей как “AS IS”, так и “TO BE”. Проектирование включает в себя определение топологии сети или схемы коммуникаций, реализацию нужного качества обслуживания, анализ функционирования (трафик, дисциплины обслуживанияв узлах, протоколы доступа). Модель топологии дополняется моделями очередей, надежности, материальных затрат.
Важную роль играет библиотека методов построения и компонентов сетей. Методика основана на выполнении ряда шагов: установление целей модернизации, исследование существующей сети, определение типов компонентов в ней, построениемодели “AS IS”, ее верификация, анализ результатов, корректировка с переходом к “TO BE”.
В графическом языке IDEF14сети и подсети изображаются в виде облаков, топологические связи представляются линиями, для узлов используютсяспециальные иконки, возможны поясняющие надписи, список характеристик размещается в прямоугольниках.P0+H+=+849:0012 >?17 /45.D+849:0+> UML. Язык UML положен в основу Rational UnifiedProcess (RUP) — известной методологии проектирования информационных систем, развиваемой фирмой Rational Software. В UML также используется ряд диаграмм.К основным следует отнести прежде всего диаграммы классов. Они имеют следующие отличияот аналогичных диаграмм в IDEF4.Во-первых, в прямоугольнике класса имеются три секции, в верхней секции записывается имякласса, в средней секции — атрибуты, в нижней части — процедуры класса.
При записи атрибутовуказываются символ доступности (+ — public, # — prоtected, - - private), идентификатор атрибута, типатрибута. Запись процедуры аналогична подобным записям в языках программирования: указываются имя процедуры и в скобках — список параметров.Во-вторых, в диаграммах классов UML отображение отношений часть-целое (отношений агрегации) выполняется с помощью линий с ромбовидной стрелкой, направленной от класса-части к классу-целому, и отношений наследования (суперкласс-подкласс) — с помощью линий с обычной стрелкой, направленной от подкласса к суперклассу.Поведенческий аспект моделирования отражен в диаграммах процессов, имеющихся в UML.Они бывают двух типов — диаграммы сценариев (ДС) и диаграммы взаимодействия объектов (ДВО).Сценарий — это последовательность событий, заключающихся в воздействиях (посылках сообщений) одного объекта на некоторый другой объект.
В ДС объекты изображаются прямоугольникамии располагаются в горизонтальном ряду объектов. Ось времени направлена от этого ряда вертикально вниз. От каждого объекта параллельно оси времени идут такназываемые их линии жизни (lifelines). Каждое событие изображается горизонтальной линией со стрелкой от линии жизни объекта, посылающего сообщение, к линии жизни объекта, принимающего сообщение. Над этими линиями возможен поясняющийтекст. Линии располагаются одна над другой в порядке, в котором события совершаются (пример ДС на рис. 6.16).Диаграмма ДВО представляет собой граф, в котором вершины соответствуют объектам, а ребра — воздействиям. Околоребер возможны поясняющие записи, в частности, последовательные номера, указывающие порядок совершения событий.К числу других диаграмм относятся диаграммы использо- %+,.
6.)6. Вид диаграммы сценариеввания, цель которых — отобразить взаимодействие системы с пользователем. В этих диаграммах отображены в виде овалов те функции, которые непосредственно должен (или может) выполнять пользователь. При этом пользователи различаются ролями, выполняемыми ими при эксплуатации системы.Проектирование информационной системы в RUP начинается с построения диаграмм использования. При этом определяется и согласовывается внешняя функциональность системы и в итоге фор&.+.)$(*),$" . !"#$%!#&'&($"!))$*+($*,#&($"!)&*1645@!"! 6%*#$A&,&+($*,#&($"!)&P !"#$%!#&'&($"!))KH :&:#*%мируется техническое задание на разработку ПО.
Далее разрабатываются диаграммы взаимодействия“пользователь-система”, при этом выявляются необходимые объекты, строятся диаграммы классов,формируется компонентная структура ПО."84@8://04. 4B.,3.A.0+. CASE-,+,-./ 5D> 740=.3-<:DF04@4 384.7-+849:0+>. На рынкепрограммных продуктов имеется много CASE-систем для концептуального проектирования АС.Чаще всего в них поддерживается методология IDEF.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
