Анализ требований и предварительное проектирование системы
Объектно-ориентированное моделирование
Как известно, проектирование прикладной программной системы начинается с анализа требований, которым она должна будет удовлетворять. Такой анализ проводится с целью понять назначение и условия эксплуатации системы настолько, чтобы суметь составить её предварительный проект.
При объектно-ориентированном подходе анализ требований к системе сводится к разработке моделей этой системы. Моделью системы (или какого-либо другого объекта или явления) мы называем формальное описание системы, в котором выделены основные объекты, составляющие систему, и отношения между этими объектами. Построение моделей – широко распространённый способ изучения сложных объектов и явлений. В модели опущены многочисленные детали, усложняющие понимание. Моделирование широко распространено и в науке, и в технике.
Модели помогают:
- проверить работоспособность разрабатываемой системы на ранних этапах её разработки;
- общаться с заказчиком системы, уточняя его требования к системе;
- вносить (в случае необходимости) изменения в проект системы (как в начале её проектирования, так и на других фазах её жизненного цикла).
В настоящее время существует несколько технологий объектно-ориентированной разработки прикладных программных систем, в основе которых лежит построение и интерпретация на компьютере моделей этих систем. Мы подробно ознакомимся с одной из таких технологий – OMT (Object Modeling Techniques). Эта технология оказала большое влияние на других разработчиков объектно-ориентированных технологий, а книга, в которой она описана, является одной из наиболее часто цитируемых книг по данному направлению. Более того, система обозначений (графический язык) для описания моделей, предложенная в этой книге, широко применяется в других технологиях и в статьях по объектно-ориентированной разработке программных систем.
В технологии OMT проектируемая программная система представляется в виде трёх взаимосвязанных моделей:
- объектной модели, которая представляет статические, структурные аспекты системы, в основном связанные с данными;
- динамической модели, которая описывает работу отдельных частей системы;
- функциональной модели, в которой рассматривается взаимодействие отдельных частей системы (как по данным, так и по управлению) в процессе её работы.
Эти три вида моделей позволяют получить три взаимно-ортого-нальных представления системы в одной системе обозначений. Совокупность моделей системы может быть проинтерпретирована на компьютере (с помощью инструментального программного обеспечения), что позволяет продемонстрировать заказчику характер работы с будущей системой и существенно упрощает согласование предварительного проекта системы.
Модели, разработанные и отлаженные на первой фазе жизненного цикла системы, продолжают использоваться на всех последующих его фазах, облегчая программирование системы, её отладку и тестирование, сопровождение и дальнейшую модификацию.
Как будет показано в дальнейшем, модели системы не связаны с языком программирования, на котором будет реализована система.
Объектная модель системы
Объектная модель описывает структуру объектов, составляющих систему, их атрибуты, операции, взаимосвязи с другими объектами. В объектной модели должны быть отражены те понятия и объекты реального мира, которые важны для разрабатываемой системы. В объектной модели отражается прежде всего прагматика разрабатываемой системы, что выражается в использовании терминологии прикладной области, связанной с использованием разрабатываемой системы.
Объекты и классы
По определению будем называть объектом понятие, абстракцию или любую вещь с чётко очерченными границами, имеющую смысл в контексте рассматриваемой прикладной проблемы. Введение объектов преследует две цели:
- понимание прикладной задачи (проблемы);
- введение основы для реализации на компьютере.
Примеры объектов: форточка, Банк «Империал», Пётр Сидоров, дело № 7461, сберкнижка и т.д.
Цель разработки объектной модели – описать объекты, составляющие в совокупности проектируемую систему, а также выявить и указать различные зависимости между объектами. Декомпозиция проблемы на объекты – творческий, плохо формализуемый процесс.
Все объекты могут быть отличены один от другого: пусть у нас есть два яблока, имеющие одинаковый цвет, форму, вес и вкус; всё равно это два яблока (а не одно), в чём легко убедиться, съев одно из них (другое останется). Между объектами можно установить отношение тождества: объекты, удовлетворяющие этому отношению, одинаковы (тождественны), как вышеупомянутые яблоки. В случае с яблоками иногда говорят о двух экземплярах объекта яблоко. Мы будем считать здесь, что объект и экземпляр объекта – это одно и то же.
Два яблока из предыдущего примера принадлежат одному и тому же классу объектов (именно с этим связана их одинаковость). Цвет, форма, вес и вкус яблока – это его атрибуты: совокупность атрибутов и их значений (например, красное, овальное, стограммовое, кисло-сладкое) характеризует объект.
Все объекты одного и того же класса характеризуются одинаковыми наборами атрибутов. Однако объединение объектов в классы определяется не наборами атрибутов, а семантикой. Так, например, объекты конюшня и лошадь могут иметь одинаковые атрибуты: цена и возраст. При этом они могут относиться к одному классу, если рассматриваются в задаче просто как товар, либо к разным классам, что более естественно.
Рис. 2.1. Пример класса и объекта этого класса
Объединение объектов в классы позволяет ввести в задачу абстракцию и рассмотреть её в более общей постановке. Класс имеет имя (например, лошадь), которое относится ко всем объектам этого класса. Кроме того, в классе вводятся имена атрибутов, которые определены для объектов. В этом смысле описание класса аналогично описанию типа структуры (записи); при этом каждый объект имеет тот же смысл, что и экземпляр структуры (переменная или константа соответствующего типа). Пример класса и его объекта приведён на рисунке 2.1.
Атрибуты объектов
Атрибут – это значение, характеризующее объект в его классе. Примеры атрибутов: категория, баланс, кредит (атрибуты объектов класса счёт); имя, возраст, вес (атрибуты объектов класса человек) и т.д.
Среди атрибутов различаются постоянные атрибуты (константы) и переменные атрибуты. Постоянные атрибуты характеризуют объект в его классе (например, номер счёта, категория, имя человека и т.п.). Текущие значения переменных атрибутов характеризуют текущее состояние объекта (например, баланс счёта, возраст человека и т.п.); изменяя значения этих атрибутов, мы изменяем состояние объекта.
Атрибуты перечисляются во второй части прямоугольника, изображающего класс (рис. 2.1). Иногда указывается тип атрибутов (ведь каждый атрибут – это некоторое значение) и начальное значение переменных атрибутов (совокупность начальных значений этих атрибутов задаёт начальное состояние объекта).
Следует отметить, что, говоря об объектах и их классах, мы не подразумеваем никакого объектно-ориентированного языка программирования. Это, в частности, выражается в том, что на данном этапе разработки программной системы следует рассматривать только такие атрибуты, которые имеют смысл в реальности (все атрибуты объектов класса счёт – рисунок 2.1 – обладают этим свойством). Атрибуты связаны с особенностями общей реализации. Например, если известно, что будет использоваться база данных, в которой каждый объект имеет уникальный идентификатор, то включать этот идентификатор в число атрибутов объекта на данном этапе не следует. Дело в том, что, вводя такие атрибуты, мы ограничиваем возможности реализации системы. Так, вводя в качестве атрибута уникальный идентификатор объекта в базе данных, мы уже в самом начале проектирования отказываемся от использования СУБД, которые такой идентификатор не поддерживают.
Операции и методы
Операция – это функция (или преобразование), которую можно применять к объектам данного класса.
Все объекты данного класса используют один и тот же экземпляр каждой операции (т.е. увеличение количества объектов некоторого класса не приводит к увеличению количества загруженного программного кода). Объект, из которого вызвана операция, передаётся ей в качестве её неявного аргумента (параметра).
Примеры операций: проверить, снять, поместить (для объектов класса счёт – рис. 2.1), открыть на чтение, читать, закрыть (для объектов класса файл – рис. 2.2) и т.п.
Одна и та же операция может, вообще говоря, применяться к объектам разных классов: такая операция называется полиморфной, так как она может иметь разные формы для разных классов. Например, для объектов классов вектор и комплексное число можно определить операцию +; эта операция будет полиморфной, так как сложение векторов и сложение комплексных чисел, вообще говоря, разные операции.
Рис. 2.2. Другие примеры классов
Каждой операции соответствует метод – реализация этой операции для объектов данного класса. Таким образом, операция – это спецификация метода, метод – реализация операции. Например, в классе файл может быть определена операция печать (print). Эта операция может быть реализована разными методами: (а) печать двоичного файла; (б) печать текстового файла и др. Логически эти методы выполняют одну и ту же операцию, хотя реализуются они разными фрагментами кода.
Каждая операция имеет один неявный аргумент – объект, к которому она применяется. Кроме того, операция может иметь и другие аргументы (параметры). Эти дополнительные аргументы параметризуют операцию, но не связаны с выбором метода. Метод связан только с классом и объектом (некоторые объектно-ориентированные языки, например C++, допускают одну и ту же операцию с разным числом аргументов, причём используя то или иное число аргументов, мы практически выбираем один из методов, связанных с такой операцией; на этапе предварительного проектирования системы удобнее считать эти операции различными, давая им разные имена, чтобы не усложнять проектирование).
Операция (и реализующие её методы) определяется своей сигнатурой, которая включает, помимо имени операции, типы (классы) всех её аргументов и тип (класс) результата (возвращаемого значения). Все методы, реализующие операцию, должны иметь такую же сигнатуру, что и реализуемая ими операция.
Операции перечисляются в третьей части прямоугольника (рис. 2.1), описывающего класс. Каждая операция должна быть представлена своей сигнатурой, однако на ранних стадиях проектирования можно ограничиваться указанием имени операции, отложив полное определение сигнатуры на конец рассматриваемой фазы жизненного цикла (либо даже на последующие фазы). В графическом языке технологии OMT тип любого объекта данных указывается вслед за именем этого объекта после двоеточия (как в языке Паскаль).
При моделировании системы полезно различать операции, имеющие побочные эффекты (эти эффекты выражаются в изменении значений атрибутов объекта, т.е. в изменении его состояния), и операции, которые выдают требуемое значение, не меняя состояния объекта. Эти последние операции называются запросами.
Запросы без аргументов (за исключением неявного аргумента – объекта, к которому применяется операция) могут рассматриваться как производные атрибуты. Значения производных атрибутов зависят от значений основных атрибутов. В этом их отличие от основных атрибутов, значения которых независимы. Следовательно, значения основных атрибутов объекта определяют как его состояние, так и значения его производных атрибутов. Так, например, длина, ширина и высота комнаты – её основные атрибуты, а площадь и кубатура – производные атрибуты; такой атрибут, как кубатура, нужен для того, чтобы не вычислять кубатуру комнаты всякий раз, когда понадобится её значение.
Выбор основных атрибутов объектов произволен, но в их число не следует включать такие, значения которых определяются значениями других атрибутов, так что на самом деле они являются производными.
Значения некоторых атрибутов объекта могут быть доступны только операциям этого объекта. Такие атрибуты называются закрытыми. На рисунке 2.3 показаны закрытые атрибуты для объектов класса счёт. Значения закрытых атрибутов объекта можно узнать вне объекта только в том случае, если среди операций этого объекта определены соответствующие запросы. Аналогично, в объекте можно определить и закрытые (вспомогательные) операции, однако на ранних стадиях проектирования этого, как правило, не делают, так как выделение закрытых операций связано в основном с реализацией системы.
Рис. 2.3. Открытые и закрытые атрибуты и операции
Таким образом, для задания класса необходимо указать имя этого класса, а затем перечислить его атрибуты и операции (или методы). Полное описание объекта на графическом языке OMT имеет вид, изображённый на рисунке 2.4. Так, на рисунке 2.5 приведены сокращения обозначения классов для нашего основного примера – системы обслуживания клиентов банковского консорциума.
| ИМЯ_КЛАССА |
| имя_атрибута 1: тип_1 = значение_по_умолчанию_1 имя_атрибута 2: тип_2 = значение_по_умолчанию_2 . . . . . . . . . . . . . . . |
| имя_операции_1 (список_аргументов_1): тип_результата сигнатура_операции_2 сигнатура_операции_3 . . . . . . . . . . . . . . . . |
Рис. 2.4. Полное представление объекта в OMT
Однако иногда бывает удобно пользоваться сокращённым описанием класса, когда в прямоугольнике, изображающем этот класс, указывается только имя класса.
Рис. 2.5. Возможные классы для системы AMT
(банковское обслуживание)