Программная инженерия лабораторный практикум
 Скачать 1.48 Mb.
|
|
Text Box Добавляет на диаграмму текстовую область Note Добавляет на диаграмму примеча- ние Anchor Note to Item Добавляет на диаграмму связь примечания с соответствующим графическим элементом диаграм- мы Package Добавляет на диаграмму пакет Use Case Добавляет на диаграмму вариант использования Actor Добавляет на диаграмму актера Unidirectional Association Добавляет на диаграмму направ- ленную ассоциацию Dependency or Instantiates Добавляет на диаграмму отноше- ние зависимости Generalization Добавляет на диаграмму отноше- ние обобщения 13 Рис. 2.1. Диалоговое окно настройки панели инструментов Для построения диаграммы для рассматриваемой модели бан- комата следует выполнить следующие действия: 1. Добавить актера с именем Банк, для которого выбрать сте- реотип Service (Сервис), означающий, что банкомат использует неко- торые услуги Банка в качестве сервиса. 2. Добавить вариант использования Получение справки о со- стоянии счета, для которого выбрать стереотип Business Use Case (Бизнес-вариант использования). 3. Добавить вариант использования Блокирование кредитной карточки. 4. Добавить направленную ассоциацию от бизнес-актера Кли- ент Банкомата к варианту использования Получение справки о со- стоянии счета. 5. Добавить направленную ассоциацию от варианта использо- вания Снятие наличных по кредитной карточке к сервису Банк. 6. Добавить направленную ассоциацию от варианта использо- вания Получение справки о состоянии счета к сервису Банк. 7. Добавить отношение зависимости со стереотипом < 8. Добавить отношение зависимости со стереотипом < При этом отношение зависимости со стереотипом < 14 если в результате проверки ПИН-кода будет установлено, что соот- ветствующая кредитная карточка утрачена ее владельцем или при- знана недействительной. Построенная таким образом диаграмма ва- риантов использования будет иметь следующий вид (рис. 2.2). Рис. 2.2. Диаграмма вариантов использования для модели банкоматов Контрольные вопросы 1. Из каких элементов состоит диаграмма Use Case? 2. Какие отношения разрешены между элементами диаграммы Use Case? 3. Для чего применяют диаграммы Use Case? 4. Чем отличаются друг от друга отношения включения и рас- ширения с точки зрения управления? 5. Каково назначение спецификации элемента Use Case и как она оформляется? 6. Что такое сценарий элемента Use Case? 15 Лабораторная работа №3 РАСЧЕТ ХАРАКТЕРИСТИК МОДУЛЬНОЙ ПРОГРАММНОЙ СИСТЕМЫ Цель работы: оценка показателей связности и сцепления модульной программной системы Программа выполнения работы 1. Изучить методические указания по расчету характеристик мо- дульной программной системы и показателей ее сложности. 2. Вычислить характеристики модульности и сложности про- граммы для заданного варианта. Методически указания Модуль - фрагмент программного текста, являющийся строи- тельным блоком для физической структуры системы. Как правило, модуль состоит из интерфейсной части и части-реализации. Модульность — свойство системы, которая может подвергаться декомпозиции на ряд внутренне связанных и слабо зависящих друг от друга модулей. По определению Г. Майерса, модульность — свойст- во ПО, обеспечивающее интеллектуальную возможность создания сколь угодно сложной программы. Связность модуля (Cohesion) — это мера зависимости его частей. Связность — внутренняя характеристика модуля. Чем выше связ- ность модуля, тем лучше результат проектирования, то есть тем «черней» его ящик (капсула, защитная оболочка модуля), тем меньше «ручек управления» на нем находится и тем проще эти «ручки». Для измерения связности используют понятие силы связности (СС). Существует 7 типов связности: 1. Связность по совпадению (СС=0). В модуле отсутствуют яв- но выраженные внутренние связи. 2. Логическая связность (СС=1). Части модуля объединены по принципу функционального подобия. Например, модуль состоит из разных подпрограмм обработки ошибок. При использовании такого модуля клиент выбирает только одну из подпрограмм. Недостатки: 16 - сложное сопряжение; - большая вероятность внесения ошибок при изменении со- пряжения ради одной из функций. 3. Временная связность (СС=3). Части модуля не связаны, но не- обходимы в один и тот же период работы системы. Недостаток: сильная взаимная связь с другими модулями, отсю- да — сильная чувствительность внесению изменений. 4. Процедурная связность (СС=5). Части модуля связаны по- рядком выполняемых ими действий, реализующих некоторый сцена- рий поведения. 5. Коммуникативная связность (СС=7). Части модуля связаны по данным (работают с одной и той же структурой данных). 6. Информационная (последовательная) связность (СС=9). Вы- ходные данные одной части используются как входные данные в дру- гой части модуля. 7. Функциональная связность (СС=10). Части модуля вместе реализуют одну функцию. Отметим, что типы связности 1,2,3 — результат неправильного планирования архитектуры, а тип связности 4 — результат небрежно- го планирования архитектуры приложения. Алгоритм определения уровня связности модуля. 1. Если модуль — единичная проблемно-ориентированная функ- ция, то уровень связности — функциональный; конец алгоритма. В противном случае перейти к пункту 2. 2. Если действия внутри модуля связаны, то перейти к пункту 3. Если действия внутри модуля никак не связаны, то перейти к пунк- ту 6. 3. Если действия внутри модуля связаны данными, то перей- ти к пункту 4. Если действия внутри модуля связаны потоком управ- ления, перейти к пункту 5. 4. Если порядок действий внутри модуля важен, то уровень связности — информационный. В противном случае уровень связно- сти — коммуникативный. Конец алгоритма. 5. Если порядок действий внутри модуля важен, то уровень связности — процедурный. В противном случае уровень связности — временной. Конец алгоритма. 6. Если действия внутри модуля принадлежат к одной категории, то уровень связности — логический. Если действия внутри модуля не 17 принадлежат к одной категории, то уровень связности — по совпаде- нию. Конец алгоритма. Возможны более сложные случаи, когда с модулем ассоциируются несколько уровней связности. В этих случаях следует применять одно из двух правил: - правило параллельной цепи. Если все действия модуля имеют несколько уровней связности, то модулю присваивают самый сильный уровень связности; - правило последовательной цепи. Если действия в модуле имеют разные уровни связности, то модулю присваивают самый сла- бый уровень связности. Например, модуль может содержать некоторые действия, которые связаны процедурно, а также другие действия, связные по совпаде- нию. В этом случае применяют правило последовательной цепи и в целом модуль считают связным по совпадению. Сцепление модулей. Сцепление (Coupling) — мера взаимозави- симости модулей по данным. Сцепление — внешняя характеристика модуля, которую желательно уменьшать. Количественно сцепление измеряется степенью сцепления (СЦ). Выделяют 6 типов сцепления. 1. Сцепление по данным (СЦ=1). Модуль А вызывает модуль В. Все входные и выходные параметры вызываемого модуля — про- стые элементы данных. 2. Сцепление по образцу (СЦ=3). В качестве параметров использу- ются структуры данных. 3. Сцепление по управлению (СЦ=4). Модуль А явно управляет функционированием модуля В (с помощью флагов или переклю- чателей), посылая ему управляющие данные. 4. Сцепление по внешним ссылкам (СЦ=5). Модули А и В ссыла- ются на один и тот же глобальный элемент данных. 5. Сцепление по общей области (СЦ=7). Модули разделяют одну и ту же глобальную структуру данных. 6. Сцепление по содержанию (СЦ=9). Один модуль прямо ссылает- ся на содержание другого модуля (не через его точку входа). На- пример, коды их команд перемежаются друг с другом. Сложность программной системы. В простейшем случае сложность системы определяется как сумма мер сложности ее моду- лей. Сложность модуля может вычисляться различными способами. М. Холстед предложил меру длины N модуля: 18 N n 1 log 2 (n 1 ) + n 2 log 2 (n 2 ), где n 1 — число различных операторов, п 2 — число различных опе- рандов. В качестве второй метрики М. Холстед рассматривал объем V мо- дуля (количество символов для записи всех операторов и операндов текста программы): V = N x log 2 (n 1 + n 2 ). Вместе с тем известно, что любая сложная система состоит из элементов и системы связей между элементами и что игнорировать внутрисистемные связи неразумно. Том МакКейб при оценке сложности ПС предложил исходить из топологии внутренних связей. Для этой цели он разработал метрику цикломатической сложности: V(G) = E-N + 2, где Е — количество дуг, a.N — количество вершин в управляющем графе ПС. Таким образом, при комплексной оценке сложности ПС необходимо рассматривать меру сложности модулей, меру сложности внешних связей (между модулями) и меру сложности внутренних связей (внутри модулей). Контрольные вопросы 1. Поясните понятия модуля и модульности. Зачем используют модули? 2. В чем состоит принцип информационной закрытости? Какие достоинства он имеет? 3. Что такое связность модуля? 4. Какие существуют типы связности? 5. Дайте характеристику функциональной связности. 6. Дайте характеристику информационной связности. 7. Охарактеризуйте коммуникативную связность. 8. Охарактеризуйте процедурную связность. 9. Дайте характеристику временной связности. 10. Дайте характеристику логической связности. 11. Охарактеризуйте связность по совпадению. 12. Что такое сцепление модуля? 13. Какие существуют типы сцепления? 14. Дайте характеристику сцепления по данным. 15. Дайте характеристику сцепления по образцу. 19 16. Охарактеризуйте сцепление по управлению. 17. Охарактеризуйте сцепление по внешним ссылкам. 18. Дайте характеристику сцепления по общей области. 19. Дайте характеристику сцепления по содержанию. 20. Что значит «улучшать сцепление»? 21. Какие подходы к оценке сложности системы вы знаете? Лабораторная работа №4 РАЗРАБОТКА ДИАГРАММ КЛАССОВ НА ЯЗЫКЕ UML Цель работы: построение диаграммы классов UML Программа выполнения работы 1. Изучить назначение и методику разработки диаграммы классов. 2. Изучить технологию создания диаграмм классов UML в Rational Rose. 3. Разработать UML диаграмму классов для заданного варианта. Методически указания - Диаграмма классов является основным логическим представ- лением модели и содержит детальную информацию о внутреннем устройстве объектно-ориентированной программной системы или, используя современную терминологию, об архитектуре программной системы. Активизировать рабочее окно диаграммы классов можно несколькими способами: - окно диаграммы классов появляется по умолчанию в рабочем окне диаграммы после создания нового проекта; - щелкнуть на кнопке с изображением диаграммы классов на стандартной панели инструментов; - раскрыть логическое представление (Logical View) в браузере проекта и дважды щелкнуть на пиктограмме Main (Главная); - выполнить операцию главного меню: Browse Class Diagram (Обзор Диаграмма классов). - При этом появляется новое окно с чистым рабочим листом диаграммы классов и специальная панель инструментов, содержащая кнопки с изображением графических примитивов, необходимых для разработки диаграммы классов (табл. 4.1). Назначение отдельных кнопок панели можно узнать также из всплывающих подсказок. На 20 специальной панели инструментов по умолчанию присутствует толь- ко часть пиктограмм элементов, которые могут быть использованы для построения диаграммы классов. Добавить кнопки с пиктограмма- ми других графических элементов таких как, например, отношения агрегации и композиции, шаблон, класс бизнес-сущность, управляю- щий класс, или удалить ненужные кнопки можно с помощью на- стройки специальной панели инструментов. Соответствующее диало- говое окно настройки специальной панели инструментов для диа- граммы классов можно вызвать аналогично другим панелям с помо- щью операции контекстного меню Customize (Настройка) при пози- ционировании курсора на специальной панели инструментов Таблица 4.1. Назначение кнопок специальной панели инструментов для диаграммы классов Графическое изображение Всплывающая подсказка Назначение кнопки Selection Tool Превращает изображение курсора в форму стрелки для последующего выделения эле- ментов на диаграмме Text Box Добавляет на диаграмму текстовую область Note Добавляет на диаграмму примечание Anchor Note to Item Добавляет на диаграмму связь примечания с соответствующим графическим элемен- том диаграммы Class Добавляет на диаграмму класс Interface Добавляет на диаграмму интерфейс Unidirectional Association Добавляет на диаграмму направленную ас- социацию Association Class Добавляет на диаграмму ассоциацию класс Package Добавляет на диаграмму пакет Dependency or Instantiates Добавляет на диаграмму отношение зави- симости Generalization Добавляет на диаграмму отношение обоб- щения Realize Добавляет на диаграмму отношение реали- зации 21 Для построения диаграммы классов рассматриваемой модели банкомата следует описанным выше способом добавить оставшиеся классы и ассоциации, а также специфицировать стереотипы, атрибу- ты и операции этих классов. С этой целью следует выполнить сле- дующие действия: 1. Для класса IИнтерфейс Банка добавить операцию: прове- рить идентификатор карточки (идентификатор карточки: Integer) с квантором видимости public. В качестве типа возвращаемого резуль- тата для этой операции следует выбрать тип Boolean (логический), а в качестве целочисленного аргумента задать идентификатор карточки. Для задания аргумента необходимо перейти на вкладку Detail (Под- робно) окна спецификации свойств даной операции и после добавле- ния аргумента с помощью операции контекстного меню Insert ввести имя аргумента и его тип Integer в соответствующие поля ввода. 2. Для класса IИнтерфейс Банка добавить операцию: открыть счет клиента (идентификатор карточки: Integer) с квантором видимо- сти public. В качестве целочисленного аргумента этой операции сле- дует задать идентификатор карточки. 3. Для класса IИнтерфейс Банка добавить операцию: прове- рить баланс клиента (идентификатор карточки: Integer, введенная сумма наличных: Currency) с квантором видимости public. В качестве типа возвращаемого результата для этой операции следует выбрать тип Boolean (логический). В качестве первого целочисленного аргу- мента этой операции следует задать идентификатор карточки, а в ка- честве второго аргумента - введенная сумма наличных с типом Currency (Денежный). 4. Для класса IИнтерфейс Банка добавить операцию: умень- шить счет клиента (идентификатор карточки: Integer, введенная сум- ма наличных: Currency) с квантором видимости public. В качестве ти- па возвращаемого результата для этой операции следует выбрать тип Boolean (логический). В качестве первого целочисленного аргумента этой операции следует задать идентификатор карточки, а в качестве второго аргумента - введенная сумма наличных с типом Currency (Денежный). 5. Для класса Устройство чтения карточки добавить операцию: прочитать идентификатор карточки() с квантором видимости public. 22 В качестве типа возвращаемого результата для этой операции следует выбрать тип Integer (целочисленный), а в секцию документации дан- ной операции следует ввести поясняющий текст: «Вызывается после того, как кредитная карточка вставлена в Устройство чтения карточ- ки». 6. Для класса Устройство чтения карточки добавить операцию: прочитать ПИН-код() с квантором видимости public. В качестве типа возвращаемого результата для этой операции следует выбрать тип Integer (целочисленный), а в секцию документации данной операции следует ввести поясняющий текст: «Вызывается после того, как кре- дитная карточка вставлена в Устройство чтения карточки». 7. Для класса Устройство чтения карточки добавить операцию: вернуть кредитную карточку() с квантором видимости public. В сек- цию документации данной операции следует ввести поясняющий текст: «Вызывается после завершения транзакции». 8. Для класса Устройство чтения карточки добавить операцию: блокировать кредитную карточку() с квантором видимости public. В секцию документации данной операции следует ввести поясняющий текст: «Вызывается после того, как установлен факт утраты кредит- ной карточки владельцем». 9. Добавить класс с именем Экран Банкомата, для которого выбрать стереотип boundary. Данный класс также находится на гра- нице моделируемой системы, на что и указывает этот стереотип. В секцию документации данного класса следует ввести поясняющий текст: «Устанавливается на банкомате». 10. Для класса Экран Банкомата добавить операцию: показать меню опций() с квантором видимости public. 11. Для класса Экран Банкомата добавить операцию: показать меню снятия суммы() с квантором видимости public. 12. Добавить класс с именем Клавиатура Банкомата, для кото- рого выбрать стереотип boundary. В секцию документации данного класса следует ввести поясняющий текст: «Устанавливается на бан- комате». 13. Для класса Клавиатура Банкомата добавить операцию: вве- сти ПИН-код() с квантором видимости public. В качестве типа воз- вращаемого результата для этой операции следует выбрать тип Integer, а в секцию документации данной операции следует ввести поясняющий текст: «Вызывается после того, как клиент ввел значе- ние ПИН-кода с клавиатуры». |