Учебное пособие по выполнению и оформлению курсовых, дипломных и квалификационных работ москва 2002 2 аннотация
 Скачать 0.53 Mb.
|
|
Пример 6.5. Уточнить отношения классов пакета Объекты задачи между собой с классом Решение из пакета Объекты управления, используя результаты детализации отношений между объектами рассматриваемых классов. Анализ диаграммы кооперации, представленной на рис. 6.9 показывает, что: 55 • класс Задание по сути дела представляет собой таблицу, в которой фиксируется все информация о конкретной задаче: вид задачи, алгоритм решения, данные и резуль- тат, причем результат связан с заданием неразрывно, так как теряет смысл вне контек- ста задания (отношение композиции), а данные имеют смысл сами по себе (отношение агрегации); • класс Алгоритм целесообразно разрабатывать как абстрактный, обеспечиваю- щий интерфейс между объектом класса Решение и конкретным алгоритмом и между объектом класса Задание и опять же конкретным алгоритмом; • отношение между классами Задание и Алгоритм, Решение и Алгоритм, а также Задание и Решение – ассоциации, направленные к классу Задание. Кроме того, анализ структур исходных данных и результатов решаемых задач по- казывает их существенное различие, следовательно, классы Данные и Результаты необ- ходимо реализовать, как абстрактные, и наследовать от них классы, уточняющие струк- туры данных и результатов для каждого случая. Результат уточнения показан на рис. 6.16. Проектирование классов Собственно проектирование классов предполагает окончательное определение структуры и поведения его объектов. Структура объектов определяется совокупно- стью атрибутов класса. Каждый атрибут это поле или совокупность полей, содержа- щееся в объекте класса. Поведение объектов класса определяется реализуемыми обязанностями. Обязанно- сти выполняются посредством операций класса. Таким образом, при проектировании класса помимо имени и максимально полного списка атрибутов, необходимо уточнить егоответственность иоперации. Причем как атрибуты, так и операции в процессе проектирования целесообразно дополнительно специфицировать. В зависимости от степени детализации диаграммы классов обозна- чение атрибута может включать, помимо имени, тип, описание видимости и значение по умолчанию в следующем виде: <признак видимости> <имя>:<тип>=<значение по умолчанию> где признак видимости может принимать одно из трех значений: «+» – общий; «#» – защищенный; «-» – скрытый. 56 Операциями называют основные действия, реализуемые классом. В отличие от ме- тодов операции не всегда реализуются классом непосредственно. Например, операция Ввод числа может быть реализована агрегированным интерфейсным элементом «окно ввода». Полное описание операции на диаграмме класса в UML может выглядеть следую- щим образом: <признак видимости> <имя>(<список параметров>): <тип возвращаемого значе- ния> Ответственностью класса называют краткое неформальное перечисление основ- ных функций объектов класса. Ответственность класса обычно определяют на началь- ных этапах проектирования, когда атрибуты и операции класса еще не определены. Эту информацию отображают на диаграмме классов в специальных секциях условного изо- бражения класса (рис. 6.17). Исходный список операций класса формируют, анализируя диаграммы деятельно- стей, диаграммы кооперации и диаграммы последовательностей, построенные для раз- личных сценариев с участием объектов проектируемого класса. На начальных этапах проектирования в секции операций класса обычно указывают лишь имена основных операций, определяющих наиболее общее поведение объектов соответствующих клас- сов. По мере уточнения добавляют новые операции, а информацию об уже имеющихся операциях детализируют. Большинство атрибутов выявляется при анализе предметной области, требований технического задания и описаний потоков событий. Кроме того, как уже указывалось выше, отношение ассоциации и его подвиды – аг- регация и композиция – означают наличие обмена сообщениями между объектами классов. Для организации передачи сообщений необходимо, чтобы генерирующий со- общения объект содержал информацию о вызываемом объекте, что означает наличие у этого объекта соответствующего указателя. Причем при отношении композиции объек- ты-части могут быть организованы как объектные поля объекта-целого. В том случае, если объекты проектируемого класса должны реализовывать слож- ное поведение, для них целесообразно разрабатывать диаграммы состояний. Диаграммы состояний объекта. Под состоянием применительно к диаграмме со- стояний понимают ситуацию в жизненном цикле объекта, во время которой он: удовле- творяет некоторому условию, осуществляет определенную деятельность или ожидает 57 некоторого события. Изменение состояния, связанное с нарушением условия или, соот- ветственно, завершением деятельности или наступлением события называют перехо- дом. Диаграммы состояний показывают состояния объекта, возможные переходы, а также события или сообщения, вызывающие каждый переход. Условные обозначения состояний приведены на рис. 6.18. Действие, указанное по- сле слова Вход, выполняется при входе в состояние, а действие, указанное после слова Выход – при выходе из него. Деятельность связывается с нахождением в состоянии. Переход обозначается линией со стрелкой и может быть помечен меткой, состоя- щей из трех частей, каждую из которых можно опустить: <Событие> [<Условие>]/<Действие> Если событие не указано, то это означает, что переход выполняется по завершению деятельности, связанной с данным состоянием. Если же оно указано – то при наступ- лении события. Условие записывается в виде логического выражения. Переход проис- ходит, если результат выражения – «истина». Объект не может одновременно перейти в два разных состояния, поэтому условия перехода для любого события должны быть взаимоисключающими. В отличие от деятельностей, действия, указанные для перехода, связывают с по- следним и рассматривают как мгновенные и непрерываемые. При необходимости можно определять суперсостояния (рис. 6.18, г), которые объ- единяют несколько состояний в одно. Этот механизм обычно используют, чтобы пока- зать переход из нескольких состояний в одно и тоже состояние, например, при отмене каких либо действий. Пример 6.6. Разработать диаграмму состояний для объекта класса Решение. Диаграмму строим, анализируя соответствующие диаграммы последовательностей (рис. 6.7–6.8). При этом необходимо уточнить, в какой момент разрешить прерывание процесса извне. Чтобы показать, что прерывание процесса возможно еще во время его инициализации, вводим суперсостояние Процесс. При реализации следует учесть воз- можность прерывания процесса до активации Алгоритма (рис. 6.19). Результаты уточнения структуры и поведения объектов классов отразим на диа- грамме классов. Пример 6.7. Уточнить атрибуты и операции классов Решение, Задание, Алгоритм, Данные и Результаты, используя полученные в данном параграфе сведения. 58 К л а с с З а д а н и е. Поскольку объект класса Задание должен хранить иденти- фикатор задачи и тип алгоритма, он должен иметь соответствующие поля и включать операции Определить задачу (), Определить алгоритм(), Сообщить тип задачи(), Сооб- щить тип алгоритма(). Кроме того, объект класса Задание отвечает за объекты классов Данные и Резуль- таты, связанные с ним, следовательно, он должен хранить их адреса и соответственно выполнять операции Определить данные(), Сообщить данные(), Фиксировать результа- ты(), Сообщить результаты(). К л а с с ы Д а н н ы е и Р е з у л ь т а т ы. Данные задач и их результаты должны храниться в базе данных, но имеют различные структуры. Эту проблему можно ре- шить, если хранить и данные, и результаты в упакованном виде, распаковывая их по мере надобности. Поэтому, соответствующие классы должны объявлять абстрактные операции Упаковать() и Распаковать(), которые будут реализовываться классами- подтипами в зависимости от реальной структуры данных, определяемой типом задачи. Следовательно, указанные классы должны также хранить тип задачи, с которой они связаны, и содержать операции Определить тип задачи() и Сообщить тип Задачи(). К л а с с А л г о р и т м. Объекты класса Алгоритм отвечают за реализацию метода решения задачи. Поскольку они посылают сообщение объектам класса Задания, то ес- тественно должны хранить его адрес. Кроме того, класс Алгоритм должен объявлять абстрактную операцию Выполнить(). Эта операция должна переопределяться классами Алгоритм, реализующий метод. Примечание. Возможно более удачное решение: в классе Алгоритм определить операцию Выполнить() и внутреннюю абстрактную операцию Реализовать метод(), которая вызывается из первой. Такое решение позволит не дублировать общее поведе- ние всех алгоритмов, например, запрос и распаковку данных, а также упаковку и запись результата. Это решение не приведено, чтобы не усложнять и так достаточно сложный пример. К л а с с Р е ш е н и е. Объект класса Решение обращается к объектам классов За- дание и Алгоритм, следовательно, необходимо хранить их адреса. Операции Начать() и Прервать() получены из диаграмм последовательностей действий. Операция Обрабо- 59 тать исключение() получена оттуда же, но должна реализовываться особым способом, так как будет получать управление через механизм исключений. Результаты уточнения приведены на рис. 6.20. Проектирование методов класса. Некоторую достаточно существенную инфор- мацию о действиях, которые должны выполняться методами класса, можно получить, анализируя диаграммы последовательности действий. Однако алгоритмы всех сколько- нибудь сложных методов должны быть проработаны детально. При этом можно ис- пользовать как уже известные нотации (схемы алгоритмов и псевдокоды), так и диа- граммы деятельностей. Ранееуже были описаны диаграммы деятельности, которые предлагалось исполь- зовать в процессе уточнения спецификаций для описания вариантов использования. Эти же диаграммы могут использоваться и при проектировании методов обработки со- общений, в том числе и затрагивающих несколько объектов. В последнем случае целе- сообразно указать вертикальными пунктирными линиями ответственности объектов соответствующих классов, что позволит проследить вызовы других объектов. Следует помнить, что в соответствии с общими правилами процедурной декомпо- зиции любую деятельность можно декомпозировать и изобразить в виде диаграммы деятельности более низкого уровня. Пример 6.8. Построить диаграмму деятельности для операции Начать() класса Ре- шение. Анализ рис. 6.4, 6.7-6.8 показывает, что данная деятельность затрагивает три объ- екта уже детализированных классов Решение, Алгоритм и Задание. Определим зоны ответственности объектов этих классов (рис. 6.21). Полностью спроектированные классы описывают на конкретном языке программи- рования. Компоновка программных компонентов Диаграмма компонентов применяют при проектировании физической структуры разрабатываемого ПО. Эти диаграммы показывают, как выглядит ПО на физическом уровне, т.е. из каких частей оно состоит и как эти части связаны между собой. Диаграмма компонентов оперирует понятиями компонент и зависимость. Под компонентами понимают физические заменяемые части ПО, которые соответствуют некоторому набору интерфейсов и обеспечивают их реализацию. По сути дела, это от- 60 дельные файлы различных типов: исполняемые (.exe), текстовые, графические, табли- цы баз данных и т.п., составляющие разрабатываемое ПО. Условные графические обо- значения компонент различных типов приведены на рис. 6.22. Зависимость между компонентами фиксируют, если один компонент содержит не- который ресурс (модуль, объект, класс и т.д.), а другой его использует. На рис. 6.23 в качестве примера приведена диаграмма компонентов системы решения комбинаторно- оптимизационных задач. Показан также интерфейс, через который система взаимодей- ствует с базой данных. При «сборке» исполняемых файлов диаграммы компонентов применяют для ото- бражения взаимосвязей файлов, содержащих исходный код. Так на рис. 6.24 показано, что основной файл Main.cpp зависит от заголовочного файла Model.h, реализация кото- рого находится в файле Model.cpp. Используя UML можно построить диаграмму компоновки практически для лю- бого случая, например, для Интернет-приложения. На рис. 6.25 приведен пример диа- граммы компонентов клиентской части Интернет-приложения, написанного с исполь- зованием Java, которое в процессе работы демонстрирует некоторый рисунок. Проектирование размещения программных компонентов для распределенных программных систем При физическом проектировании распределенных программных систем необходи- мо определить наиболее целесообразный вариант размещения программных компонен- тов на реальном оборудовании в локальной или глобальной сетях. Для этого использу- ют специальную модель UML– диаграмму размещения. Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Каждой части аппаратных средств системы,на- пример, компьютеру или датчику, соответствует узел на диаграмме размещения. Со- единения узлов означают наличие в системе соответствующих коммуникационных ка- налов. Внутри узлов указывают размещенные на данном оборудовании программные компоненты разрабатываемой программной системы, сохраняя указанные на диаграм- ме компонентов отношения зависимости. На рис. 6.26 показаны условное обозначение узлов (процессора и устройства), а диаграмме размещения. 61 Пример 6.9. Разработать диаграмму размещения для системы учета успеваемости студентов. Поместим основную часть системы на сервер деканата, а на компьютерах сети – соответствующие клиентские части (рис. 6.27). 7. ПРАВИЛА ОФОРМЛЕНИЯ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ Оформление текстового и графического материала В соответствии с ГОСТ 7.32 – 91 расчетно-пояснительная записка должна вклю- чать: титульный лист, реферат, содержание, введение, основную часть, заключение, список использованных источников и, возможно, приложение. Пример титульного листа записки (ГОСТ 19.104 –78) приведен в приложении 2. Пояснительная записка оформляется на листах формата А4. Графический материал можно оформлять на листах формата А3. Поля на листе определяются в соответствии с общими требованиями: левое – не менее 30 мм, правое – не менее 10 мм, верхнее – не менее 15, а нижнее – не менее 20. При использовании текстовых редакторов для оформления записки параметры страницы заказываются в зависимости от устройства печати. При ручном оформлении выбираются из соображений удобства. Нумерация страниц – сквозная. Номер проставляется сверху справа арабской циф- рой. Страницами являются листы с текстами, рисунками и текстами приложения. Первая страница – титульный лист. Номер страницы на титульном листе не про- ставляется. Образец титульного листа представлен в приложении 2. Вторая страница – аннотация на разрабатываемый программный продукт, в кото- рой в сжатом виде описывается назначение и особенности разработки. Третья страница – оглавление, отражающее содержание изложенного материала (пример оглавления приведен в приложении 3). Ни аннотация, ни само оглавление в содержании не упоминаются. Затем следуют разделы записки в порядке, определенном логикой изложения мате- риала. Записка завершается списком литературы. Далее могут следовать приложения, содержащие материал, не вошедший в записку по причине ее ограниченного размера, но интересный для более глубокого понимания назначения и возможностей разработки. Расчетно-пояснительная записка может содер- жать одно и более приложений. 62 Наименование разделов пишутся прописными буквами в середине строки. Расстоя- ние между заголовками и текстом, а также между заголовками раздела и подразделов должно быть равно: • при выполнении документа машинописным способом – двум интервалам; • при выполнении рукописным способом –10 мм; • при использовании текстовых редакторов – определяется возможностями редак- тора. Наименования подразделов и пунктов следует размещать с абзацного отступа и пе- чатать с прописной буквы вразрядку, не подчеркивая и без точки в конце. Расстояние между последней строкой текста предыдущего раздела и последующим заголовком при расположении их на одной странице должно быть равно: • при выполнении документа машинописным способом – трем интервалам; • при выполнении рукописным способом – не менее 15 мм; • при использовании текстовых редакторов – определяется возможностями редак- тора. Разделы и подразделы нумеруются арабскими цифрами с точкой. Разделы должны иметь порядковые номера 1, 2, и т. д. Номер подраздела включает номер раздела и по- рядковый номер подраздела, входящего в данный раздел, разделенные точкой. Напри- мер: 2.1., 3.5. Ссылка на пункты, разделы и подразделы указывается порядковым но- мером, например, «в разд. 4», «в п. 3.3.4». Текст разделов выполняется через 1,5 интервала, а при использовании текстовых редакторов высота букв и цифр должна быть не менее 1,8 мм (шрифт № 12). Перечисления надо нумеровать арабскими цифрами со скобкой; Например: 2), 3) и т.д. - с абзацного отступа. Допускается выделять перечисление простановкой дефиса перед пунктом текста или символом, его заменяющим, в текстовых редакторах. Оформление рисунков, схем алгоритмов, таблиц и формул Иллюстрации (графики, схемы, диаграммы) могут быть приведены как в основном тексте, так и в приложении. Все иллюстрации именуются рисунками. Все рисунки, таб- лицы и формулы нумеруются арабскими цифрами последовательно (сквозная нумера- ция). В приложении - в пределах приложения. Чертежи, графики, диаграммы и схемы должны быть выполнены с учетом ЕСКД. 63 Каждый рисунок должен иметь подрисуночную подпись, помещаемую, как следует из названия под рисунком, например: Рис.12. Форма окна основного меню На все рисунки, таблицы и формулы в записке должны быть ссылки в виде: «(рис. 12)» или « форма окна основного меню приведена на рис. 12.». Рисунки и таблицы должны размещаться сразу после той страницы, на которой в тексте записки она упоминается в первый раз. Если позволяет место, рисунок (таблица) может размещаться в тексте на той же странице, где на него дается первая ссылка. Если рисунок занимает более одной страницы, на всех страницах, кроме первой, проставляется номер рисунка и слово «Продолжение». Например: Рис. 12. Продолжение Рисунки следует размещать так, чтобы их можно было рассматривать без поворота записки. Если такое размещение невозможно, рисунки следует располагать так, чтобы для рассматривания надо было повернуть записку по часовой стрелке. В этом случае верхним краем является левый край страницы. Расположение и размеры полей сохра- няются в соответствии с выбранными. Схемы алгоритмов должны быть выполнены в соответствии со стандартом ЕСПД. Толщина сплошной линии при вычерчивании схем алгоритмов должна быть в пределах от 0,6 до 1,5 мм. Надписи на схемах должны быть выполнены чертежным шрифтом. Высота букв и цифр должна быть менее 3,5 мм. Номер таблицы размещается в правом верхнем углу перед заголовком таблицы, ес- ли он есть. Заголовок, кроме первой буквы , выполняется строчными буквами. В аббре- виатурах используются только заглавные буквы. Например: ПЭВМ (ГОСТ 2.105). Ссылки на таблицы в тексте пояснительной записки должны быть в виде слова «табл.» и номера таблицы. Например: Результаты тестов приведены в табл. 4. Уравнения и формулы следует выделять из текста в отдельную строку, оставив выше и ниже формулы не менее одной свободной строки. Если формула не умещается на одной строке, ее переносят, прервав на любом математическом знаке. Номер формулы ставится с правой стороны страницы в круглых скобках на уровне формулы. Например: 64 z:=sin(x)+ln(y); (12) Ссылка на номер формулы дается в скобках. Например: «расчет значений произ- водится по формуле (12)». Примечание следует помещать при необходимости пояснения содержания теста таблицы или рисунка. Оно размещается непосредственно после пункта, подпункта, таблицы или рисунка, к которому относится. Слово «примечание» печатается с абзац- ного отступа с прописной буквы вразрядку и не подчеркивается. Если примечаний не- сколько, то они нумеруются, например: П р и м е ч а н и я : 1. …. 2. ….. |