Объектно-ориентированная методология анализа и построения спецификаций
Цели:обзор средств проектировщика ПО, получение и закрепление навыков в использовании ООП в проектировании ПО.
Теоретический материал
На данный момент не является тайной, что для успешной конкуренции стало недостаточно просто укладываться в бюджет и сроки. Опыт софтверных компаний как зарубежных, так и отечественных, позволил сформулировать так называемое Правило «80/20»:
Правило «80/20»: успешность проекта на 80% определяется регламентом работ и только на 20% – применяемым инструментарием.
Проектирование архитектуры для структурной методологии включает следующие основные методы: метод нисходящего проектирования, метод восходящего проектирования, метод расширения ядра.
В основе объектно-ориентированного подхода лежит объектная декомпозиция: структурасистемы описывается в терминах объектов и связей между ними, поведениесистемы описывается в терминах обмена сообщениями между объектами..
Объектно-ориентированный подход позволяет сократить время на разработку систем при условии повторного использования заготовок (шаблоны, паттерны).
Объектно-ориентированный анализ (ООА) – процесс применения объектно-ориентированного подхода для понимания задачи. После завершения анализа требования к информационной системе должны стать понятными членам группы, и должен быть составлен словарь предметной области.
Спецификация разрабатываемого ПО с использованием UML(Unified Modeling Language) объединяет несколько моделей: модель использования, логическую модель, модель реализации, модель процессов и модель развертывания (рисунок 4.1). Предлагается создавать дополняющие друг друга диаграммы:
1) диаграммы вариантов использования;
2) диаграммы классов;
3) диаграммы пакетов;
4) диаграммы последовательностей действий;
5) диаграммы коопераций;
6) диаграммы деятельностей;
7) диаграммы состояний объектов,
8) диаграммы компонентов;
9) диаграммы размещения.
Рисунок 4.1 - Спецификация ПО при использовании UML
Немаловажную роль при проведении ООА играют модели прецедентов. Модели прецедентов описывает способ взаимодействия пользователя с системой.
Прецедент — это набор сценариев использования, в котором каждый экземпляр сценария представляет собой последовательность действий, выполняемых системой для достижения ощутимого для конкретного исполнителя результата.
Создание прецедентов выполняется при последовательности действий:
– определение действующих субъектов;
– создание предварительного списка прецедентов;
– уточнение и обозначение прецедентов;
– определение последовательности событий для каждого прецедента;
– моделирование прецедентов.
При выполнении анализа прецедентов устанавливается картина взаимодействий в системе. После построения описания прецедентов и создания диаграмм взаимодействия, приступают к построению концептуальной модели – основы системы. Пример описания прецедента представлен в Приложении Б. Концептуальная модель не зависит от конкретных способов реализации или использования системы.
Диаграммы вариантов использования
Вариантом использования называется характерная процедура применения разрабатываемой системы конкретным лицом (люди, другие системы, устройства).
Варианты использования в зависимости от целей выполнения конкретной процедуры [15, 19]: основные, вспомогательные и дополнительные.
Пример описания варианта использования системы для формирования выписки из учетной карточки студента (методические указания к Лабораторной работе № 3):
Основные варианты использования должны быть описаны подробно. Подробная форма [24] включает описание типичного хода событий, альтернатив и исключений (Приложение Б).
Диаграммы вариантов использования используют объекты (рисунок 4.2): актёр (действующее лицо), вариант и связь.
Рисунок 4.2 - Условные обозначения диаграмм вариантов использования
Варианты использования могут быть связаны между собой: связи использования (uses) и связи расширения (extends).
Состояние объекта (диаграмма состояний) – есть ситуация в жизненном цикле объекта, во время которого он:
1) удовлетворяет некоторому условию,
2) осуществляет определенную деятельность или
3) ожидает некоторое событие.
Диаграмма состояний показывает состояния объекта, возможные переходы, события или сообщения, вызывающие каждый переход.
Пример диаграммы состояний представлен на рисунке 4.3.
Рисунок 4.3 - Диаграмма варианта использования системы
Обзор CASE-средств
Rational Roseиспользует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования.
В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов.
Рисунок 4.4 - CASE-средство Rational Rose
В результате разработки проекта с помощью CASE-средства Rational Rose (рисунок 4.4) формируются следующие документы:
– диаграммы классов;
– диаграммы состояний;
– диаграммы сценариев;
– диаграммы модулей;
– диаграммы процессов;
– спецификации классов, объектов, атрибутов и операций;
– заготовки текстов программ;
– модель разрабатываемой программной системы.
Последний из перечисленных документов является текстовым файлом, содержащим всю необходимую информацию о проекте (в том числе необходимую для получения всех диаграмм и спецификаций).
Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать категория классов или подсистема.
Пакеты MS Visioи ModelMakerтакже использует методологию ООА. Принцип создания моделей отличается незначительно (рисунок 4.5, 4.6).
Рисунок 4.5 - Создание ОО-модели средствами MS Visio
Рисунок 4.6 - Выбор диаграмм в ModelMaker
Вопросы для самоконтроля
1. В чем заключаются основные принципы ООА?
2. Различия и общее в структурном и объектно-ориентированном подходах.
Практическая работа
Цели:обзор средств проектировщика ПО, получение и закрепление навыков в использовании ООП в проектировании ПО.
Средства выполнения задания: MS Visio, Model Maker, средства пакета MS Office.
Изучить теоретический материал, дать письменные ответы на контрольные вопросы и выполнить практическое задание.
Практическое задание
Построить для задания предыдущей лабораторной работы и описать с предоставлением отчета по выполнению лабораторной работы:
– диаграмму вариантов использования;
– карту диалогов для двух вариантов использования;
– диаграмму взаимодействия (диаграммы последовательности или кооперативные диаграммы);
– диаграмму классов и пакетов – концептуальную модель;
– диаграммы состояния или активности (диаграммы перехода состояний), диаграммы деятельности.
Лабораторная работа № 5