Учебное пособие по выполнению и оформлению курсовых, дипломных и квалификационных работ москва 2002 2 аннотация
 Скачать 0.53 Mb.
|
|
Диаграммы отношений компонентов данных Диаграммы отношений компонентов данных в отличие от функциональных диа- грамм предназначены для определения спецификаций структур данных программы. Структурой данных называют совокупность правил и ограничений, которые отра- жают связи, существующие между отдельными частями (элементами) данных. Разли- чают абстрактные структуры данных, используемые для уточнения связей между элементами, и конкретные структуры, применяемые для представления данных в про- граммах. Абстрактные структуры можно разделить на три группы: структуры, элементы ко- торых не связаны между собой (множества, кортежи), структуры с неявными связями элементов (таблицы, структуры) и структуры, связь элементов которых указывается явно (графы). Очень существенно, что в реальности возможно вложение структур дан- ных, в том числе и разных типов, поэтому для их описания могут потребоваться специ- альные модели. В зависимости от описываемых типов отношений, модели структур данных принято делить на иерархические и сетевые. Иерархические модели позволяют описывать упорядоченные или неупорядоченные отношение вхождения элементов данных в компонент более высокого уровня, т.е. множества, таблицы и их комбинации. К иерархическим моделям относят модель Джексона-Орра, для графического представления которой могут использоваться: * диаграммы Джексона, предложенные в составе методики проектирования ПО то- го же автора в 1975 г.; * скобочные диаграммы Орра, предложенные в составе методики проектирования ПО Варнье-Орра (1974 г.). Сетевые модели основаны на графах, а потому позволяют описывать связность взаимодействующих компонентов независимо от вида отношения, в том числе комби- нации множеств, таблиц и графов. Примером сетевой модели является модель «сущ- ность-связь» (ER – Entity-Relationship), обычно используемую при разработке баз дан- ных. Диаграммы Джексона и Орра. Восноведиаграмм Джексона и диаграмм Орра лежит предположение о том, что структуры данных, так же как и программ, можно строить из элементов с использованием всего трех основных конструкций: последова- тельности, выбора и повторения. 22 В нотации Джексона каждая конструкция представляется в виде двухуровневой ие- рархии, на верхнем уровне которой расположен блок конструкции, а на нижнем – бло- ки элементов. Нотации конструкций различаются специальными символами в правом верхнем углу блоков элементов. В изображении последовательности символ отсутству- ет. В изображении выбора ставится символ «о» (латинское) – сокращение английского «или» (or). Конструкции последовательности и выбора должны содержать по два или более элементов второго уровня. В изображении повторения в блоке единственного (повторяющегося) элемента ставится символ «*». Так схема, показанная на рис. 3.12, а, означает, что конструкция А состоит из эле- ментов В, С и D, следующих в указанном порядке. Схема на рис. 3.12, б означает, что конструкция S состоит либо из элемента P, либо из элемента Q, либо из элемента R. Схема, изображенная на рис. 3.12, в, показывает, что конструкция I состоит из 0 или более элементов X. В том случае, если необходимо показать, что конструкция повторения должна включать 1 или более элементов, используют комбинацию из двух структур последова- тельности и повторения (рис. 3.13). Отличие диаграмм Орра – в нотации. Автор предлагает для представления основ- ных конструкций данных использовать фигурные скобки (рис. 3.14). Пример 3.4. Рассмотрим описание структуры данных файла «Электронная ведо- мость», содержащего сведения о сдаче экзаменов студентами. Файл состоит из записей о результатах сдачи сессии студентами одной группы. Он имеет следующую структу- ру: номер группы, затем записи об успеваемости студентов (ФИО студента, затем на- звание предмета и оценка, полученная студентом, в завершении записи специальный символ «конец записи») и специальный символ «конец файла». На рис. 3.15 показано, как выглядит описание данной структуры с использованием диаграммы Джексона. Сетевая модель данных. Сетевыемодели данных используют в тех случаях, если отношение между компонентами данных не исчерпываются включением. Для графиче- ского представления разновидностей этой модели используют несколько нотаций. Наи- более известными являются: нотация П. Чена, нотация Р. Баркера и нотация IDEF1 (бо- лее современный вариант этой нотации – IDEFIX используется в CASE-системах, на- пример, ERWin). 23 Нотация Баркера является наиболее распространенной. Далее в настоящем разделе будем придерживаться именно этой нотации. Базовыми понятиями сетевой модели данных являются: сущность, атрибут и связь. Сущность – реальный или воображаемый объект, имеющий существенное значе- ние для рассматриваемой предметной области. Каждая сущность должна: * иметь уникальное имя, * обладать одним или несколькими атрибутами, которые либо принадлежат сущно- сти, либо наследуются через связь; * обладать одним или несколькими атрибутами, которые однозначно идентифици- руют каждый экземпляр сущности. Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, предметов и т.п.). Имя сущности должно отра- жать тип или класс объекта, а не его конкретный экземпляр (Аэропорт, а не Внуково). На диаграмме в нотации Баркера сущность изображается прямоугольником, ино- гда, с закругленными углами (рис. 3.16, а). Каждая сущность обладает одним или несколькими атрибутами. Атрибут – любая характеристика сущности, значимая для рассматриваемой предметной области и пред- назначенная для квалификации, идентификации, классификации, количественной ха- рактеристики или выражения состояния сущности (рис. 3.16, б). В сетевой модели атрибуты ассоциируются с конкретными сущностями, и, соот- ветственно, экземпляр сущности должен обладать единственным определенным значе- нием для ассоциированного атрибута. Атрибут, таким образом, представляет собой не- который тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов. Экземпляр атрибута – определенная характеристика конкретно- го экземпляра сущности. Он определяется типом характеристики и ее значением, назы- ваемым значением атрибута. Атрибуты делятся на ключевые, т.е. входящие в состав уникального идентифика- тора, который называют первичным ключом, и описательные – прочие. Первичный ключ – это атрибут или совокупность атрибутов и/или связей, предна- значенная для уникальной идентификации каждого экземпляра сущности (совокуп- ность признаков, позволяющих идентифицировать объект). Ключевые атрибуты поме- щают в начало списка и помечают символом «#» (рис. 3.16, в). 24 Описательные атрибуты могут быть обязательными или необязательными. Обяза- тельные атрибуты для каждой сущности всегда имеют конкретное значение, необяза- тельные – могут быть не определены. Обязательные и необязательные описательные атрибуты помечают символами «*» и «о» соответственно. Для сущностей определено понятие супертип и подтип. Супертип – сущность, обобщающая некую группу сущностей (подтипов). Он характеризуется общими для подтипов атрибутами и отношениями. Например, супертип «учащийся» обобщает под- типы «школьник» и «студент» (рис. 3.17). Связь – поименованная ассоциация между двумя или более сущностями, значимая для рассматриваемой предметной области. Связь, таким образом, означает, что каждый экземпляр одной сущности ассоциирован с произвольным (в том числе и нулевым) ко- личеством экземпляров второй сущности и наоборот. Если любой экземпляр одной сущности связан хотя бы с одним экземпляром другой сущности, то связь является обя- зательной (рис. 3.18, а). Необязательная связь представляет собой условное отношение между сущностями (рис. 3.18, б). Каждая сущность может обладать любым количеством связей с другими сущно- стями модели. Связь предполагает некоторое отношение сущностей, которое характе- ризуется количеством экземпляров сущности, участвующих в связи с каждой стороны. Различают три типа отношений: 1*1 – «один-к-одному»; 1*n – «один-ко-многим»; n*m – «многие-ко-многим» (рис. 3.19). Кроме того сущности бывают независимые, зависимые и ассоциированные сущно- сти. Независимая сущность представляет независимые данные, которые всегда присут- ствуют в системе. Они могут быть, как связаны с другими сущностями, так и нет. Зависимая сущность представляет данные, зависящие от других сущностей систе- мы, поэтому она всегда должна быть связана с другими сущностями. Ассоциированная сущность представляет данные, которые ассоциируются с отно- шениями между двумя и более сущностями. Обычно данный вид сущностей появляется в модели для разрешения отношения «многие-ко-многим» (рис. 3.20). Если экземпляр сущности полностью идентифицируется своими ключевыми атри- бутами, то говорят о полной идентификации сущности. В противном случае идентифи- кация сущности осуществляется с использованием атрибутов связанной сущности, что указывается черточкой на линии связи (рис. 3.21). 25 Пример 3.5. Рассмотрим структуру базы данных для системы учета успеваемости студентов. Основными сущностями для решения указанной задачи являются: * «Студент»; * «Предмет» (изучаемый учебный курс). Отношение между ними относится к типу «многие-ко-многим». Для разрешения этого отношения введем ассоциированную сущность «Экзамен/Зачет», которая отража- ет текущее выполнение предметов учебного плана студентом. Предметы, которые изучает и по которым отчитывается студент, запланированы кафедрой в учебном плане. Учебный план включает список предметов каждого семест- ра (сущность «Семестр»). Для получения справок различного рода потребуются сущности, определяющие структуру организации: * «Факультет»; * «Курс» (как совокупность студентов, поступивших в институт в одном году); * «Кафедра»; * «Группа». Для определения момента времени, начиная с которого отсутствие положительных результатов сдачи экзамена следует считать задолженностью, необходимо хранить да- ты экзаменов для каждой группы (сущность «Дата экзамена»). На рис. 3.22 показаны основные отношения между указанными сущностями. На следующем шаге определяем атрибуты каждой сущности и уточняем их типы (атрибуты, используемые для дополнительной идентификации сущности другой сущ- ностью, не указаны, так как они описаны в соответствующей сущности). Факультет: * DepID – уникальное имя факультета (ключевое поле); * DepName – название факультета. Курс: * CursID – уникальное имя кафедры (ключевое поле); * EnterYear – год начала обучения для большинства студентов курса. Кафедра: * SpecID – уникальное имя кафедры (ключевое поле); * SpecName – название кафедры. Семестр: 26 * SemestrID – уникальное имя семестра обучения на конкретной кафедре (ключевое поле); * SemName – название семестра обучения на кафедре. Группа: * GroupID – уникальное имя группы (ключевое поле); * GroupName – название группы. Предмет: * SubjectID – уникальное имя предмета (ключевой атрибут); * SubjectName – название предмета; * ExamKind – вид оценки знаний (необязательный атрибут): экза- мен/зачет/экзамен+зачет. Дата экзамена: * Date – дата экзамена; * AudNumber – номер аудитории. Студент: * StudentID – уникальное имя студента (ключевое поле); * SerName – фамилия; * FirstName – имя; * SecondName – отчество; * StEnterYear – год поступления в институт. Экзамен/Зачет: * Date – дата сдачи экзамена или зачета; * ExemType – тип (экзамен или зачет); * Mark – оценка. Полученная диаграмма «сущность-связь» приведена на рис. 3.23. Данная диаграмма должна быть проверена с точки зрения возможности получения всех справок, указанных в техническом задании или показанных на диаграмме потоков данных разрабатываемой системы (рис. 3.10). 27 4. ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ СТРУКТУРНОМ ПОДХОДЕ Разработка структурной и функциональной схем Процесс проектирования сложного ПО начинают с уточнения его структуры, т.е. определения структурных компонентов и связей между ними. Результат уточнения структуры может быть представлен в виде структурной и/или функциональной схем. Структурная схема разрабатываемого ПО. Структурной называют схему, отра- жающую состав и взаимодействие по управлению частей разрабатываемого ПО. Самый простой вид ПО – программа в качестве структурных компонентов может включать только подпрограммы и библиотеки ресурсов. Разработка структурной схемы программы обычно выполняется методом пошаговой детализации (см. § 4.2). Структурными компонентами программной системы или программного комплекса могут служить программы, подсистемы, базы данных, библиотеки ресурсов и т. п. Так структурная схема программной системы, как правило, показывает наличие подсистем или других структурных компонентов (рис. 4.1). Более полное представление о проектируемом ПО с точки зрения взаимодействия его компонентов между собой и с внешней средой дает функциональная схема. Функциональная схема. Функциональная схема или схема данных (ГОСТ 19.701– 90) – схема взаимодействия компонентов ПО с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изобра- жения функциональных схем используют специальные обозначения, установленные стандартом. Функциональные схемы более информативны, чем структурные. Так функцио- нальные схемы программных комплексов и систем наглядно демонстрируют различие между ними (рис. 4.2). Все компоненты структурных и функциональных схем должны быть описаны. При структурном подходе особенно тщательно необходимо прорабатывать спецификации межпрограммных интерфейсов, так как от качества их описания зависит количество самых дорогостоящих ошибок. К самым дорогим при структурном подходе относятся ошибки, обнаруживаемые при комплексном тестировании, так как для их устранения могут потребоваться серьезные изменения уже отлаженных текстов. 28 Использование метода пошаговой детализации для проектирования структуры программного обеспечения Структурный подход предлагает осуществлять декомпозицию программ методом пошаговой детализации. Результат декомпозиции – структурная схема программы – представляет собой многоуровневую иерархическую схему взаимодействия подпро- грамм по управлению. Минимально такая схема отображает два уровня иерархии, т.е. показывает общую структуру программы. Однако тот же метод позволяет получить структурные схемы с большим количеством уровней. Метод пошаговой детализации реализует нисходящий подход и базируется на ос- новных конструкциях структурного программирования. Он предполагает пошаговую разработку алгоритма. Каждый шаг при этом включает разложение функции на под- функции. Так на первом этапе описывают решение поставленной задачи, выделяя об- щие подзадачи. На следующем аналогично описывают решение подзадач, формулируя уже подзадачи следующего уровня. Таким образом, на каждом шаге происходит уточ- нение функций проектируемого ПО. Процесс продолжают, пока не доходят до подза- дач, алгоритмы решения которых очевидны. Декомпозируя программу методом пошаговой детализации следует придерживать- ся основного п р а в и л а структурной декомпозиции, следующего из принципа верти- кального управления: в первую очередь детализировать управляющие процессы деком- позируемого компонента, оставляя уточнение операций с данными напоследок. Кроме этого целесообразно придерживаться следующих рекомендаций: * не отделять операции инициализации и завершения от соответствующей обработ- ки, так как модули инициализации и завершения имеют плохую связность (временную) и сильное сцепление (по управлению); * не проектировать слишком специализированных или слишком универсальных модулей, так как проектирование излишне специальных модулей увеличивает их коли- чество, а проектирование излишне универсальных модулей – увеличивает их слож- ность; * избегать дублирования действий в различных модулях, так как при их изменении исправления придется вносить во все места, где они выполняются – в этом случае целе- сообразно просто реализовать эти действия в отдельном модуле; 29 * группировать сообщения об ошибках в один модуль по типу библиотеки ресур- сов, тогда будет легче согласовать формулировки, избежать дублирования сообщений, а также перевести сообщения на другой язык. При этом, описывая решение каждой задачи, желательно использовать не более одной-двух структурных управляющих конструкций, таких как цикл-пока или ветвле- ние, что позволяет четче представить себе структуру организуемого вычислительного процесса. Пример 4.1. Разработать алгоритм программы построения графиков функций од- ной переменной на заданном интервале изменения аргумента [x 1 , x 2 ] при условии не- прерывности функции на всем интервале определения. В общем виде задача построения графика функции ставится как задача отображе- ния реального графика (рис. 4.3, а), выполненного в некотором масштабе, в соответст- вующее изображение в окне на экране (рис. 4.3, б). Для того чтобы построить график необходимо задать функцию, интервал измене- ния аргумента [x1, x2], на котором функция непрерывна, количество точек графика n, размер и положение окна экрана, в котором необходимо построить график: wx1, wy1, wx2, wy2 и количество линий сетки по горизонтали и вертикали nlx, nly. Значения wx1, wy1, wx2, wy2, nlx, nly можно задать, исходя из размера экрана, а интервал и число то- чек графика надо вводить. Разработку алгоритма выполняем методом пошаговой детализации, используя для его документирования псевдокод. Примем, что программа будет взаимодействовать с пользователем через традици- онное иерархическое меню, которое содержит пункты: «Формула», «Отрезок», «Шаг», «Вид результата» и «Выход». Для каждого пункта этого меню необходимо реализовать сценарий, предусмотренный в техническом задании. Шаг 1. Определяем структуру управляющей программы, которая для нашего слу- чая реализует работу с меню через клавиатуру: Программа. Инициализировать глобальные переменные Вывести заголовок и меню Выполнять Если выбрана Команда то Выполнить Команду 30 иначе Обработать нажатие клавиш управления Все-если до Команда=Выход Конец. Очистка экрана, вывод заголовка и меню, а также выбор Команды – операции сравнительно простые, следовательно, их можно не детализировать. Шаг 2. Детализируем операцию Выполнить команду: Выполнить Команду: Выбор Команда Функция: Ввести или выбрать формулу Fun Выполнить разбор формулы Отрезок: Ввести значения x1,x2 Шаг: Ввести значение h Вид результата: Ввести вид_результата Выполнить: Рассчитать таблицу значений функции. Если Вид_результата=График то Построить график иначе Вывести таблицу все-если Все-выбор Определим, какие фрагменты имеет смысл реализовать в виде подпрограмм. Во- первых, фрагмент Вывод заголовка и меню, так как это достаточно длинная линейная последовательность операторов и ее выделение в отдельную процедуру позволит со- кратить управляющую программу. Во-вторых, фрагменты Разбор формулы, Расчет зна- чений функции, Построение графика и Вывод таблицы, так как это достаточно слож- ные операции. Это – подпрограммы первого уровня, которые в основном определяют структуру программы (рис. 4.4). 31 Определим для этих подпрограмм интерфейсы по данным с основной программой, т.е. в данном случае списки параметров. Подпрограмма Вывод заголовка и меню параметров не имеет. Подпрограмма Разбор формулы должна иметь два параметра: Fun – аналитическое задание функции, Tree – возвращаемый параметр – адрес дерева разбора. Подпрограмма Расчет Значений функции должна получать адрес дерева разбора Tree, отрезок x1 и x2, а также шаг h. Обратно в программу она должна возвращать таб- лицу значений функции X(n) и Y(n), где n – количество точек функции. Подпрограммы Вывода таблицы и Построения графика должны получать таблицу значений функции и количество точек. После уточнения имен переменных алгоритм основной программы будет выгля- деть следующим образом: Программа. Вывод заголовка и меню Выполнять Если выбрана Команда то Выбор Команда Функция: Ввести или выбрать формулу Fun Разбор формулы (Fun; Var Tree) Отрезок: Ввести значения x1,x2 Шаг: Ввести значения h Вид результата: Ввести Вид_результата Выполнить: Расчет таблицы(x1,x2,h,Tree; Var X, Y, n) Если Вид_результата=График то Построение графика(X, Y, n) иначе Вывеод таблицы(X, Y, n) все-если 32 Все-выбор иначе Обработать нажатие клавиш управления Все-если до Команда=Выход Конец. На следующих шагах необходимо выполнить детализацию алгоритмов подпро- грамм. Детализацию выполняют, пока алгоритм программы не станет полностью поня- тен. Один из возможных вариантов полной структурной схемы данной программы по- казан на рис. 4.5. Использование метода пошаговой детализации при проектировании алгоритмов программ обеспечивает высокий уровень технологичности разрабатываемого ПО, так как метод позволяет использовать только структурные способы передачи управления. Разбиение на модули при данном виде проектирования выполняется эвристически, исходя из рекомендуемых размеров модулей (20-60 строк) и сложности структуры (две- три вложенных управляющих конструкции). Определяющую роль при разбиении про- граммы на модули играют принципы обеспечения технологичности модулей. Для анализа технологичности полученной иерархии модулей целесообразно ис- пользовать структурные карты Константайна или Джексона. Структурные карты Константайна На структурной карте отношения между модулями представляют в виде графа, вершинам которого соответствуют модули и общие области данных, а дугам – межмо- дульные вызовы и обращения к общим областям данных. Различают четыре типа вершин: * модуль – подпрограмма; * подсистема – программа; * библиотека – совокупность подпрограмм, размещенных в отдельном модуле; * область данных – специальным образом оформленная совокупность данных, к которой возможно обращение извне. Обозначения соответствующих вершин приведены на рис. 4.6. (Обозначения даны в соответствии со стандартами IBM, ISO и ANSI.) Если стрелка, изображающая вызов касается блока, то обращение происходит к модулю целиком, а если входит в блок, то – к элементу внутри модуля. 33 При необходимости на структурной карте можно уточнить особые условия вызова: циклический вызов (рис. 4.7, а), условный вызов (рис. 4.7, б) и однократный вызов – при повторном вызове основного модуля однократно вызываемый модуль не активизи- руется (рис. 4.7, в). Связи по данным и управлению обозначают стрелками, параллельными дуге вызо- ва, причем направление стрелки указывает направление связи (рис. 4.8). Структурные карты Константайна позволяют наглядно представить результат де- композиции программы на модули и оценить ее качество, т.е. соответствие рекоменда- циям структурного программирования. Пример 4.2. Представим в виде структурной карты Константайна полную струк- турную схему, полученную в предыдущем примере (рис. 4.5). Подпрограммы Очистка окна, Вывод прямоугольника, Вывод строки текста, Вывод отрезка прямой, Задание цвета рисования и Задания цвета фона являются частью биб- лиотеки графических примитивов практически в любой среде программирования уни- версального языка, поэтому их включать в структурную карту не будем. Для остальных подпрограмм покажем особые условия вызова и типы связей (рис. 4.9). Модули Расчет значений функции, Вывод таблицы и Построение графика связаны с основной программой по образцу, так как параметры X и Y структурные (массивы), следовательно, программа считается сцепленной по образцу. Примечание. Анализ показывает, что количество сцеплений по образцу в програм- ме можно уменьшить, если подпрограмму Расчет значений функции перенести на сле- дующий уровень и вызывать из функций Вывод таблицы и Построение графика. Одна- ко в этом случае мы при смене вида результата лишний раз будем считать таблицу зна- чений. Аналогично можно перенести Разбор формулы на более низкий уровень и вызы- вать ее, например, из подпрограммы Расчет значений функции, но поскольку велика вероятность многократного расчета значений одной функции на разных интервалах, вряд ли это целесообразно. После внесения соответствующих изменений в алгоритм следует определить пол- ную спецификацию модулей. Спецификация должна включать: имя, краткое описание назначения, перечень входных и выходных параметров с указанием типа и области до- 34 пустимых входных и выходных значений. Затем можно приступать к реализации моду- лей. В соответствии с требованиями нисходящей разработки (комбинированный под- ход) можно предложить следующий порядок реализации модулей: Основная программа – Вывод окна с текстом – Вывод заголовка и меню – Разбор формулы – Расчет значе- ний функции – Вывод таблицы – Построение графика. В завершении этого этапа необходимо убедиться, что разработанная иерархия кор- ректно реализует спецификации проектируемой системы. 5. АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ ОБЪЕКТНОМ ПОДХОДЕ UML – стандартный язык описания разработки программных продуктов с ис- пользование объектного подхода Модели разрабатываемого ПО при объектном подходе основаны на предметах и явлениях реального мира. В основе всех моделей лежит описание требуемого поведе- ния разрабатываемого ПО, т.е. его функциональности, но это поведение связывается с состояниями элементов (объектов) конкретной предметной области. Таким образом, на этапе анализа ставятся две задачи: * уточнить требуемое поведение разрабатываемого ПО; * разработать концептуальную модель его предметной области с точки зрения поставленных задач. В основе объектного подхода к разработке ПО лежит объектная декомпозиция, т.е. представлении разрабатываемого ПО в виде совокупности объектов, в процессе взаи- модействия которых посредством передачи сообщений и происходит выполнение тре- буемых функций (рис. 5.1). Разрабатываемое с помощью объектного подхода программное обеспечение, как правило, очень сложно, поэтому для описания разработки в настоящее время исполь- зуют специальный язык – универсальный язык моделирования UML. Этот язык, авто- рами которого являются Г. Буч, Д. Рамбо и А. Джакобсон [1], недавно был признан стандартным средством описания объектных разработок. Полное описание разработки с использованием UML включает несколько моделей, характеризующих определенный аспект проектируемой системы (рис. 5.2): 35 • модель использования – представляет собой описание функциональности ПО с точки зрения пользователя; • логическая модель – описывает ключевые абстракции ПО (классы, интерфейсы, и т.п.), т.е. средства, обеспечивающие требуемую функциональность; • модель реализации – определяет реальную организацию программных модулей; • модель процессов – отображает организацию вычислений и оперирует понятия- ми «процессы» и «нити». Она позволяет оценить производительность, масштабируе- мость и надежность ПО; • модель развертывания – показывает особенности размещения программных компонентов на конкретном оборудовании. Всего UML предлагает девять дополняющих друг друга диаграмм, входящих в раз- личные модели: * диаграммы вариантов использования; * диаграммы классов; * диаграммы пакетов: * диаграммы последовательностей действий; * диаграммы кооперации: * диаграммы деятельностей: * диаграммы состояний объектов: * диаграммы компонентов: * диаграммы размещения. Полная спецификация разрабатываемого ПО, помимо указанных диаграмм, как и при структурном подходе, обязательно включает словарь терминов и различного рода описания и текстовые спецификации. Конкретный набор документации определяется разработчиком. UML и предлагаемая теми же авторами методика разработки ПО названная Rational Unified Process поддерживаются пакетом Rational Rose фирмы Rational Software Corporation. Ряд диаграмм можно получить также средствами программы Microsoft Visual Modeler и других CASE-средств. Определение вариантов использования Разработку спецификаций начинают с анализа требований к функциональности, указанных в техническом задании. В процессе этого анализа выявляют внешних поль- 36 зователей разрабатываемого ПО и перечень отдельных аспектов его поведения в про- цессе взаимодействия с конкретными пользователями. Аспекты поведения ПО были названы «вариантами использования» или «прецедентами» (use cases). Вариант использования представляет собой характерную процедуру применения разрабатываемой системы конкретным действующим лицом, в качестве которого могут выступать не только люди, но и другие системы и устройства. Не следует путать вариант использования с конкретными операциями будущей системы. Каждый вариант использования связан с некоторой целью, имеющей само- стоятельное значение, например, для текстового редактора Формирование оглавления – это вариант использования, а Связывание заголовков со специальными стилями – опе- рация, которую необходимо выполнить, чтобы стало возможно автоматическое по- строение оглавления. В зависимости от цели выполнения процедуры различают следующие варианты использования: * основные – обеспечивают требуемую функциональность разрабатываемого ПО; * вспомогательные – обеспечивают выполнение необходимых настроек системы и ее обслуживание (например, архивирование информации и т.п.); * дополнительные – обеспечивают дополнительные удобства для пользователя (как правило, реализуются в том случае, если не требуют серьезных затрат каких-либо ре- сурсов ни при разработке, ни при эксплуатации). В зависимости от уровня абстракции вариант использования может описываться кратко или более подробно. Краткая форма описания содержит: название варианта ис- пользования, его цель, действующих лиц, тип варианта использования (основная, вто- ростепенная или дополнительная) и его краткое описание. Ниже приведено краткое описание варианта использование Выполнение задания системы решения комбинатор- но-оптимизационных задач. Предполагается, что эта система должна обеспечивать возможность решения нескольких комбинаторно-оптимизационных задач на графах (задачи коммивояжера, задачи определения кратчайшего пути и т.п.) разными алгорит- мами и хранить в базе данных исходные данные и результаты. Название варианта Выполнение задания Цель Получение результатов решения задачи Действующие лица Пользователь 37 Краткое описание Решение задачи предполагает выбор задачи, выбор ал- горитма, задание данных и получение результатов решения. Тип Основной Основные варианты использования обычно описывают подробно, стараясь отра- зить особенности предметной области разрабатываемого ПО. Подробная форма, кроме указанной выше информации, включает описание типичного хода событий и возмож- ных альтернатив. Типичный ход событий представляют в виде диалога между пользо- вателями и системой, последовательно нумеруя события. Если пользователь может вы- бирать варианты, то их описывают в отдельных таблицах. Также отдельно приводят альтернативы, связанные с нарушением типичного хода событий. Например: Вариант использования Выполнение задания Типичный ход событий Действия исполнителя Отклик системы 1. Пользователь инициирует новое задание 2. Система регистрирует новое задание и предлагает список типов задач 3. Пользователь выбирает тип за- дачи. 4. Система регистрирует тип задачи и предлагает список способов задания данных 5. Пользователь выбирает способ задания данных. а) Если выбран ввод с клавиатуры, см. раздел Ввод данных. б) Если выбран ввод из базы данных, см. раздел Выбор данных из базы 6. Система регистрирует данные и предла- гает список алгоритмов решения 7. Пользователь выбирает алго- ритм 8. Система регистрирует алгоритм и пред- лагает начать решение 9. Пользователь инициирует про- цесс решения 10. Система запускает подпрограмму реше- ния задачи 11. Пользователь ожидает 12. Система демонстрирует результаты и предлагает сохранить их в базе 13. Пользователь анализирует ре- 14. Если выбрано сохранение данных, то си- 38 зультаты и выбирает, сохранять их в базе или нет система выполняет запись данных задания в базу 15. Система переходит в состояние ожида- ния Альтернатива: 10. Если время выполнения программы с точки зрения пользователя велико, то он прерывает процесс выполнения. 11. Система прерывает расчеты, предлагает список алгоритмов решения и воз- вращается на шаг 7. Дополнительная информация. 1. Необходимо обеспечить произвольную последовательность выбора типа задачи, данных и алгоритма. 2. Необходимо обеспечить возможность выхода из варианта на любом этапе. Раздел Ввод данных Типичный ход событий Действия исполнителя Отклик системы 1. Пользователь выбрал Ввод дан- ных. 2. Система последовательно запрашива- ет ввод данных. 3. Пользователь вводит данные. 4. Система проверяет данные и запраши- вает, сохранять ли данные в базе. 5. Пользователь отвечает на за- прос. 6. Если выбран вариант сохранения дан- ных, то система выполняет запись дан- ных в базу и регистрирует их в текущем задании. Альтернатива: 4. Если обнаружены некорректные данные, то система выдает сообщение об ошибке с диагностикой и предлагает их исправить, возвращаясь на предыдущий шаг. 39 Раздел Выбор данных из базы Типичный ход событий Действия исполнителя Отклик системы 1. Пользователь выбрал Выбор дан- ных из базы 2. Система демонстрирует список дан- ных в базе. 3. Пользователь выбирает данные. 4. Система читает данные и регистри- рует их в текущем задании. Диаграммы вариантов использования. Диаграммы вариантов использования по- зволяют наглядно представить ожидаемое поведение системы. Основными понятиями диаграмм вариантов использования являются: действующее лицо, вариант использования, связь. Действующее лицо – внешняя по отношению к разрабатываемому ПО сущность, которая взаимодействует с ним с целью получения или предоставления какой-либо ин- формации. Как уже упоминалось выше, действующими лицами могут быть пользова- тели, другое ПО или какие-либо технические средства, взаимодействующее с разраба- тываемым ПО. Вариант использования – некоторая очевидная для действующего лица процедура, решающая его конкретную задачу. Все варианты использования, так или иначе, связа- ны с требованиями к функциональности разрабатываемой системы и могут сильно от- личаться по объему выполняемой работы. Связь – взаимодействие действующих лиц и соответствующих вариантов использо- вания. Варианты использования также могут быть связаны между собой. При этом фик- сируют связи использования и расширения. Использование подразумевает, что существует некоторый фрагмент поведения раз- рабатываемого ПО, который повторяется в нескольких вариантах использования. Этот фрагмент оформляют, как отдельный вариант использования и указывают связь с ним типа «использование». Расширение применяют, если имеется два подобных варианта использования, раз- личающиеся наличием в одном из них некоторых дополнительных действий. В этом 40 случае дополнительные действия определяют как отдельный вариант использования, который связан с основным вариантом связью типа «расширение». На рис. 5.3 приведены условные обозначения, которые применяют при изображе- нии диаграмм вариантов использования. Пример 5.1.Построить диаграмму вариантов использования для системы решения комбинаторно-оптимизационных задач. Действующее лицо у данной системы одно – Пользователь, который по сути дела обращается к системе либо для решения новой задачи, либо для просмотра результатов ранее решенной задачи, которые должны сохраняться в базе данных. Представим эти варианты использования на диаграмме. Вариант Выполнение задания на самом деле включает несколько вариантов, кото- рые различаются способом определения данных (ввод с клавиатуры или чтение из ба- зы), и сохранением введенных данных в базе. Изобразим эти варианты на схеме, указав соответствующие расширения данного варианта. Помимо двух основных вариантов использования система должна также преду- сматривать вспомогательные варианты использования для удаления лишних данных и результатов из базы. Полученная диаграмма показана на рис. 5.4. Естественно все варианты использования определить, как правило, не удается: но- вые варианты фиксируют постоянно, даже в процессе эксплуатации. Но, чем больше вариантов выявлено в процессе уточнения спецификаций, тем лучше, так как при этом мы получаем более точную модель предметной области, что уменьшает вероятность ее пересмотра при добавлении функций. Построение концептуальной модели предметной области Диаграммы классов – центральное звено объектно-ориентированных методов раз- работки ПО, поэтому все существующие методы используют диаграммы классов в од- ной из известных нотаций. Однако в основном диаграммы классов в этих методах при- меняют на этапе проектирования для того, чтобы показать особенности построения конкретных классов. В отличие от ранее существующих нотаций UML предлагает ис- пользовать три уровня диаграмм классов в зависимости от степени их детализации: 41 * концептуальный уровень, на котором диаграммы классов, называемые в этом случае контекстными, демонстрируют связи между основными понятиями предмет- ной области; * уровень спецификаций, на котором диаграммы классов отображают интерфейсы классов предметной области, т.е. связи объектов этих классов; * уровень реализации, на котором диаграммы классов непосредственно показывают поля и методы конкретных классов. Практически это три разных модели, связь между которыми неоднозначна. Так, ес- ли концептуальная модель определяет некоторое понятие предметной области как класс, то это не означает, что для реализации этого понятия будет использован отдель- ный класс. Однако во всех трех моделях нас интересуют типы объектов (классы) и их статические отношения, что позволяет использовать единую нотацию. Каждая из перечисленных моделей используется на конкретном этапе разработки ПО: * концептуальную модель – на этапе анализа; * диаграммы классов уровня спецификации – на этапе проектирования; * диаграммы классов уровня реализации – на этапе реализации. Концептуальные модели в соответствии с определением оперируют: понятиями предметной области, атрибутами этих понятий и отношениями между ними. Понятию в предметной области разрабатываемого ПО могут соответствовать как материальные предметы, так и абстракции, которые применяют специалисты предметной области. Основным понятиям в модели ставится в соответствие класс. Класс при этом тра- диционно понимают как совокупность общих признаков некоторой группы объектов предметной области. В соответствии с этим определением на диаграмме классов каж- дому классу соответствует группа объектов, общие признаки которых и фиксирует класс. Так класс «студент» объединяет общие признаки группы людей, обучающихся в высших учебных заведениях. Экземпляр класса или объект (например, Иванов И.И.) обязательно обладает всей совокупностью признаков своего класса и может иметь соб- ственные признаки, не фиксированные в классе. Так, например, помимо того, что Ива- нов И.И. является студентом, он еще может быть спортсменом, музыкантом и т.д. Строго говоря, таким собственным признаком является и идентифицирующее студента имя. 42 На диаграммах класс изображается в виде прямоугольника, внутри которого указа- но имя класса (рис. 5.5, а). При необходимости допускается указывать характеристики класса, например атрибуты, используя специальные секции условного обозначения (рис. 5.5, б). В качестве атрибутов представляют некоторые, существенные с точки зрения ре- шаемой задачи характеристики объектов, например, идентифицирующие значения (имя, номер). Для конкретного объекта атрибут всегда имеет конкретное значение для конкретного объекта. На диаграмме классов атрибуты обычно показывают в секции ат- рибутов. Под отношением классов понимают статическую, т.е. не зависящую от времени, связь между классами. Различают два основных вида отношений: ассоциация и обоб- щение. Отношение ассоциации означает наличие связи между экземплярами классов или объектами, например, класс «студент» ассоциирован с классом «институт». Ассоциа- ция может иметь имя, например, «Обучается». Рядом с именем ассоциации обычно ставят стрелку, указывающую направление чтения имени («Студент обучается в институте», а не наоборот). Связь между экземплярами классов подразумевает некоторые роли, которые соот- ветствующие объекты играют по отношению друг к другу. Роль связана с направлени- ем ассоциации. Так по отношению к студентам институт – организация, осуществляю- щая их обучение, т.е. роль института можно назвать «Место учебы». Студент для ин- ститута – объект обучающей деятельности института, т.е. «Обучаемый». Если роль собственного имени не имеет, то можно считать, что ее имя совпадает с именем класса, по отношению к которому определяется эта роль. Для рассматриваемого примера это соответственно роли «Студент» и «Институт» (рис. 5.6, а), но роль можно указать и яв- но (рис. 5.6, б). Роль также обладает характеристикой множественности, которая показывает, сколько объектов может участвовать в одной связи с каждой стороны. Допускается указывать множественность: * – от 0 до бесконечности; <целое>.. * – от заданного числа до бесконечности; <целое> – точно определенное количество объектов; <целое1>, <целое2> – несколько вариантов точного количества объектов; 43 <целое1>..<целое2> – диапазон объектов. Обобщением называют такое отношении между классами, при котором любой объ- ект одного класса (подтипа) обязательно является также и объектом другого класса, называемого в данном контексте супертипом. Так, если некоторый конкретный студент Иванов И.И. является объектом подтипа Студент первого курса супертипа Студент, то тот же самый Иванов И.И. является объектом указанного супертипа. Следовательно, все, что известно об объектах супертипа (ассоциации, атрибуты, операции) касается и объектов подтипа. На диаграмме классов обобщение обозначают линией с треугольной стрелкой на конце, подходящем к супертипу (рис. 5.7). На практике определение основных понятий предметной области, которые должны представляться на контекстной диаграмме в виде классов, является не тривиальной за- дачей. Обычно используют следующий способ: * формируют множество понятий-кандидатов из существительных, характеризую- щих предметную область в описании вариантов использования; * исключают понятия, не существенные для данного варианта использования, на- пример в предыдущем примере, «информация», «ввод» и т.п. Для определения множества понятий-кандидатов полезно использовать и перечень возможных категорий понятий-кандидатов. Пример 5.2. Построить концептуальную модель для системы решения комбина- торно-оптимизационных задач. Множество понятий-кандидатов для данной разработки включает следующие словосочетания: задание, тип задачи, список типов задач, способ задания данных, ввод данных, вы- бор данных из базы, алгоритм решения задачи, список конкретных алгоритмов реше- ния задачи, полнота описания задания, результаты, данные, база данных. Попробуем выделить основные понятия и связать их между собой. Цель основного варианта использования системы – выполнение задания. Полное описание задания включает: тип задачи, данные и указание на алгоритм. С ним же бу- дут связаны и полученные результаты. Данные могут сохраняться в базе и вводиться. Описание задания и все, что с ним связано, может сохраняться в базе. Определим возможные обобщения: 1) способ задания данных: ввод данных, выбор данных из базы; 2) алгоритм: алгоритм решения задачи: конкретный алгоритмы решения задачи. Переходим к построению концептуальной модели. 44 Основной класс-понятие, исходя из описания – Задание. Связываем с ним классы- понятия Данные, Алгоритм и Результаты. В разрабатываемой системе планируется реализовать алгоритмы решения задач трех типов: поиск цикла минимальной длины, проходящего через все вершины; поиск кратчайшего пути и поиск минимального покрывающего дерева. Следовательно, класс- понятие Алгоритм является супертипом для классов Алгоритм поиска цикла мини- мальной длины, Алгоритм поиска кратчайшего пути и Алгоритм поиска минимального покрывающего дерева, от которых, в свою очередь, будут наследоваться Алгоритмы, реализующие конкретные методы. Алгоритм также связан с Данными и Результатами. Для алгоритма очень существенной характеристикой является его точность, соответст- венно добавим атрибут Точность. Данные и Задания должны храниться в Базе данных, что показывают ассоциациями соответствующих классов. Способ задания данных для понимания основной концепции проектируемой системы пока не очень существенен. Вид задачи в нашем случае, скорее атрибут класса Задание, чем самостоятельный класс, так как в реальном мире это имя, которое позволяет уточнить группу возможных алгоритмов решения и структуры исходных данных и получаемых результатов. На рис. 5.8 показана полученная контекстная диаграмма классов. Описание поведения. Системные события и операции Концептуальная модель характеризует статические свойства разрабатываемого ПО. Для описания особенностей его поведения, т.е. возможных действий системы, целесо- образно использовать диаграммы последовательностей системы, системные события, системные операции, диаграммы деятельностей, а при необходимости и диаграммы со- стояний объектов (см. § 6.4). Диаграммы последовательностей системы. Диаграмма последовательностей системы – графическая модель, которая для определенного сценария варианта исполь- зования показывает генерируемые действующими лицами события и их порядок. При этом система рассматривается как единое целое. Для построения диаграммы последовательностей системы необходимо: * представить систему как «черный ящик» и изобразить для нее линию жизни – вертикальную пунктирную линию, подходящую к блоку снизу; 45 * идентифицировать каждое действующее лицо и изобразить для него линию жиз- ни (много действующих лиц бывает в вариантах совместного использования ПО); * из описания варианта использования определить множество системных событий и их последовательность; * изобразить системные события в виде линий со стрелкой на конце между линия- ми жизни действующих лиц и системы, а также указать имя события и список переда- ваемых значений. В отличие от внутренних событий, события, которые генерируются для системы действующими лицами, называют системными. Системные события инициируют вы- полнение соответствующего множества операций, также называемых системными. Каждую системную операцию называют по имени соответствующего сообщения. Множество всех системных операций определяют, идентифицируя системные со- бытия всех вариантов использования. Для наглядности системные операции изобража- ют в виде операций абстрактного класса (типа) System. Если желательно разделить множество операций на подмножества, инициируемые разными пользователями, то ис- пользуют несколько абстрактных классов: System1, System2 и т.д. Каждую системную операцию необходимо описать. Обычно описание системной операции содержит: * имя операции и ее параметры; * описание обязанности; * указание типа; * названия вариантов использования, в которых она используется; * примечания для разработчиков алгоритмов и т.д.; * описание обработки возможных исключений; * описание вывода неинтерфейсных сообщений; * предположение о состоянии системы до выполнения операции (предусловие); * описание изменения состояния системы после выполнения операции (постусло- вие). Пример 5.3. Разработать диаграмму последовательностей системы для варианта использования Выполнение задания решения комбинаторно-оптимизационных задач. Анализируем описание варианта использования и определяем, что действующее лицо должно генерировать девять системных событий, включая загрузку задания из ба- зы, которая логически следует из операции сохранения. 46 Покажем эти события на диаграмме последовательностей (рис. 5.9). В скобках укажем параметры, которые должны формировать эти события Следовательно, система должна обеспечивать выполнения соответствующих опе- раций. Полученное множество операций приписывают классу System (рис. 5.10). Далее каждую операцию необходимо описать. Для примера опишем операцию Инициировать решение (). |