Лекция 4

подхода:
принцип "разделяй и властвуй" - принцип решения сложных проблем путем

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

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

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

Исходный документ для процессов:
разработки текстов (проектированию и

кодированию) программ, входящих в ПС;
разработки документации по применению ПС;
разработки существенной части комплекта тестов для тестирования ПС.

спецификация качества ПС+ функциональная спецификация ПС

Спецификация анализа ПС не определяет, каким

образом будут реализованы указанные требования. Это задача этапа проектирования.

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

ПС. Эти требования пишутся на языке, понятном заказчику и чаще всего могут быть неполными;
требования разработчиков. Эти требования согласованы требованиями заказчика и максимально детализированы.

Способы определения требований к ПС:
управляемый пользователем;
контролируемый пользователем;
независимый от пользователя.

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

могут возникнуть в ходе работы ПC, и реакций на эти ситуации;

Structured Analysis and Design Technique);
диаграмм потоков данных (DFD —

Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;
диаграмм «сущность—связь» (ERD Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы;
диаграмм переходов состояний (STD — State Transition Diagrams), характеризующих поведение системы во времени;
спецификаций процессов (могут быть представлены в виде псевдокодов, блок-схем алгоритмов, Flow-форм, диаграмм Насси — Шнейдермана или просто краткого текстового описания);
словаря терминов.

IDEF0-диаграмме функции = блоки, а интерфейсы входа-выхода = дуги, соответственно

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

обратная связь по входу; г — обратная связь по управлению;

д — выход-исполнитель

– уточняющая диаграмма.

функциональные группы — процессы.
2. Выявление внешних объектов, связанных с

разрабатываемой системой.
3. Идентификация основных потоков информации, циркулирующей между системой и внешними объектами.
4. Предварительная разработка контекстной диаграммы.
5. Проверка предварительной контекстной диаграммы и внесение в нее изменений.
6. Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков.
7. Проверка основных требований контекстной диаграммы.
8. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.
9. Проверка основных требований по DFD соответствующего уровня.
10. Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.
11. Проверка полноты и наглядности модели после построения каждых двух-трех уровней.

хранилищ данных. Большинство словарей содержит следующую информацию:
Имя (основное имя элемента

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

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

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

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

экземпляр первой сущности связан точно с одним экземпляром второй сущности.

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

Модальности связей:

иметь несколько детей»;
справа налево: «Ребенок должен принадлежать точно одному

сотруднику».

абстракции архитектурного уровня. Включает три типа деятельности:
Определение структуры ПС. ПС

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

его построения.

Архитектура ПС — это его строение, как оно

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

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

Основные задачи разработки архитектуры ПС:

выделение независимых программных компонентов разрабатываемого ПС;
определение,

какие функции из спецификации анализа ПС будут реализованы в каждой программном компоненте ПС;
определение способов взаимодействия между выделенными программными компонентами ПС.

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

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

многопользовательскую (сетевую) архитектуру.

ПС: в состав ПС входит только одна программа. Такую архитектуру

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

отдельно. Это означает, что каждый программный модуль программируется, компилируется и

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

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

связей скрыто от внешней части программы, тем проще программа и

выше прочность модуля.

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

Логическая связанность.
Временная связанность.
Процедурная связанность.
Коммуникативная связанность.
Информационная связанность.

Функциональная связанность

модулей. Характеризуется способом передачи данных.
Типы сцепления:
Сцепление по содержанию. Один

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

Модуль будем называть рутинным, если результат обращения к нему зависит

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

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

работы;
доступ к подпрограммам и данным модуля ограничен.

Достоинства информационной закрытости:
обеспечивается возможность

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

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

В проектировании модуля можно выделить два основных процесса:
внешнее проектирование модуля;
проектирование логики модуля.

включает в себя следующие сведения:

имя модуля;
объявления подпрограмм (или прототипы функций

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

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

компиляция модуля.