Структуры данных: несвязанные, с неявными связями, с явными связями; иерархические модели Джексона-Орра; моделирование данных – диаграммы «сущность-связь» (erd); метод Баркера; метод idef1.

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

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

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

В первую группу входят множества и кортежи. Наиболее существенная характеристика элемента данных отношение вхождения. Данные абстрактные структуры используют, если никакие другие отношения элемен¬тов не являются существенными для описываемых объектов.

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

Существуют иерархические и сетевые модели.

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

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

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

Каждая конструкция представляется в виде двухуровневой иерархии, на верхнем уровне - блок конструкции, а на нижнем - блоки элементов. Нотации конструкций различаются специальными символами в правом верхнем углу блоков элементов. В изображении последовательности дополнительный символ отсутствует. В изображении выбора ставится сим¬вол «о» (латинское) - сокращение английского «или» (or). Конструкции по¬следовательности и выбора должны содержать по два или более элементов второго уровня. В изображении повторения в блоке единственного (повторя¬ющегося) элемента ставится символ «*».

РИСУНОК 87-1

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

Скобочная нотация для представления структур д-х Орра:

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

РИСУНОК 87-2

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

• нотация П. Чена;

• нотация Р. Баркера;

• нотация IDEF1 (более соврем. - IDEF1X использ. в CASE-системах, напр. в ERWin).

Нотация Баркера Базовые понятия сетевой модели данных: сущность, атри¬бут и связь.

Сущность — реальный или воображаемый объект, имеющий существен¬ное значение для рассматриваемой предметной области.

Каждая сущность должна:

• иметь уникальное имя;

• обладать 1м или неск-ми атриб-ми, к-е принадлежат сущности, или наследуются через связь;

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

Имя сущности должно отражать тип или класс объекта, а не его конкретный эк¬земпляр (Аэропорт, а не Внуково).

На диаграмме в нотации Баркера сущность изображается прямоуголь¬ником, иногда с закругленными углами. Сущность обладает атрибутами.

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

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

Описательные атрибуты: обязательными (для каждой сущности всегда имеют конкретное зна¬чение, помечают «*») или необязательными (могут быть не определены, помечают «о»).

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

РИСУНОК 87-3

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

Три типа отношений: 1*1 - «один-к-одному»; 1*n - «один-ко-многим; n*m - «многие-ко-многим».

РИСУНОК 87-4

Сущности бывают независимыми, зависимыми и ассоцииро¬ванными. Независимая сущность представляет независимые данные, кото¬рые всегда присутствуют в системе. Они могут быть связаны или не связаны с другими сущ-ми той же системы. Зависимая сущность представляет данные, зависящие от других сущно¬стей системы, поэтому она всегда должна быть связана с другими сущно¬стями.

Ассоциированная сущность представляет данные, которые ассоцииру¬ются с отношениями между двумя и более сущностями. Обычно данный вид сущностей используется в модели для разрешения отношения «многие-ко-многим». Если экземпляр сущности полностью идентифицируется своими клю¬чевыми атрибутами, то говорят о полной идентификации сущности.

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

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

РИСУНОК 87-5

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

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

• каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;

• каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

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

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

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

Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка. Мощность связи обозначается: (по умолчанию - N).

Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией. Сущность-потомок является зависимой от идентификатора сущностью. Сущность-родитель м.б. независимой и зависимой сущностью (опред-тся ее связями с др. сущ0и).

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

Сущности могут иметь также внешние ключи (Foreign Key. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках. (см. Иванова Г.С. Технология разработки программного обеспечения)

89. Структурная и функциональная схемы: структурные схемы пакетов программ, программного комплекса, программной системы; функциональная схема-схема данных, основные обозначения по ГОСТ 19.701-90; проектирование структуры программного обеспечения с использованием метода пошаговой детализации: основное правило и рекомендации по применению; структурные карты Константайна: назначение, типы вызовов модулей - последовательный, параллельный, вызов сопрограммы; особые условия вызова - циклический, условный, однократный; диаграммы реализации параллельного вызова и вызова сопрограммы; типы связи – по данным, по управлению.

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

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

Структурными компонентами программной системы или программного комплекса могут служить программы, подсистемы, базы данных, библиоте¬ки ресурсов и т. п.

Структурная схема ПК демонстри¬рует передачу управления от программы-диспетчера соответствующей про¬грамме.

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

Функциональная схема. Функциональная схема или схема данных - схема взаимодействия компонентов ПО с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств.

Функциональные схемы, более информативны, чем структурные.

РИСУНОК 88-1 - описание жлементов схемы

Использование метода пошаговой детализации для проектирования структуры ПО

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

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

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

Кроме этого, целесообразно. Придерживаться следующих рекомендаций:

• не отделять операции инициализации и завершения от соответствую¬щей обработки, так как модули инициализации и завершения имеют плохую связность (временную) и сильное сцепление (по управлению);

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

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

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

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

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

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

Различают четыре типа вершин (рис. 5.7):

• модуль - подпрограмма,

• подсистема - программа,

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

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

РИСУНОК 88-2

При этом отдельные части программной системы (программы, подпро¬граммы) могут вызываться последовательно, параллельно или как сопро¬граммы

РИСУНОК 88-3

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

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

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

Если стрелка, изображающая вызов, касается блока, то обращение про¬исходит к модулю целиком, а если входит в блок, то - к элементу внутри мо¬дуля.

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

РИСУНОК 88-4

Связи по данным и управлению обозначают стрелками, параллельными дуге вызова, направление стрелки указывает направление связи (рис. 5.11).

Структурные карты Константайна позволяют наглядно представить ре¬зультат декомпозиции программы на модули и оценить ее качество, т. е. со¬ответствие рекомендациям структурного программирования (сцепление и связность).

РИсунок 88-5

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

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

• вид хранимой информации каждого элемента данных;

• связи элементов данных и вложенных структур;

• время хранения данных структуры («время жизни»);

• совокупность операции над элементами данных.

Вид хранимой информации определяет тип соответствующего поля па¬мяти.

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

Представление данных в оперативной памяти. Различают две базо¬вые структуры организации данных в оперативной памяти: векторную и списковую.

Векторная структура представляет собой последовательность байт памяти, которые исполь¬зуются для размещения полей данных (рис. 5.14). Последовательное размещение организованных структур данных позволяет осуществлять прямой доступ к элементам: по индексу (совокупности индексов) - в массивах или строках или по имени поля - в записях или объектах.

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

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

При использовании списковых структур следует помнить, что:

• для хранения указателей необходима дополнительная память;

• поиск в линейных списках последова¬тельный, а потому требует больше времени;

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

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

Представление данных во внешней памяти. Современные операци¬онные системы поддерживают два способа организации данных во внешней памяти: последовательный и с прямым доступом.

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

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

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

• в оперативной памяти размещают данные, к которым необходим быстрый;

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

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

Проектирование ПО, основанное на декомпозиции данных

Методика Джексона основана на поиске соответствий структур исходных данных и результатов. Однако при ее применении возможны ситуации, когда на ка¬ких-то уровнях соответствия отсутствуют. Такие ситуации были названы «столкновениями». Выделяют несколько типов столкновений, которые разрешают по-разному. Их просто сортируют до обра¬ботки.

Разработка структуры программы в соответствии с методикой выполня¬ется так:

• строят изображение структур входных и выходных данных;

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

• формируют структуру программы на основании структур данных и обнаруженных соответствий;

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

• анализируют и обрабатывают несоответствия, т.е. разрешают «столк¬новения»;

• добавляют необходимые операции (ввод, вывод, открытие/закрытие файлов и т. п.);

• записывают программу в структурной нотации (псевдокоде).

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

В методике Джексона предлагается псевдокод, точно соответству¬ющий графической нотации. Он использует следующие конструкции.

Последовательность:

<Имя> Посл.

Выполнить <действие 1>

Выполнить <действие 2>

<Имя> конец

Выбор:

<Имя> Выбор <условие действия 1>

Выполнить <действие 1>

<Имя> или <условие действия 2>

Выполнить <действие 2>

<Имя> конец;

Повторение:

<Имя> Повт, пока не <условие действия>

Выполнить <действие 1>

<Имя> конец

Методика Варнье-Орра базируется на том же положении, что и методика Джексона, но основными при построении про¬граммы считаются структуры выходных данных и, если структуры входных данных не соответствуют структурам выходных, то их допускается менять. Таким образом, ликвидируется основная причина столкновений.

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

Как следует из вышеизложенного, методики Джексона и Варнье-Орра могут использоваться только в том случае, если данные разрабатываемых программ могут быть представлены в виде иерархии или совокупности ие¬рархий. (см. Иванова Г.С. Технология разработки программного обеспечения)

91. Спецификация программного обеспечения при использовании UML: модель использования, логическая модель, модель реализации, модель процессов, модель развертывания; варианты использования: основные, вспомогательные, дополнительные, краткая и подробная формы описания; диаграммы вариантов использования – прецедентов (uses case diagrams): действующее лицо, вариант использования, связь; связи использования и расширения.

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

Таким образом, на этапе анализа ставятся две задачи:

• уточнить требуемое поведение разрабатываемого ПО;

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

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

1995г. - первая версия языка UML (Unified Modeling Language - унифицированный язык моделиро¬вания), который в настоящее время фактически признан стандартным средством описания проектов, создаваемых с использованием объектно-ориентированного подхода. Создатели: Града Буч, Ивар Якобсон и Джеймс Рамбо.

Спецификация разрабатываемого ПО при ис¬пользовании UML объединяет несколько моделей: использования, логичес¬кую, реализации, процессов, развертывания.

Модель использования представляет собой описание функциональности ПО с точки зрения пользователя.

Логическая модель описывает ключевые абстракции ПО (классы, интерфейсы и т. п.), т. е. средства, обеспечивающие требуемую функциональность.

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

Модель процессов отображает организацию вычислений и оперирует по¬нятиями «процессы» и «нити». Она позволяет оценить производительность, масштабируемость и надежность ПО.

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

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

Всего UML предлагает 9 дополняющих друг друга диаграмм, вхо¬дящих в различные модели:

• диаграммы вариантов использования;

• диаграммы классов;

• диаграммы пакетов;

• диаграммы последовательностей действий;

• диаграммы кооперации;

• диаграммы деятельностей;

• диаграммы состояний объектов;

• диаграммы компонентов;

• диаграммы размещения.

Все диаграммы используют единую графи¬ческую нотацию, что облегчает их понимание.

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

Определение «вариантов использования»

Разработку спецификаций ПО начинают с ана¬лиза требований к функциональности, указанных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемого ПО и перечень отдельных аспектов его поведения в про¬цессе взаимодействия с конкретными пользователями. Аспекты поведения ПО были названы «вариантами использования» или «прецедентами» (use cases).

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

Каждый вариант использования связан с некой це¬лью, имеющей самостоятельное значение.

В зависимости от цели выполнения конкретной процедуры различают:

-основные вар. использ. - обеспечивают требуемую функциональность разрабатываемого ПО;

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

-дополнительные - обеспечивают дополнительные удобства для поль¬зователя (реализуются, если не требуют серьезных затрат каких-либо ресурсов ни при разработке, ни при эксплуатации).

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

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

Диаграммы вариантов использования. Диаграммы вариантов исполь¬зования позволяют наглядно представить ожидаемое поведение системы. Основными понятиями:

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

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

Связь - взаимодействие действующих лиц и соответствующих вариан¬тов использования.

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

Использование подразумевает, что существует некоторый фрагмент поведения разрабатываемого ПО, который повторяется в нескольких вариантах использования. Этот фрагмент оформляют, как отдельный вариант использования и указывают связь с ним типа «использова¬ние)».

Расширение применяют, если имеется два подобных варианта использо¬вания, различающиеся наличием в одном из них некоторых дополнительных действий. В этом случае дополнительные действия определяют как отдель¬ный вариант использования, который связан с основным вариантом связью типа «расширение».

Условные обозначения:

Человечек - исполнитель(дейст лицо)

Овал - вариант исп-я

линия- связь

Диаграмма вариантов использования отражает типичное взаимодействие пользователя с разрабатываемым программным обеспечени¬ем. Ее необходимо обсудить с заказчиком для определения как можно боль¬шего числа основных вариантов использования и проанализировать на пол¬ноту обслуживания системы. Чем больше вариантов выявлено в процессе уточнения специфика¬ций, тем лучше. (см. Иванова Г.С. Технология разработки программного обеспечения)

92. Уровни моделирования предметной области: концептуальный, спецификации, реализации; контекстные диаграммы классов (class diagrams); диаграмма последовательностей системы (seguence diagrams), системные события и операции, описание системной операции; диаграммы деятельностей (activity diagrams) этапа анализа требований и уточнения спецификаций.

Диаграммы классов - центральное звено объектно-ориентированных методов разработки ПО, поэтому все существующие методы используют диаграммы классов в одной из известных нотаций. Од¬нако в основном диаграммы классов в этих методах применяют на этапе про¬ектирования, для того чтобы показать особенности построения конкретных классов. В отличие от ранее существовавших нотаций, UML предлагает ис¬пользовать три уровня диаграмм классов в зависимости от степени их дета¬лизации:

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

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

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

Каждую из перечисленных моделей используют на конкретном этапе разработки ПО:

• концептуальную модель - на этапе анализа;

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

• диаграммы классов уровня реализации - на этапе реализации.

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

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

На диаграммах класс изображается в виде прямоугольника, внутри кото¬рого указано имя класса (рис. 6.6, а). При необходимости допускается указы¬вать характеристики класса, например атрибуты, используя специальные секции условного обозначения (рис. 6.6, б).

РИСУНОК 91-1

В качестве атрибутов представляют некоторые, существенные с точки зрения решаемой задачи характеристики объектов, например идентифициру¬ющие значения (имя, номер). Для конкретного объекта атрибут всегда имеет определенное значение. На диаграмме классов атрибуты обычно показывают в секции атрибутов.

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

Отношение ассоциации означает наличие связи между экземплярами классов или объектами, например, класс Студент ассоциирован с классом Институт. Ассоциация может иметь имя, например Обучается. Рядом с именем ассоциации обычно ставят стрелку, указывающую направление чтения имени («Студент обучается в институте», а не наоборот).

Связь между экземплярами клас¬сов подразумевает некоторые роли, которые соответствующие объекты играют по отношению друг к другу. Роль связана с направлением ассоциации. Так по отношению к студентам институт - организация, осуществляющая их обучение, т. е. роль института мож¬но назвать Место учебы. Студент для института - объект обучающей дея¬тельности института, т. е. Обучаемый. Если роль собственного имени не имеет, то можно считать, что ее имя совпадает с именем класса, по отноше¬нию к которому определяется эта роль. Для рассматриваемого примера это соответственно роли Студент и Институт (рис. 6.7, а), но роль можно указать и явно (рис. 6.7, б).

РИСУНОК 91-2

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

* - от 0 до бесконечности;

<целое>.. * - от заданного числа до бесконечности;

<целое> — точно определенное количество объектов;

<целое!>, <целое2> - несколько вариантов точного количества объектов;

<целое1>..<целое2> - диапазон объектов.

Чтобы избежать излишних нагромождений рекомендуется следовать простому правилу [37]: если некоторый объект X в реальном мире не явля¬ется числом или текстом, то это скорее всего понятие. В противном слу¬чае - это атрибут.

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

РИСУНО 91-3

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

• формируют множество понятий-кандидатов из существительных, ха¬рактеризующих предметную область в описании вариантов использования;

• исключают понятия, не существенные для данного варианта использо¬вания, например, в предыдущем примере, «информация», «ввод» и т. п.

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

Описание поведения. Системные события и операции

Концептуальная модель характеризует статические свойства разрабаты¬ваемого ПО. Для описания особенностей его поведе¬ния, т. е. возможных действий системы, целесообразно использовать: диа¬граммы последовательностей системы, системные события, системные опе¬рации, диаграммы деятельностей, а при необходимости и диаграммы состо¬яний объектов.

Диаграмма последовательностей системы. Системные события и операции.

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

Для построения диаграммы последовательностей системы необходимо:

• представить систему как «черный ящик» и изобразить для нее линию жизни - вертикальную пунктирную линию, подходящую к блоку снизу;

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

• из описания варианта использования определить множество систем¬ных событий и их последовательность;

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

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

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

Каждую системную операцию необходимо описать. Обычно описание системной операции содержит:

• имя операции и ее параметры;

• описание обязанности;

• указание типа;

• названия вариантов использования, в которых она используется;

• примечания для разработчиков алгоритмов и т. д.;

• описание обработки возможных исключений;

• описание вывода неинтерфейсных сообщений;

• предположение о состоянии системы до выполнения операции (пре¬дусловие);

• описание изменения состояния системы после выполнения операции

(постусловие).

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

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

Диаграммы деятельностей позволяют описывать альтернативные и па¬раллельные процессы. Для обозначения альтернативных процессов исполь¬зуют ромб, условие указывают над ним слева или справа, а аль¬тернативы «да», «нет» - рядом с соответствующими выходами. С помощью этого же блока можно построить циклический процесс. Множественность активации деятельности обозначают символом «*», помещенным рядом со стрелкой активации деятельности, и при необходимости уточняют надписью вида «для каждой строки».

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

РИСУНОК 91-5

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

93. Проектирование структуры программного обеспечения при объектном подходе: стереотипы классов – классы сущности, классы интерфейсы, управляющие классы, исключения, пакеты классов; диаграмма пакетов (package diagrams).

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

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