для третьего подхода

где УД_СТОИМОСТЬ_анi — метрика стоимости одной строки аналога, взятая из метрического базиса. Пример применения данного процесса оценки приведем ниже.

10. Классические методы анализа.

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

Структурный анализ

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

Метод анализа Джексона

Методы анализа, ориентированные на структуры данных.

11. Структурный анализ.

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

12. Диаграммы потоков данных и их описание.

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

движении от входа к выходу системы. Диаграмма может использоваться для представления программного изделия на любом уровне абстракции. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем,

DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных.

Диаграммы потоков данны (DFD - Data Flow Diagramm) строятся из следующих элементов:

Функция – функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»)

Имя

Функции

Поток данных - Объект, над которым выполняется действие.

Имя объекта

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

---

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

Имя внешнего

объекта

Нотация DFD может описывать любые действия, в том числе, процесс продажи или отгрузки товара, работу с заявками от клиентов или закупки материалов, с точки зрения описания системы. Эта нотация помогает понять, из чего должна состоять система, что нужно для автоматизации бизнес-процесса. Но DFD не является описанием непосредственно бизнес-процесса. Здесь, например, нет такого важного параметра, как время. Также в этой нотации не предусмотрены условия и «развилки». В DFD мы рассматриваем откуда появляются данные, какие данные нужны, их обработку и куда результаты отправить. Т.е. в этой нотации описывается не столько непосредственно процесс, сколько движение потоков данных.

Декомпозиция. В DFD-диаграммах предусмотрена возможность создавать крупные процессы и декомпозировать их на подпроцессы с подробным описанием действий.

DFD-диаграммы активно применяются при разработке программного обеспечения. При этом:

• хранилища данных – это электронные таблицы и базы данных,

• внешние сущности – клиенты или другие базы данных, в том числе, из других программ (интеграция и обмен данными),

• процессы – это выполняемые функции и модули в системе.

Базовые средства диаграммы не обеспечивают полного описания требований к

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

— потоки данных, и преобразователи— процессы. Для этих целей используются словарь требований (данных) и спецификации процессов. Словарь требований

(данных) содержит описания потоков данных и хранилищ данных.

Большинство

словарей

содержит следующую информацию.

1.

Имя (основное имя элемента данных, хранилища или внешнего объекта).

2.Прозвище (Alias) — другие имена того же объекта.

3.Где и как используется объект — список процессов, которые используют данный элемент, с указанием способа использования (ввод в процесс, вывод из процесса, как внешний объект или как память).

4.Описание содержания — запись для представления содержания.

5.Дополнительная информация — дополнительные сведения о

типах данных, допустимых значениях, ограничениях т.д.

Спецификация процесса — это описание преобразователя. Спецификация поясняет: ввод данных в преобразователь, алгоритм обработки, характеристики производительности преобразователя, формируемые результаты.

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

13. Методы анализа, ориентированные на структуры данных.

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

---

Методы, ориентированные на структуры данных, обеспечивают:

1.Определение ключевых информационных объектов и

операций.

2.Определение иерархической структуры данных.

3.Компоновку структур данных из типовых конструкций — последовательности, выбора, повторения.

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

Наиболее известны два метода: метод Варнье–Орра и метод Джексона.

В методе Варнье–Орра для представления структур применяют диаграммы Варнье. Для построения диаграмм Варнье используют три базовых элемента:

последовательность, выбор, повторение

1. Конструкция иерархии данных

Конструкция иерархии данных отражает вложенность некоторых конструкций данных в другие компоненты данных. Графически данные объединяются в конструкцию иерархии с помощью скобки. Вложенность скобок определяет уровень иерархии соответствующих конструкций данных. Пример представления конструкции иерархии данных «Отчет» приведен на рис. 5.51.

На данном рисунке на втором уровне иерархии структуры данных «Отчет» находится конструкция иерархии данных, состоящая из компонентов 1, 2, 3. Компонент 1 представляет собой конструкцию данных, включающую компоненты 4, 5, компонент 3 – конструкцию, содержащую компоненты 6, 7. Компоненты 4 – 7 находятся на третьем уровне иерархии. В состав компонента 5 входят компоненты 8, 9 четвертого уровня иерархии. Данные в каждой из конкретных конструкций иерархии могут быть представлены конструкциями иерархии, последовательности, выбора или повторения.

2. Конструкция последовательности данных

Эта конструкция возникает, когда два или более компонента данных помещаются вместе, строго последовательным образом, и образуют единый компонент данных. Графически последовательные компоненты данных в конструкции последовательности изображаются сверху вниз. На рис. 5.52 приведена структура конструкции данных «Дата». Данная конструкция представляет собой последовательность данных «Число N», «Месяц M», «Год Y». Все конструкции, входящие в состав иерархической конструкции «Отчет» (см. рис. 5.51), представляют собой конструкции последовательности данных

3. Конструкция выбора данных

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

Пример конструкции выбора данных приведен на рис. 5.53. На данном рисунке конструкция «Сезон» представляет собой конструкцию выбора из альтернативных подкомпонентов «Зима W», «Весна P», «Лето S», «Осень A» (сезон представляет собой зиму, весну, лето или осень).

4. Конструкция повторения данных

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

---

Представление повторения данных на диаграммах Варнье–Орра иллюстрирует рис. 5.54. На данном рисунке компонент «Файл» состоит из повторяющихся подкомпонентов «Запись», подкомпонент «Запись» может повторяться от одного до n раз. Компонент «Неделя» состоит из повторяющихся семь раз подкомпонентов «День».

Метод Джексона (1975) включает 6 шагов. Три шага выполняются на этапе анализа, а остальные - на этапе проектирования.

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

2. Объект-структура. Действия над объектами представляются диаграммам Джексона.

3. Начальное моделирование. Объекты и действия представляются как обрабатывающая модель. Определяются связи между моделью и реальным миром.

4. Доопределение функций. Выделяются и описываются сервисные функции.

5. Учет системного времени. Определяются и оцениваются характеристики планирования будущих процессов.

6. Реализация. Согласование с системной средой, разработка аппаратной платформы.

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

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

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

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

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

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

Обычно в проектировании выделяют две ступени: предварительное проектирование и детальное проектирование. Предварительное проектирование формирует абстракции архитектурного уровня, детальное проектирование уточняет эти абстракции, добавляет подробности алгоритмического уровня. Кроме того, во многих случаях выделяют интерфейсное проектирование, цель которого — сформировать графический интерфейс пользователя (GUI). Схема информационных связей процесса проектирования приведена на рис. 4.2.

---

Рис. 4.2. Информационные связи процесса проектирования

Предварительное проектирование обеспечивает:

• идентификацию подсистем;

• определение основных принципов управления подсистемами, взаимодействия подсистем.

Предварительное проектирование включает три типа деятельности:

1. Структурирование системы. Система структурируется на несколько подсистем, где под подсистемой понимается независимый программный компонент. Определяются взаимодействия подсистем.

2. Моделирование управления. Определяется модель связей управления между частями системы.

3. Декомпозиция подсистем на модули. Каждая подсистема разбивается на модули. Определяются типы модулей и межмодульные соединения.

Рассмотрим вопросы структурирования, моделирования и декомпозиции более подробно.

Структурирование системы

Известны четыре модели системного структурирования:

• модель хранилища данных;

• модель клиент-сервер;

• трехуровневая модель;

• модель абстрактной машины.

В модели хранилища данных (рис. 4.3) подсистемы разделяют данные, находящиеся в общей памяти. Как правило, данные образуют БД. Предусматривается система управления этой базой.

Рис. 4.3. Модель хранилища данных

Модель клиент-сервер используется для распределенных систем, где данные распределены по серверам (рис. 4.4). Для передачи данных применяют сетевой протокол, например TCP/IP.

Рис. 4.4. Модель клиент-сервер

Трехуровневая модель является развитием модели клиент-сервер (рис. 4.5).

Рис. 4.5. Трехуровневая модель

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

Преимущества трехуровневой модели:

• упрощается такая модификация уровня, которая не влияет на другие уровни;

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

Модель абстрактной машины отображает многослойную систему (рис. 4.6).

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

Рис. 4.6. Модель абстрактной машины

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

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

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

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

---

Смотрите также файлы

• Рабочая тетрадь по теоретической механике 3.pdf

• Информационные технологии. Лекции.docx

• Инструктаж по технике безопасности на уроках информатики.docx

• Тема 1.1 Основные понятия теории множеств.docx

• ЧМ Контрольная работа 1.docx