Главная цель DFD - показать, как каждая работа преобразует свои входные данные в выходные, а также выявить отношения между этими работами

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

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

Работы. В DFD работы представляют собой функции системы, преобразующие входы в выходы. Смысл их совпадает со смыслом работ IDEF0. Они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.

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

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

Хранилище данных. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое

16.​ Проектирование функций. Диаграмма потоков данных.

Состав диаграмм потоков данных

Основными компонентами диаграмм потоков данных являются:

• внешние сущности;

• системы и подсистемы;

• процессы;

• накопители данных;

• потоки данных

1. Описание контекста процессов и построение начальной контекстной диаграммы.

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

2. Спецификация структур данных.

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

3. Построение начального варианта концептуальной модели данных.

Для каждого класса объектов предметной области выделяется сущность. Устанавливаются связи между сущностями и определяются их характеристики. Строится диаграмма "сущность-связь" (без атрибутов сущностей).

4. Построение диаграмм потоков данных нулевого и последующих уровней.

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

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

Декомпозируются сложные процессы и проверяется соответствие различных уровней модели процессов.

Накопители данных описываются посредством структур данных, а процессы нижнего уровня — посредством спецификаций.

5. Уточнение концептуальной модели данных.

Определяются атрибуты сущностей. Выделяются атрибуты-идентификаторы. Проверяются связи, выделяются (при необходимости) связи "супертип-подтип".

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

17.​ Проектирование пользовательского интерфейса.

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

Типы.

Процедурно-ориентированные:

а) примитивный интерфейс – взаимодействие с пользователем происходит в консольном режиме;

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

в) со свободной навигацией (графический пользовательский интерфейс / Graphic User Interface) – соответствует интерактивному взаимодействию пользователя с графическими элементами управления.

Объектно-ориентированные:

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

Психофизические особенности человека, требующие учёта при проектировании пользовательского интерфейса.

1. В каждый момент времени фокус внимания может фиксироваться в одной точке.

2. В процессе переработки информации мозг воспинимает данные в определенном контенте.

3. При смене кадра мозг на некоторое время блокируется для исследования нового изображения. Если требуется быстрая реакция, не следует перерисовывать всё изображение.

4. Емкость краткосрочной памяти составлет в среднем 5-9 объектов. Не стоит без необходимости требовать от пользователя запоминать больше 5 объектов (например, числа из 5 цифр).

5. Люди вносят в каждую деятельность понимание того, как она должна выполняться (модель деятельности). Желательно, чтобы расположение элементов интерфейса было привычно пользователю.

6. Цвет ассоциируется человеком с некоторым эмоциональным фоном. Не стоит злоупотреблять "теплыми" цветами, т.к. они быстро утомляют.

7. Обилие оттенков привлекает внимание, но и быстро утомляет.

8. При создании звукового сопровождения целесообразно предусмотреть возможность его отключения.

9. При ожидании более 2 секунд пользователь может отвлечься, "потерять мысль". Следует на время ожидания предоставить пользователю хотя бы какую-то промежуточную информацию.

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

Модели интерфейса.

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

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

Программная модель - итоговая модель, обобщающая модели программиста и пользователя.

Типы диалога:

- управляемые программой;

- управляемые пользователем.

Формы диалога:

- фразовая - предполагает общение с пользователем на естественном языке или его подмножестве;

- директивная - предполагает использование команд (директив) формального языка;

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

Разработка диалогов.

1. Проектирование абстрактных диалогов - определение множества необходимых диалогов, их основных сообщений и возможных сценариев.

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

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

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

Проектирование интерфейсов прямого манипулирования.

Метафора - мысленный перенос свойств или признаков одного объекта на другой.

Существует три типа основных объектов ИПМ:

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

- объекты-контейнеры - могут манипулировать своими внутренними объектами, например, копировать их или сортировать;

- объекты-устройства - представляют устройства, существующие в реальном мире (диски, принтеры и т.д.).

Манипулирование объектами происходит с использованием технологии drag & drop.

Интеллектуальные элементы пользовательских интерфейсов.

1. Советчик - помогают пользователям в выполнении конкретных задач.

2. Мастер - используется для выполнения общераспространенных задач, например, установка ПО.

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

Интерфейсы прикладного программирования.

Вопрос 18.​ Проектирование выходных документов.

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

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

рис. Структура документа.

Зона 1	Зона 2	Заголовочная часть
Зона 3
Зона 4
Зона 5	Содержательная часть
Зона 6	Оформляющая часть

Формуляр образца проектируется в соответствии с ГОСТами. Документ делится на три части: 1.Заголовочная (зоны 1-4). Зона 1 – наименование объекта управления, структурного подразделения. Здесь указывается почтовый адрес объекта. Зона 2 – индекс формы, гриф ее утверждения. Зона 3 – наименование и значение реквизитов-признаков, постоянных для данного документа. Зона 4 – название документа и дата составления. 2.Содержательная (зона 5). Зона 5 – наименование строк, граф и их значения. 3. Оформляющая (зона 6). Зона 6 – подписи ответственных лиц, печать. Зоны документов имеют следующую форму: линейную; табличную; анкетную. При линейной форме каждому реквизиту выделяются две клетки: для наименования; для значения. Табличная форма предусматривает расположение данных в виде таблицы с графами по вертикали и строками по горизонтали. Так оформляется пятая зона документа. Анкетная форма подразумевает размещение реквизитов в вертикальной последовательности: наименования – в левой части, значения – в правой. На практике обычно имеет место сочетание этих двух форм – линейной и табличной. При проектировании входного документа важное значение имеет связанный с этой формой носитель. Входной документ должен удовлетворять следующим требованиям: Многострочность; Выделение реквизитов, переносимых на машинный носитель, утолщенной рамкой при размещении на бланке; Включение информации для контроля (контрольные суммы или контрольный разряд по модулю); Состав показателей в документах не должен повторяться.

Рассмотрим особенности проектирования экранных форм. Порядок проектирования экранной формы следующий: проектирование содержания экранной формы; проектирование ее формы представления (формы экрана); программное обеспечение экранной формы.

Содержание экранной формы зависит от ее назначения. По назначению можно выделить следующие типы экранных форм: для ввода информации в базу данных; для параметров обработки информации по задаче; для вывода результатов решения задачи и справочной информации. Результатом проектирования содержания экранной формы является ее реквизитный состав.

Вопрос 19.​ Структурное и объектное моделирование. Основные идеи каждого подхода.

· Структурное моделирование

Структурное моделирование [structural equation modeling (SEM)] восходит к множественной регрессии (см.файл «Множественная регрессия в SPSS») и служит сходным целям, но обладает более широкими возможностями, допуская моделирование взаимодействий, нелинейностей, коррелирующих независимых переменных, ошибки измерения, коррелирующих членов ошибки, множества латентных независимых переменных, каждая из которых измеряется множеством индикаторов, и одной и более зависимых переменных, каждая из которых также измеряется множеством индикаторов. SEM можно использовать как более мощную альтернативу множественной регрессии, путевого анализа, факторного анализа, анализа временных рядов и ковариационного анализа. То есть, эти процедуры могут рассматриваться специфическими случаями SEM или, если сказать по другому, SEM является расширением общей линейной модели (GLM), которая, в свою очередь, является расширением множественной регрессии.

К преимуществам SEM в сравнении с множественной регрессией относятся более гибкие допущения (в частности, разрешающие интерпретацию даже при наличии мультиколлинеарности), использование конфирматорного факторного анализа, снижающего ошибки измерения за счет использования множества индикаторов для каждой латентной переменной, удобный графический интерфейс моделирования в SEM, возможность тестирования модели в целом, скорее чем на уровне отдельных коэффициентов, возможность тестирования моделей с множеством зависимых переменных, возможность моделировать промежуточные переменные, не ограничиваясь только аддитивными моделями (в регрессионном анализе зависимая переменная является функцией от эффекта Var1 плюс эффекта Var2 плюс эффекта Var3 и т.д.), моделировать члены ошибки, тестировать коэффициенты путем сравнения их в различных группах респондентов и управлять сложными данными (временными рядами с автокоррелирующими ошибками, не-нормальными данными, неполными данными). Кроме того, в сравнении с регрессией, подверженной ошибкам интерпретации из-за плохо специфицированных моделей, стратегия оценки в SEM, опирающаяся на сравнение альтернативных моделей для выявления лучше всего соответствующей исходным данным, отличается гораздо большей надежностью.

SEM принято рассматривать как скорее конфирматорную, чем эксплораторную процедуру, использующую один из трех подходов:

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

Подход с альтернативными моделями. Можно проверить две или более каузальные модели на предмет того, какая из них обладает лучшим соответствием исходным данным. Существует множество показателей качества соответствия, разрабатывавшихся на основе различных соображений, и обычно исследователь выбирает из них и указывает в отчете три или четыре показателя. Несмотря на желательность использования именно такого подхода при моделировании различных жизненных явлений, на практике исследователю редко удается найти в литературе две хорошо разработанных альтернативных модели для последующего сравнения со своей моделью.

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

Однако независимо от подхода, само по себе SEM не может рисовать каузальные стрелки в моделях или разрешать каузальные неопределенности. Для этого требуется теоретическое осмысление, знание изучаемого предмета и здравый смысл исследователя.

SEM является семейством статистических процедур, которые инкорпорируют и объединяют путевой анализ и факторный анализ (см. файлы «Путевой анализ в SPSS» и «Факторный анализа в SPSS»). Фактически, использование процедур SEM для модели, в которой каждая переменная имеет только один индикатор, является формой путевого анализа. Использование процедур SEM для модели, в которой каждая переменная имеет множество индикаторов, но где нет прямых эффектов (стрелок), связывающих переменные, является формой факторного анализа. Однако обычно SEM связывается с гибридной моделью, в которой имеется как множество индикаторов для каждой переменной (называемой латентной переменной или фактором), так и путей, обозначающих связи между латентными переменными. Синонимами SEM являются ковариационный структурный анализ, ковариационное структурное моделирование и анализ ковариационных структур [covariance structure analysis, covariance structure modeling, and analysis of covariance structures]. Несмотря на то, что эти синонимы прямо указывают на анализ ковариации как на фокус SEM, следует иметь в виду, что SEM может также анализировать структуру средних оценок модели.

· Объектное моделирование

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

Объектно-ориентированное моделирование обычно делится на два аспекта работы: моделирования динамического поведения, как бизнес-процессов и прецедентов, а также моделирования статических структур, таких как классы и компоненты. ООА и ООД являются двумя различными абстрактными уровнями во время ООМ. Unified Modeling Language (UML) и SysML являются двумя популярными международными языками стандартов, которые используются в объектно-ориентированном моделирование.

Преимущества ООМ являются:

· Эффективная и действенная связь:

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

· Полезная и стабильная абстракция

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

20. Универсальный язык моделей (UML): общая характеристика.

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

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

UML не является языком программирования.

UML не является спецификацией инструмента.

UML не является моделью процесса разработки приложений.