Екзамен МТТП КС

ХНУРЕ

Спеціалізація –«Інформаційні технології проектування»

«Системне проектування»

Семестр I

Навчальна дисципліна “Методологія та технологія проектування КС”

ЕКЗАМЕНАЦІЙНИЙ БІЛЕТ № 2

1. Роль фази «Фізичне проектування» МТП КС.

2. Зв`язок методів «Логічне моделювання даних» та «Реляційний аналіз даних».

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

ЛМД. Реляционный анализ обеспечивает глубокий сквозной контроль достоверность ЛМД. На этапах 140(исследование существующих данных) и 320(разработка требуемой модели данных) реляционный анализ используется как неформальный метод анализа имеющейся документации. Кроме того, здесь он также может быть использован для проверки нормализованности ЛСД, а если неизвестна структура данных, то и для разработки первого варианта ЛСД. Формально этот метод используется на этапе 340(совершенствование требуемой модели данных) с целью анализа структур ввода - вывода и сопоставления результатов анализа с разработанной ЛМД требуемой системы

ЕКЗАМЕНАЦІЙНИЙ БІЛЕТ № 5

1. Взаємозв`язок понять потік даних та подія.

.

Связь между потоками данных и событиями

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

В SSADM есть два способа идентификации входных данных в анализируемой системе. Во-первых, потоки данных идентифицируются и изображаются на СПД. Во-вторых, события, которые воздействуют на объекты, определяются при анализе "Истории жизни объекта" и документируются в ИЖО-схемах. Оба способа используют терминологию элементов данных. Суммарный поток данных обычно содержит в себе одно событие или пакет событий. Аналитик, разрабатывающий МПД ТС для обоснования принимаемых решений, должен быть заинтересован в выявлении связей между потоками данных и событиями. Этому обоснованию и решению задачи определения функций системы может помочь следующий перечень правил:

• один поток данных может нести пакет событий ( аналитик, чтобы обеспечить простоту СПД, обычно предпочитает рисовать один входной поток данных, вмещающий в себя пакет событий и отражающий поступающие в систему данные). Такой пакет может быть входом в режимах "он-лайн" или "оф-лайн";

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

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

• события одного типа могут переноситься несколькими потоками данных, но любое конкретное событие должно полностью включаться только в один поток данных;

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

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

2. Взаємозв`язок поміж методами структурного системного аналізу та системного проектування.

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

Среди перечисленных выше методологий одной из наиболее развитых является SSADM (Методология структурного анализа и проектирования систем),

SSADM является ярким примером реального воплощения принципа проектирования "сверху вниз" в технологии создания сложных ИУС. Он сочетает в себе простоту применения системными аналитиками средней квалификации, точность определения результатов проектирования, согласованность с современными стандартами и методологией управления проектными работами (PRINCE), гибкость в применении к проектированию широкого класса систем для различных типов объектов, гарантии качества результатов проектирования и преемственность различных версий проектов. Каркас SSADM описывается структурной моделью, основными элементами которой, в зависимости от уровня иерархии, являются модуль, стадия, этап или задача. Это делает технологию проектирования четкой и ясной, легко автоматизируемой, а также создает предпосылки для привязки методов проектирования к конкретным элементам структуры через так называемые "описания действий". Методическое обеспечение 4-й версии SSADM состоит из 13-ти методов структурного системного анализа и проектирования, объединяемых в одно целое вышеупомянутой структурной моделью.

Структурным анализом принято называть метод исследования системы, который начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней10. Структурный анализ предусматривает разбивку системы на уровни абстракции с ограниченным числом элементов на каждом из уровней (обычно от 3 до 6—7).

Проектирование - фаза ЖЦ, на которой вырабатывается, как реализуются требования пользователя, которые порождены и зафиксированы на фазе анализа

Затверджено на засіданні кафедри СТ

Протокол № _7_ від „_12_”_____12______2018 р.

Зав.кафедри I.В. Гребеннік Екзаменатор С.І.Чайніков

\ХНУРЕ

Спеціалізація –«Інформаційні технології проектування»

«Системне проектування»

Семестр I

Навчальна дисципліна “Методологія та технологія проектування КС”