Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ПРОГРАММНАЯ ИНЖЕНЕРИЯ.docx
Скачиваний:
115
Добавлен:
09.09.2018
Размер:
2.83 Mб
Скачать

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. На данном рисунке компонент «Файл» состоит из повторяющихся подкомпонентов «Запись», подкомпонент «Запись» может повторяться от одного до раз. Компонент «Неделя» состоит из повторяющихся семь раз подкомпонентов «День».

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

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

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

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

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

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

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

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

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

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

На проектирование, кодирование и тестирование приходится более 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. Модель абстрактной машины

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

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

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

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

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

  • снаружи он проще, чем внутри;

  • его проще использовать, чем построить.

  1. Виды связности модулей.

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

Связность — внутренняя характеристика модуля. Чем выше связность модуля, тем лучше результат проектирования

а- функциональная; б- последовательная; в- информационная; г- процедурная; д-временная; е- логическая

1.Связность по совпадению - В модуле связь между элементами мала или отсутствует. Такой модуль значительно усложняет процесс разработки и поддержки системы.

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

3. Временная связность - подразумевает, что эти функции выполняются одновременно или в течение некоторого периода времени. Недостаток: сильная взаимная связь с другими модулями, отсюда — сильная чувствительность внесению изменений.

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

Модуль A

  • ОбработкаДанныхА

  • СчитатьДанные

  • ОбработатьДанныеА

  • СохранитьДанные

Конец модуля

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

Модуль

  • Успеваемость студентов

  • Сгенерировать отчет по успеваемости

  • Выдать отстающих студентов

  • Выдать список отличников

Конец модуля

5.Последовательная связность - Выходные данные одной части используются как входные данные в другой части модуля.

Модуль

  • Прием и проверка записи

  • Прочитать запись из файла

  • Проверить контрольные данные

  • Удалить контрольные поля

  • Вернуть обработанную запись

Конец модуля

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

Модуль

  • Шифрование данных +

  • Зашифровать данные +

  • Расшифровать данные –

  • Сформировать набор ключей ...

Конец модуля

  1. Сцепление модулей.

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

Связанность по данным. Коммуникация между модулями происходит исключительно посредством обмена необходимыми элементами данных. Все входные и выходные параметры вызываемого модуля — простые элементы данных.

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

Связанность по управлению. Здесь начинаются проблемы со связанностью. Модуль А явно управляет функционированием модуля В (с помощью флагов или переключателей), посылая ему управляющие данные. Предполагается, что вызывающий модуль “знает” логику работы вызываемого, что уменьшает их независимость.

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

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

  1. Понятие сложности программной системы.

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

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

  • Необходимо соблюдать

  • максимальную степень внутренней связности

  • минимальную степень внешней связанности

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

Таким образом, при комплексной оценке сложности ПС необходимо рассматривать меру сложности модулей ( его длину и объём), меру сложности внешних связей (между модулями) и меру сложности внутренних связей (внутри модулей) [28], [56]. Традиционно со внешними связями сопоставляют характеристику «сцепление», а с внутренними связями — характеристику «связность».

  1. Метод структурного проектирования.

  2. Типы информационных потоков (преобразование, запрос).

Исходными данными для метода структурного проектирования являются компоненты модели анализа ПС, которая представляется иерархией диаграмм потоков данных. Результат структурного проектирования — иерархическая структура ПС. Действия структурного проектирования зависят от типа информационного потока в модели анализа.

Типы информациооных потоков Различают 2 типа информационных потоков: 1) поток преобразований; 2) поток запросов. Как показано на рис. 5.1, в потоке преобразований выделяют 3 элемента: Входящий поток, Преобразуемый поток и Выходящий поток. Потоки запросов имеют в своем составе особые элементы — запросы. Назначение элемента-запроса состоит в том, чтобы запустить поток данных по одному из нескольких путей. Анализ запроса и переключение потока данных на один из путей действий происходит в центре запросов. Структуру потока запроса иллюстрирует рис. 5.2. Рис. 5.1. Элементы потока преобразований Рис. 5.2. Структура потока запроса