45504

Графические средства представления проектных решений АСОИУ (IDEF, DFD, UML, ERD и т.п.)

Доклад

Информатика, кибернетика и программирование

DFD диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. Первый шаг моделирования – извлечение информации из интервью и выделение сущностей. Второй шаг моделирования – идентификация связей. Язык UML находится в процессе стандартизации проводимом OMG – организацией по стандартизации в области ОО методов и технологий в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО.

Русский

2013-11-17

36 KB

20 чел.

13

Графические средства представления проектных решений АСОИУ (IDEF, DFD, UML, ERD и т.п.)

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

Основные компоненты: внешние сущности, системы и подсистемы, процессы, накопители данных, потоки данных.

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

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

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

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

ERD – данная нация используется в CASE средстве Oracle Designer.

Первый шаг моделирования – извлечение информации из интервью и выделение сущностей.

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

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

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

Супертипы и подтипы: одна сущность является обобщающим понятием для группы подобных сущностей.

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

Рекурсивная связь – сущность может быть связана сама с собой.

Неперемещаемые связи – экземпляр сущность не может быть перенесен из одного экземпляра связи в другой.

UML - - приемник того поколения методов объектно-ориентированного анализа и проектирования, которые появились в конце 80-х и начале 90-х годов. UML-является прямым объединением и унификацией методов Буча, Рамбо, Якобсона. Язык UML находится в процессе стандартизации, проводимом OMG – организацией по стандартизации в области ОО методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических и других. UML содержит стандартный набор диаграмм и нотаций: диаграммы вариантов использования (для моделирования бизнес-процессов организации – требования к системе), классов (для моделирования статической структуры классов системы и связи между ними), поведения системы, взаимодействия (для моделирования процесса обмена сообщениями между объектами), состояния (для моделирования поведения объектов системы при переходе из одного состояния в другое), деятельности (для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельности ).

 IDEF0 - диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель. Построение SADT-модели начинается с представления всей системы в виде простейшей компоненты - одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы. Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм. Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2.


 

А также другие работы, которые могут Вас заинтересовать

40579. Работа Access с данными на SQL Server 3.6 MB
  Access предоставляет возможность использовать данные из различных внешних источников. Внешними источниками данных могут служить таблицы других баз данных Access, Microsoft FoxPro, dBASE, Paradox и Microsoft SQL Server, таблицы и списки HTML и НТХ, находящиеся на сервере в локальной, корпоративной или сети Internet, данные из таких приложений, как Excel, Exchange
40580. Сущность метода Баркера 40.52 KB
  С их помощью определяются важные для предметной области объекты сущности их свойства атрибуты и отношения друг с другом связи. Графическое изображение сущности Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Одна и та же интерпретация не может применяться к различным именам если только они не являются псевдонимами; сущность обладает одним или несколькими атрибутами которые либо принадлежат...
40581. Сущность метода Баркера 53 KB
  Вендрова Проектирование ПО Ход урока Организационный момент 24 мин: Приветствие оформление документов к занятию Повторение пройденного материала применяемая методика выводы1520 мин Письменные ответы на вопросы: Рассмотреть стандарты: проектирования; оформления проектной документации; пользовательского интерфейса. Сообщение темы урока постановка цели и задачи:13 мин: рассмотреть сущность метода Баркера; Изложение нового материала применяемая методика: 5060 мин. Закрепление изучаемого материала...
40582. Разработка диаграмм по методу Баркера 46 KB
  Организационный момент 23 мин: Приветствие фиксация отсутствующих проверка санитарного состояния аудитории заполнение журнала рапортички проверка подготовленности студентов к занятию. Напоминание правил техники безопасности при работе с ПК; 2. Сообщение темы цели и задач практикума 23 мин: Цели: Приобретение навыков моделирования по методу Баркера для построения моделей информационной системы. Актуализация опорных знаний и умений студентов 1015 мин: устный опрос занятие 18 п.
40583. Общие принципы и подходы к разработке ПО 869.44 KB
  Итерация N Унифицированный процесс разработки программного обеспечения USDP Модель вариантов использования описывает случаи в которых приложение будет использоваться. Аналитическая модель описывает базовые классы для приложения. Модель проектирования описывает связи и отношения между классами и выделенными объектами Модель развертывания описывает распределение программного обеспечения по компьютерам.
40584. Структурный подход 30 KB
  Все наиболее распространенные методологии структурного подхода [9111213] базируются на ряде общих принципов [3]. В качестве двух базовых принципов используются следующие: принцип разделяй и властвуй принцип решения сложных проблем путем их разбиения на множество меньших независимых задач легких для понимания и решения; принцип иерархического упорядочивания принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Выделение двух базовых принципов не означает...
40585. Проблема сложности больших систем 21.96 KB
  Единственно эффективный подход к решению этой проблемы заключается в построении сложной системы из небольшого количества крупных частей каждая из которых в свою очередь строится из частей меньшего размера и т. по отношению к проектированию сложной программной системы это означает что ее необходимо разделять декомпозировать на небольшие подсистемы каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня держать в уме информацию только о ней а не обо всех остальных частях системы....
40586. Методология функционального моделирования SADT. Состав и функции моделей SADT 61.84 KB
  Состав и функции моделей SDT. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг выражающих ограничения которые в свою очередь определяют когда и каким образом функции выполняются и управляются; строгость и точность. отделение организации от функции т. Методология SDT может использоваться для моделирования широкого круга систем и определения требований и функций а затем для разработки системы которая удовлетворяет этим требованиям и реализует эти функции.
40587. Методология функционального моделирования SADT. Состав и функции моделей SADT. Типы связей 40.5 KB
  Вендрова Проектирование ПО Ход урока Организационный момент 24 мин: Приветствие оформление документов к занятию Повторение пройденного материала применяемая методика выводы1520 минзанятие 22 п.5 Сообщение темы урока постановка цели и задачи:13 мин: Методология функционального моделирования SDT; Состав и функции моделей SDT. Изложение нового материала применяемая методика: 5060 мин. лекция: Состав функциональной модели Иерархия диаграмм Типы связей между функциями Моделирование потоков данных процессов...