Конструирование объектной модели. Методика построения объектной модели
Построение объектной модели задачи с использованием языка моделирования UML.
РАБОТА ВЫПОЛНЯЕТСЯ в StarUML
Время выполнения:
2 – 3 занятия
К защите работы должен быть предоставлен проект, созданный в пакете Rational Rose, включающий три вида диаграмм: прецедентов, классов (интерфейс, данные) и последовательностей для каждой функции.
ПРИМЕР ЗАДАНИЯ:
Необходимо обеспечить хранение в базе данных следующей информации:
- информация о студентах
o Ф.И.О.,
o адрес,
o номер зачетки,
o группа);
- информация о специальностях
o наименование специальности,
o шифр;
- информация о группах
o специальность,
o год поступления,
o номер группы.
Обеспечить выдачу документа “Список группы”, содержащего поля:
· Ф.И.О.,
· номер зачетки.
Порядок выполнения работы
Построение объектной модели выполняется в пакете Rational Rose. Для этого создадим пустой проект. Начинать выполнение работы следует с диаграммы прецедентов. Ее строят в области Main секции Use Case View, как показано на рис.9.
Перед началом построения диаграммы необходимо определить роли пользователей системы (актеров) и их функции (прецеденты). В нашем случае с системой работают два актера – это «Работник учебного отдела» и «Работник деканата». В функции работника учебного отдела входит ведение списка специальностей (под ведением списка мы будем понимать добавление записей, их корректировку и удаление). Функции работника деканата включают в себя ведение списка студентов и ведение списка групп.
Построенная диаграмма изображена на рис. 10.
Далее в секции Logical View следует создать две диаграммы классов. Для этого можно создать два пакета. Первая диаграмма должна содержать классы интерфейса проектируемого приложения (см. рис. 11). На данном рисунке в классах «Список групп» и «Список студентов» опущены операции добавления, изменения и удаления во избежание загромождения рисунка. Список группы (нижний класс) является выходным документом (перед ним следует класс «Выбор группы», т.к. необходимо получить список студентов определенной группы). Вторая диаграмма – сущности базы данных (см. рис. 12).
В построенной диаграмме классов отображены все формы будущего приложения и их взаимосвязь.
Следует проставить ключевые поля и установить связь (из контекстного меню стрелки - Multiplicity).
Следующий этап построения объектной модели – создание диаграмм последовательностей. Диаграммы последовательностей создаются для каждого прецедента на диаграмме прецедентов. Чтобы добавить диаграмму последовательностей к прецеденту необходимо выбрать его в дереве и вызвать на нем контекстное меню (NewàSequence Diagram) как показано на рис. 13.
Пример диаграммы последовательностей для прецедента «Ведение списка специальностей» представлен на рис. 14.
Следует отметить, что при построении данного вида диаграммы для выходного документа «Список группы» в нашем случае следует сначала выбрать группу на форме «Выбор группы» (на нее в свою очередь должны попасть данные из сущности «Группа»), а затем отобразить форму выходного документа, на которую данные поступают уже из сущности «Студент».
Зависимости между классами (объектами)
С каждым объектом связана структура данных, полями которой являются атрибуты этого объекта и указатели функций (фрагментов кода), реализующих операции этого объекта (отметим, что указатели функций в результате оптимизации кода обычно заменяются на обращения к этим функциям). Таким образом, объект - это некоторая структура данных, тип которой соответствует классу этого объекта.
Между объектами можно устанавливать зависимости по данным. Эти зависимости выражают связи или отношения между классами указанных объектов. Примеры таких зависимостей изображены на рисунке 2.6 (первые две зависимости - бинарные, третья зависимость - тренарная). Зависимость изображается линией, соединяющей классы над которой надписано имя этой зависимости, или указаны роли объектов (классов) в этой зависимости (указание ролей - наиболее удобный способ идентификации зависимости).
Рис. 2.6. Зависимости между классами
Зависимости между классами являются двусторонними: все классы в зависимости равноправны. Это так даже в тех случаях, когда имя зависимости как бы вносит направление в эту зависимость. Так, в первом примере на рисунке 2.6 имя зависимости имеет_столицу предполагает, что зависимость направлена от класса страна к классу город (двусторонность зависимости вроде бы пропала); но следует иметь в виду, что эта зависимость двусторонняя в том смысле, что одновременно с ней существует и обратная зависимость является_столицей. Точно таким же образом, во втором примере на рисунке 2.6 можно рассматривать пару зависимостей владеет-принадлежит. Подобных недоразумений можно избежать, если идентифицировать зависимости не по именам, а по наименованиям ролей классов, составляющих зависимость.
В языках программирования зависимости между классами (объектами) обычно реализуются с помощью ссылок (указателей) из одного класса (объекта) на другой. Представление зависимостей с помощью ссылок обнаруживает тот факт, что зависимость является свойством пары классов, а не какого-либо одного из них, т.е. зависимость - это отношение. Отметим, что хотя зависимости между объектами двунаправлены, их не обязательно реализовать в программах как двунаправленные, оставляя ссылки лишь в тех классах, где это необходимо для программы.
Дальнейшие примеры зависимостей между классами приведены на рисунке 2.7. Первый пример показывает зависимость между клиентом банка и его счетами. Клиент банка может иметь одновременно несколько счетов в этом банке, либо вовсе не иметь счета (когда он впервые становится клиентом банка). Таким образом, нужно изобразить зависимость между клиентом и несколькими счетами, что и сделано на рисунке 2.7. Второй пример показывает зависимость между пересекающимися кривыми (в частности, прямыми) линиями. Можно рассматривать 2, 3, и более таких линий, причем они могут иметь несколько точек пересечения. Наконец, третий пример показывает необязательную (optional) зависимость: компьютер может иметь, а может и не иметь мышь.
Зависимостям между классами соответствуют зависимости между объектами этих классов. На рисунке 2.8 показаны зависимости между объектами для первого примера рисунка 2.6; на рисунке 2.9 показаны зависимости между объектами для примеров, изображенных на рисунке 2.7.
Рис. 2.7. Дальнейшие примеры зависимостей. Обозначения
Рис. 2.8. Зависимости между объектами
Отметим, что при изображении зависимостей между объектами мы, как правило, знаем количество объектов и не нуждаемся в таких обозначениях как "несколько", "два и более", "не обязательно".
При проектировании системы удобнее оперировать не объектами, а классами.
Рис. 2.9. Более сложные зависимости между объектами
Понятие зависимости перенесено в объектно-ориентированную технологию проектирования программных систем из технологии проектирования (и моделирования) баз данных, где зависимости используются с давних пор. Языки программирования, как правило, не поддерживают явного описания зависимостей. Тем не менее описание зависимостей очень полезно при разработке программных систем. Технология OMT использует зависимости при интерпретации диаграмм, описывающих систему.
Теперь у нас есть все необходимые понятия, чтобы описать процесс построения объектной модели. Этот процесс включает в себя следующие этапы:
- определение объектов и классов;
- подготовка словаря данных;
- определение зависимостей между объектами;
- определение атрибутов объектов и связей;
- организация и упрощение классов при использовании наследования;
- дальнейшее исследование и усовершенствование модели.
Теперь у нас есть все необходимые понятия, чтобы описать процесс построения объектной модели. Этот процесс включает в себя следующие этапы:
· определение объектов и классов;
· подготовка словаря данных;
· определение зависимостей между объектами;
· определение атрибутов объектов и связей;
· организация и упрощение классов при использовании наследования;
· дальнейшее исследование и усовершенствование модели.
2.2.1. Определение классов. Анализ внешних требований к проектируемой ПС позволяет определить объекты и классы объектов, связанные с прикладной проблемой, которую должна решать эта система. Все классы должны быть осмыслены в рассматриваемой прикладной области; классов, связанных с компьютерной реализацией, как например список, стек и т.п. на этом этапе вводить не следует.
Начать нужно с выделения возможных классов из письменной постановки прикладной задачи (технического задания и другой документации, предоставленной заказчиком). Следует иметь в виду, что это очень сложный и ответственный этап разработки, так как от него во многом зависит дальнейшая судьба проекта.
При определении возможных классов нужно постараться выделить как можно больше классов, выписывая имя каждого класса, который приходит на ум. В частности, каждому существительному, встречающемуся в предварительной постановке задачи, может соответствовать класс. Поэтому при выделении возможных классов каждому такому существительному обычно сопоставляется возможный класс.
· избыточные классы: если два или несколько классов выражают одинаковую информацию, следует сохранить только один из них;
· нерелевантные (не имеющие прямого отношения к проблеме) классы : для каждого имени возможного класса оценивается, насколько он необходим в будущей системе (оценить это часто бывает весьма непросто); нерелевантные классы исключаются;
· нечетко определенные (с точки зрения проблемы) классы (см. п. 2.3.1);
· атрибуты : некоторым существительным больше соответствуют не классы, а атрибуты; такие существительные, как правило, описывают свойства объектов (например, имя, возраст, вес, адрес и т.п.);
· операции : некоторым существительным больше соответствуют не классы, а имена операций (например, телефонный_вызов вряд ли означает какой-либо класс);
· роли : некоторые существительные определяют имена ролей в объектной модели (например, владелец, водитель, начальник, служащий; все эти имена связаны с ролями в различных зависимостях объектов класса человек);
· реализационные конструкции : именам, больше связанным с программированием и компьютерной аппаратурой, не следует на данном этапе сопоставлять классов, так как они не отражают особенностей проектируемой ПС; примеры таких имен: подпрограмма, процесс, алгоритм, прерывание и т.п.
После исключения имен всех ненужных (лишних) возможных классов будет получен предварительный список классов, составляющих проектируемую систему.
2.2.2. Подготовка словаря данных. Отдельные слова имеют слишком много интерпретаций. Поэтому необходимо в самом начале проектирования подготовить словарь данных , содержащий четкие и недвусмысленные определения всех объектов (классов), атрибутов, операций, ролей и других сущностей, рассматриваемых в проекте. Без такого словаря обсуждение проекта с коллегами по разработке и заказчиками системы не имеет смысла, так как каждый может по-своему интерпретировать обсуждаемые термины. Пример словаря см. в п. 2.3.2.
2.2.3. Определение зависимостей. На следующем этапе построения объектной модели определяются зависимости между классами. Прежде всего из классов исключаются атрибуты, являющиеся явными ссылками на другие классы; такие атрибуты заменяются зависимостями. Смысл такой замены в том, что зависимости представляют собой абстракцию того же уровня, что и классы, и потому не оказывают непосредственного влияния на будущую реализацию (ссылка на класс лишь один из способов реализации зависимостей).
Аналогично тому, как имена возможных классов получались из существительных, встречающихся в предварительной постановке прикладной задачи, имена возможных зависимостей могут быть получены из глаголов или глагольных оборотов , встречающихся в указанном документе. Так обычно описываются: физическое положение (следует_за, является_частью, содержится_в), направленное действие (приводит_в_движение), общение (разговаривает_с), принадлежность (имеет, является_частью) и т.п. Пример выделения явных и неявных глагольных оборотов из предварительной постановки конкретной прикладной задачи рассмотрен в п. 2.3.3.
Затем следует убрать ненужные или неправильные зависимости, используя следующие критерии:
· зависимости между исключенными классами должны быть исключены, либо переформулированы в терминах оставшихся классов (см. п. 2.3.3);
· нерелевантные зависимости и зависимости, связанные с реализацией, должны быть исключены (см. п. 2.3.3);
· действия: зависимость должна описывать структурные свойства прикладной области, а не малосущественные события (см. п. 2.3.3);
· тренарные зависимости: большую часть зависимостей между тремя или большим числом классов можно разложить на несколько бинарных зависимостей, используя в случае необходимости квалификаторы (см. п. 2.3.3); в некоторых (редких) случаях такое разложение осуществить не удается; например, тренарная зависимость "Профессор читает курс в аудитории 628" не может быть разложена на бинарные без потери информации;
· производные зависимости: нужно исключать зависимости, которые можно выразить через другие зависимости, так как они избыточны (см. п. 2.3.3); при исключении избыточных (производных) зависимостей нужно быть особенно осторожным, так как не все дублирующие одна другую зависимости между классами избыточны; в некоторых случаях другие зависимости позволяют установить только существование еще одной производной зависимости, но не позволяют установить кратность этой зависимости; например, в случае, представленном на рис. 2.36, фирма имеет много служащих и владеет многими компьютерами; каждому служащему предоставлено для персонального использования несколько компьютеров, кроме того, имеются компьютеры общего пользования; кратность зависимости предоставлен_для_использования не может быть выведена из зависимостей служит и владеет; хотя производные зависимости и не добавляют новой информации, они часто бывают удобны; в этих случаях их можно указывать на диаграмме, пометив косой чертой.
Рис. 2.36. Неизбыточные зависимости
Удалив избыточные зависимости, нужно уточнить семантику оставшихся зависимостей следующим образом:
· неверно названные зависимости: их следует переименовать, чтобы смысл их стал понятен (см. п. 2.3.3);
· имена ролей: нужно добавить имена ролей там, где это необходимо; имя роли описывает роль, которую играет соответствующий класс в данной зависимости с точки зрения другого класса, участвующего в этой зависимости; если имя роли ясно из имени класса, его можно не указывать (см. п. 2.3.3);
· квалификаторы: добавляя квалификаторы там, где это необходимо, мы вносим элементы контекста, что позволяет добиться однозначной идентификации объектов; квалификаторы позволяют также упростить некоторые зависимости, понизив их кратность;
· кратность: необходимо добавить обозначения кратности зависимостей; при этом следует помнить, что кратность зависимостей может меняться в процессе дальнейшего анализа требований к системе;
· неучтенные зависимости должны быть выявлены и добавлены в модель.
2.2.4. Уточнение атрибутов. На следующем этапе уточняется система атрибутов: корректируются атрибуты классов, вводятся, в случае необходимости, новые атрибуты. Атрибуты выражают свойства объектов рассматриваемого класса, либо определяют их текущее состояние.
Атрибуты обычно соответствуют существительным; например цвет_автомобиля (свойство объекта), позиция_курсора (состояние объекта). Атрибуты, как правило, слабо влияют на структуру объектной модели.
Не следует стремиться определить как можно больше атрибутов: большое количество атрибутов усложняет модель, затрудняет понимание проблемы. Необходимо вводить только те атрибуты, которые имеют отношение к проектируемой прикладной системе, опуская случайные, малосущественные и производные атрибуты.
Наряду с атрибутами объектов необходимо ввести и атрибуты зависимостей между классами (связей между объектами).
При уточнении атрибутов руководствуются следующими критериями:
· Замена атрибутов на объекты . Если наличие некоторой сущности важнее, чем ее значение, то это объект, если важнее значение, то это атрибут: например, начальник - это объект (неважно, кто именно начальник, главное, чтобы кто-то им был), зарплата - это атрибут (ее значение весьма существенно); город - всегда объект, хотя в некоторых случаях может показаться, что это атрибут (например, город как часть адреса фирмы); в тех случаях, когда нужно, чтобы город был атрибутом, следует определить зависимость (скажем, находится) между классами фирма и город.
· Квалификаторы . Если значение атрибута зависит от конкретного контекста, его следует сделать квалификатором (см. п. 2.3.4).
· Имена . Именам обычно лучше соответствуют квалификаторы, чем атрибуты объектов; во всех случаях, когда имя позволяет сделать выбор из объектов некоторого множества, его следует сделать квалификатором (см. п. 2.3.4).
· Идентификаторы . Идентификаторы объектов связаны с их реализацией. На ранних стадиях проектирования их не следует рассматривать в качестве атрибутов.
· Атрибуты связей . Если некоторое свойство характеризует не объект сам по себе, а его связь с другим объектом (объектами), то это атрибут связи, а не атрибут объекта.
· Внутренние значения . Атрибуты, определяющие лишь внутреннее состояние объекта, незаметное вне объекта, следует исключить из рассмотрения.
· Несущественные детали . Атрибуты, не влияющие на выполнение большей части операций, рекомендуется опустить.
2.2.5. Организация системы классов, используя наследование. Далее необходимо постараться найти суперклассы для введенных классов. Это полезно, так как проясняет структуру модели и облегчает последующую реализацию. Пример рассмотрен в п. 2.3.5.
2.2.6. Дальнейшее исследование и усовершенствование модели. Лишь в очень редких случаях построенная объектная модель сразу же оказывается корректной. Модель должна быть исследована и отлажена. Некоторые ошибки могут быть найдены при исследовании модели без компьютера, другие - при ее интерпретации совместно с динамической и функциональной моделями на компьютере (эти модели строятся после того, как объектная модель уже построена).
Здесь мы рассмотрим приемы бескомпьютерного поиска и исправления ошибок в объектной модели. В их основе лежат внешние признаки, по которым можно находить ошибки в модели; эти признаки могут быть объединены в следующие группы.
Признаки пропущенного объекта (класса):
· несимметричности связей и обобщений (наследований); для исправления ошибки необходимо добавить пропущенные классы;
· несоответствие атрибутов и операций у класса; для исправления ошибки необходимо расщепить класс на несколько других классов, так чтобы атрибуты и операции новых классов соответствовали друг другу;
· обнаружена операция, не имеющая удовлетворительного целевого класса; для исправления ошибки необходимо добавить пропущенный целевой класс;
· обнаружено несколько зависимостей с одинаковыми именами и назначением; для исправления ошибки необходимо сделать обобщение и добавить пропущенный суперкласс.
Признаки ненужного (лишнего) класса:
· нехватка атрибутов, операций и зависимостей у некоторого класса; для исправления ошибки необходимо подумать, не следует ли исключить такой класс.
Признаки пропущенных зависимостей:
· отсутствуют пути доступа к операциям; для исправления ошибки необходимо добавить новые зависимости, обеспечивающие возможности обслуживания соответствующих запросов.
Признаки ненужных (лишних) зависимостей:
· избыточная информация в зависимостях; для исправления ошибки необходимо исключить зависимости, не добавляющие новой информации, или пометить их как производные зависимости;
· не хватает операций, пересекающих зависимость; для исправления ошибки необходимо подумать, не следует ли исключить такую зависимость.
Признаки неправильного размещения зависимостей:
· имена ролей слишком широки или слишком узки для их классов; для исправления ошибки необходимо переместить зависимость вверх или вниз по иерархии классов.
Признаки неправильного размещения атрибутов:
· нет необходимости доступа к объекту по значениям одного из его атрибутов; для исправления ошибки необходимо рассмотреть, нужно ли ввести квалифицированную зависимость.
Примеры практического применения описанных признаков см. в п. 2.3.6.
Пример объектной модели
Рассмотрим процесс построения объектной модели для системы банковского обслуживания в процессе анализа требований и предварительного проектирования этой системы. Для построения объектной модели рассматриваемой системы нам необходимо выполнить все этапы, перечисленные в п 2.2.
2.3.1. Определение объектов и классов. В п. 1.3 сформулирована задача и приведена схема сети банковского обслуживания (рис. 1.3). Анализируя эту постановку задачи, можно выделить возможные классы, сопоставив их существительным, упомянутым в ее предварительной формулировке; получится следующий список возможных имен классов (в алфавитном порядке):
Исследуем этот список, исключая из него имена классов в соответствии с рекомендациями п. 2.2.1:
· избыточные классы : ясно, что клиент и пользователь означают одно и то же понятие; для банковской системы более естественно оставить класс клиент;
· нерелевантные классы : таким классом является класс цена (он не имеет непосредственного отношения к работе банковской сети);
· нечетко определенные классы : такими классами являются служба_ведения_записей и проверка безопасности (эти службы входят в состав проводки), система (в нашем случае непонятно, что это такое), банковская_сеть (вся ПС будет обслуживать банковскую сеть);
· атрибуты : данные проводки, данные счета, деньги (имеются в виду реальные деньги, выдаваемые клиенту кассиром или банкоматом, либо принимаемые кассиром), квитанция (выдается клиенту вместе с деньгами) более естественно иметь в качестве атрибутов;
· реализационные конструкции выражают такие имена как программное_обеспечение и доступ; их тоже следует исключить из списка имен возможных классов.
После исключения всех лишних имен возможных классов получаем следующий список классов, составляющих проектируемую систему банковского обслуживания (эти классы представлены на рис. 2.5):
2.3.2. Подготовка словаря данных. Приведем часть словаря данных, содержащую определения классов, используемых в проекте.
ATM (банкомат) - терминал, который дает возможность клиенту осуществлять свою собственную проводку, используя для идентификации свою карточку. ATM (банкомат) взаимодействует с клиентом, чтобы получить необходимую информацию для проводки, посылает информацию для проводки центральному_компьютеру, чтобы он проверил ее и в дальнейшем использовал при выполнении проводки и выдает деньги и квитанцию клиенту. Предполагается, что ATM (банкомату) не требуется работать независимо от сети.
Банк - финансовая организация, которая содержит счета своих клиентов и выпускает карточки, санкционирующие доступ к счетам через сеть ATM (банкоматов).
Карточка - пластиковая карточка, врученная банком своему клиенту, которая санкционирует доступ к счетам через сеть ATM (банкоматов). Каждая карточка содержит код банка и номер карточки, закодированные в соответствии с национальными стандартами на банковские карточки. Код_банка однозначно идентифицирует банк внутри консорциума. Номер_карточки определяет счета, к которым карточка имеет доступ. Карточка не обязательно обеспечивает доступ ко всем счетам клиента. Каждой карточкой может владеть только один клиент, но у нее может существовать несколько копий, так что необходимо рассмотреть возможность одновременного использования одной и той же карточки с разных ATM (банкоматов).
Кассир - служащий банка, который имеет право осуществлять проводки с кассовых_ терминалов, а также принимать и выдавать деньги и чеки клиентам. Проводки, деньги и чеки, с которыми работает каждый кассир, должны протоколироваться и правильно учитываться.
Кассовый_терминал - терминал, с которого кассир осуществляет проводки для клиентов. Когда кассир принимает и выдает деньги и чеки, кассовый_терминал печатает квитанции. Кассовый_терминал взаимодействует с компьютером_банка, чтобы проверить и выполнить проводку.
Клиент - держатель одного или нескольких счетов в банке. Клиент может состоять из одного или нескольких лиц, или организаций. То же самое лицо, держащее счет и в другом банке рассматривается как другой клиент.
Компьютер_банка - компьютер, принадлежащий банку, который взаимодействует с сетью ATM (банкоматов) и собственными кассовыми_терминалами банка. Банк может иметь свою внутреннюю компьютерную сеть для обработки счетов, но здесь мы рассматриваем только тот компьютер_банка, который взаимодействует с сетью ATM.
Консорциум - объединение банков, которое обеспечивает работу сети ATM (банкоматов). Сеть передает в консорциум проводки банков.
Проводка - единичный интегрированный запрос на выполнение некоторой последовательности операций над счетами одного клиента. Было сделано предположение, что ATM (банкоматы) только выдают деньги, однако для них не следует исключать возможности печати чеков или приема денег и чеков. Хотелось бы также обеспечить гибкость системы, которая в дальнейшем обеспечит возможность одновременной обработки счетов разных клиентов, хотя пока этого не требуется. Различные операции должны быть правильно сбалансированы.
Счет - единичный банковский счет, над которым выполняются проводки. Счета могут быть различных типов; клиент может иметь несколько счетов.
Центральный_компьютер - компьютер, принадлежащий консорциуму, который распределяет проводки и их результаты между ATM (банкоматами) и компьютерами_банков. Центральный_компьютер проверяет коды банков, но не выполняет проводок.
2.3.3. Определение зависимостей. Следуя рекомендациям п. 2.2.3, выделяем явные и неявные глагольные обороты из предварительной постановки задачи и рассматриваем их как имена возможных зависимостей. Из постановки задачи о банковской сети (см. п. 1.3) можно извлечь следующие обороты:
Глагольные обороты (явные и неявные):
Банковская сеть включает кассиров и ATM"ы
Консорциум распределяет результаты проводок по ATM
Банк владеет компьютером банка
Компьютер банка поддерживает счета
Банк владеет кассовыми терминалами
Кассовый терминал взаимодействует с компьютером банка
Кассир вводит проводку над счетом
ATM"ы взаимодействуют с центральным компьютером во время проводки
Центральный компьютер взаимодействует с компьютером банка
ATM принимает карточку
ATM общается с пользователем
ATM выдает наличные деньги
ATM печатает квитанции
Система регулирует коллективный доступ
Банк предоставляет программное обеспечение
Консорциум состоит из банков
Консорциум владеет центральным компьютером
Система обеспечивает протоколирование
Система обеспечивает безопасность
Клиенты имеют карточки
Карточка обеспечивает доступ к счету
В банке служат кассиры
Затем исключаем ненужные или неправильные зависимости, используя критерии, сформулированные в п. 2.2.3:
· зависимости между исключенными классами: исключаются следующие зависимости: Банковская сеть включает кассиров и ATM"ы (класс банковская_сеть исключен), ATM печатает квитанции (класс квитанция исключен), ATM выдает наличные деньги (класс деньги исключен), Система обеспечивает протоколирование проводок (класс служба_ведения_записей исключен), Система обеспечивает безопасность ведения счетов (класс служба_безопасности исключен), Банки предоставляют программное обеспечение (класс программное_обеспечение исключен);
· нерелевантные зависимости и зависимости, связанные с реализацией: зависимость "Система регулирует коллективный доступ" исключается как связанная с реализацией;
· действия описываются такими зависимостями как "ATM принимает карточку" и "ATM общается с пользователем"; мы исключаем эти зависимости;
· тренарные зависимости: зависимость "Кассир вводит проводку над счетом" раскладывается на две бинарные зависимости "Кассир вводит проводку" и "Проводка относится к счету". Зависимость "ATM"ы взаимодействуют с центральным компьютером во время проводки" раскладывается на "ATM"ы взаимодействуют с центральным компьютером" и "Проводка начинается с ATM";
· производные зависимости: зависимость "Консорциум распределяет ATM"ы" является следствием зависимостей "Консорциум владеет центральным компьютером" и "ATM"ы взаимодействуют с центральным компьютером".
Удалив избыточные зависимости, получим следующий список зависимостей:
Банк владеет компьютером банка
Компьютер банка поддерживает счета
Банк владеет кассовыми терминалами
Кассовый терминал взаимодействует с компьютером банка
Кассир вводит проводку
Проводка относится к счету
ATM"ы взаимодействуют с центральным компьютером
Проводка начинается с ATM
Центральный компьютер взаимодействует с компьютером банка
Консорциум состоит из банков
Консорциум владеет центральным компьютером
Клиенты имеют карточки
Карточка обеспечивает доступ к счету
В банке служат кассиры
Уточним семантику оставшихся зависимостей следующим образом:
· переименуем неверно названные зависимости, чтобы смысл их стал более понятен; так зависимость Компьютер_банка поддерживает счета удобнее заменить зависимостью Банк держит счета.
· имена ролей можно не использовать, так как они ясны из имен классов, участвующих в зависимости, как например, для зависимости ATM"ы взаимодействуют с центральным компьютером;
· неучтенные зависимости: Проводка начинается с кассового_терминала, Клиенты имеют счета, Проводка регистрируется карточкой следует добавить в модель.
После уточнения зависимостей можно составить исходную версию объектной диаграммы. Для рассматриваемой задачи она будет иметь вид, представленный на рис. 2.37.
Рис. 2.37. Первая версия объектной диаграммы для банковской сети
2.3.4. Уточнение атрибутов. Применяя критерии, сформулированные в п. 2.2.4, получим:
Карточка содержит код_банка и код_карточки; их можно считать атрибутами объектов класса карточка, но удобнее использовать в качестве квалификаторов, так как код_банка обеспечивает выбор банка, сокращая кратность зависимости консорциум - банк; для аналогичного использования кода_карточки необходимо добавить зависимость Банк выпускает карточки, квалификатором которой будет код_карточки.
После внесения перечисленных изменений диаграмма примет вид, представленный на рис. 2.38.
2.3.5. Организация системы классов с использованием наследования. В рассматриваемом примере естественно определить суперклассы для объектов, определяющих различные терминалы: кассовый_терминал и ATM (банкомат), и для объектов, определяющих проводки: проводка_кассира и удаленная_проводка (с банкомата).
Внеся соответствующие изменения, получим объектную диаграмму, представленную на рис. 2.39.
Рис. 2.38. Объектная диаграмма для банковской сети после уточнения атрибутов и добавления квалификаторов
Рис. 2.39. Объектная диаграмма для банковской с учетом наследования
2.3.6. Дальнейшее усовершенствование модели. Карточка выступает в двух сущностях: как регистрационная единица в банке (сберкнижка), обеспечивающая клиенту доступ к его счетам, и как структура данных, с которой работает ATM. Поэтому удобно расщепить класс карточка на два класса: регистрация_карточки и карточка; первый из этих классов обеспечивает клиенту доступ к его счетам в банке, а второй определяет структуру данных, с которой работает ATM.
Класс проводка удобно представить как агрегацию классов изменение, так как проводка - это согласованная последовательность внесения изменений в счета и другие банковские документы; при работе с банковскими документами рассматривается три вида изменений: снятие, помещение и запрос.
Класс банк естественно объединить с классом компьютер_банка, а класс консорциум - с классом центральный_компьютер.
Рис. 2.40. Окончательный вид объектной диаграммы для банковской сети
После внесения перечисленных изменений объектная диаграмма примет вид, представленный на рис. 2.40. На этом построение объектной модели этапа предварительного проектирования заканчивается. Дальнейшие уточнения объектной модели будут производиться на следующих фазах ЖЦ системы.
Выделение подсистем
2.4.1. Понятие подсистемы. Итак, ПС представляет собой множество взаимозависимых объектов. Каждый объект характеризуется набором атрибутов, значения которых определяют состояние объекта, и набором операций, которые можно применять к этому объекту. При разработке ПС удобно считать, что все атрибуты объектов являются закрытыми (т.е. они не доступны вне объекта, и для того, чтобы в некотором объекте узнать значение атрибута другого объекта, или изменить его, необходимо воспользоваться одной из открытых операций этого объекта, если, конечно, такая операция определена). Операции объектов могут быть как открытыми, так и закрытыми.
Таким образом, каждый объект имеет строго определенный интерфейс , т.е. набор открытых операций, которые можно применять к этому объекту. Все объекты одного класса имеют одинаковый интерфейс. Интерфейс класса (а, следовательно, и каждого объекта этого класса) задается списком сигнатур его открытых (общедоступных) операций (и реализующих их методов); сигнатуры закрытых операций в интерфейс объектов соответствующего класса не входят.
Объектная модель системы задает множество взаимозависимых объектов, составляющих систему, и, следовательно, определяет набор интерфейсов, доступных внутри системы. Все возможности по обработке данных внутри системы (т.е. в каждом объекте, входящем в состав системы) определяются этим набором интерфейсов, который определяет внутреннее окружение (или среду) системы .
Наряду с внутренним окружением системы можно определить ее внешнее окружение . Оно определяется функциями (операциями), реализованными в составе системного программного обеспечения (т.е. операционной системы, системы программирования, различных редакторов, СУБД и т.п.), а также в других прикладных системах и библиотеках, используемых совместно с системой. Объекты и операции, составляющие внешнее окружение системы, тоже могут быть доступны внутри системы. Чтобы не упустить этого из виду, можно было бы добавить в объектную модель еще один объект, интерфейс которого представлял бы возможности внешнего окружения, используемые в системе (такой интерфейс обычно представляет лишь часть возможностей внешнего окружения). Но это было бы не совсем точно, так как внешнее окружение реализуется не одним, а несколькими объектами. С другой стороны внутри системы нет резона рассматривать структуру ее внешнего окружения. Выход из указанного противоречия во введении в рассмотрение еще одной сущности - подсистемы.
Подсистема - это набор объектов и подсистем, обеспечивающих некоторую функциональность, и взаимодействующих между собой в соответствии с их интерфейсами. Интерфейс подсистемы представляет собой подмножество объединения интерфейсов всех объектов и подсистем, составляющих эту подсистему. В состав подсистемы может входить один, или более взаимозависимых объектов и/или подсистем.
Множество интерфейсов объектов (и подсистем), которые в своей совокупности составляют некоторую подсистему, составляет внутреннее окружение этой подсистемы. В состав каждой подсистемы должна быть включена подсистема окружение, представляющая внешнее окружение этой подсистемы. Подсистема окружение для системы банковского обслуживания, рассматриваемой в качестве сквозного примера представлена на рис. 2.41. Интерфейс подсистемы окружение определяет в каком программном окружении будет работать проектируемая система и какие возможности этого окружения будут использоваться во время ее работы (это важно, когда возникает потребность модификации или замены отдельных компонентов окружения).
Отметим, что подсистема окружение представляет только интерфейс системы банковского обслуживания с ее внешним окружением. Внешнее окружение системы банковского обслуживания состоит из нескольких подсистем и библиотек, и для него тоже может быть разработана объектная модель, которая может содержать и разрабатываемую систему (в этой объектной модели она будет одной из подсистем).
Объектную модель системы банковского обслуживания и ее системного (внешнего) окружения тоже можно изобразить в виде объектной диаграммы (правда, в состав этой объектной диаграммы будут входить не объекты, а только подсистемы; каждая подсистема изображается на диаграмме в виде прямоугольника с двойными вертикальными сторонами). Зависимости между подсистемами, изображенные на этой объектной диаграмме (рис. 2.42), отражают взаимодействие проектируемой системы банковского обслуживания и соответствующих подсистем в процессе работы системы. Тем самым определяются требования проектируемой системы к ее системному окружению.
Рис. 2.41. Объектная диаграмма банковской сети, в которой указан интерфейс с системным окружением
Рис. 2.42. Объектная диаграмма банковской сети и ее системного окружения
Введение понятия подсистемы и возможность включать в объектную модель наряду с объектами (классами) и подсистемы определяет иерархическую структуру объектной модели и позволяет использовать методологию OMT при проектировании достаточно сложных ПС, содержащих большое число различных объектов и классов.
2.4.2. Интерфейсы и окружения. Объекты и подсистемы, составляющие подсистему более высокого уровня, будем называть компонентами последней. Как уже было отмечено, для каждого компонента, входящего в состав объектной модели подсистемы, определен его интерфейс , т.е. набор открытых (общедоступных) операций, которые можно применять к этому компоненту (объекту или подсистеме).
Интерфейс объекта определяется интерфейсом соответствующего класса и задается списком сигнатур его открытых операций (методов). Интерфейс подсистемы определяется через итерфейсы составляющих ее объектов и подсистем следующим образом: операция может быть включена в интерфейс подсистемы, если в составе этой подсистемы имеется объект (подсистема), интефейс которого содержит эту операцию. Интерфейсы описываются на языке описания интерфейсов IDL (Interface Definition Language) .
Все возможности по обработке данных внутри подсистемы (т.е. в каждом компоненте, входящем в ее состав) определяются набором интерфейсов ее компонентов, который определяет внутреннее окружение подсистемы .
Если для некоторой подсистемы оказывается, что ни один ее компонент не содержит операции, которую желательно включить в ее интерфейс, в ее состав можно добавить объект, реализующий такую операцию. Такой объект называется интерфейсным объектом . Интерфейсные объекты позволяют согласовать внешний интерфейс подсистемы с ее внешним окружением , т.е. с интерфейсами других объектов и подсистем, которые вместе с рассматриваемой подсистемой составляют подсистему более высокого уровня.
Поясним введенные понятия на примере системы банковского обслуживания. В ее составе можно выделить подсистему банк (на самом деле в системе будет несколько экземпляров подсистемы банк - по одной для каждого банка, входящего в консорциум). При этом объектная модель системы примет вид, изображенный на рис. 2.43.
Рис. 2.43. Объектная диаграмма банковской сети после выделения подсистемы банк
При этом внешние интерфейсы подсистем банк и окружение вместе с интерфейсами объектов ATM и консорциум образуют внутреннее окружениесистемы банковского обслуживания. Ее внешнее окружение представлено на рис. 2.42; оно состоит из внешних интерфейсов различных программных систем, используемых в системе банковского обслуживания (на рис. показана лишь часть этих систем), и ее собственного внешнего интерфейса.
ТЕМА 4: Методология моделирования бизнес-процессов
1.Сущность моделирования и классификация моделей в реинжиниринге
Основные требования к построению моделей бизнес-процессов в компании
Методика построения прецедентной модели
Методика построения объектной модели
Вопрос 1
Моделирование - основной инструмент анализа и проектирования сложных систем. Существует огромное количество различного рода моделей. Классифицировать модели можно различными способами. По способу воплощения модели можно разделить на материальные (реальные, вещественные) и абстрактные (идеальные). Поскольку материальные модели имеют довольно ограниченную область применения, перейдем к рассмотрению абстрактных моделей.
Абстрактная модель есть отображение реального объекта в виде идеальных конструкций, выполненных средствами мышления. Выделим два основных класса абстрактных моделей: формальные (математические) и семантические (содержательные).
В формальных моделях отражаются математические закономерности, существующие между количественными параметрами. К этому классу моделей относятся, в частности, системы уравнений, статистические модели, модели исследования операций др. Математические модели универсальны в том смысле, что одна и та же модель может описывать весьма различные физические процессы или явления. Основное достоинство математических моделей заключается в том, что они позволяют с помощью формального аппарата вычислений находить решение при заданных условиях. Основная же трудность заключается в том, что не все системы удается адекватно описать некоторой единой математической моделью.
Сложные системы потому и называются сложными, что они плохо поддаются формализации. Для них целесообразно использовать семантические модели . В отличие от формальных, в семантических моделях сохраняется семантика объекта (раздел лингвистики, изучающий смысловое значение единиц языка). Примерами семантических моделей могут служить дерево целей организации, модель организационной структуры, модель информационных коммуникаций компании и т.п.
Как правило, семантические модели описывают некие объекты (сущности, системы, подсистемы, элементы), свойства объектов (параметры, характеристики), их состояния и поведение, а также отношения между объектами. Семантические модели могут быть как статическими , отражающими постоянные, устойчивые состояния объектов и отношения, так и динамическими , отражающими поток событий, т.е. изменение во времени состояний объектов, а также последовательность выполнения взаимодействий объектов. В качестве языковых средств описания семантических моделей используются графы, диаграммы, таблицы, блок-схемы, естественный язык (язык общения между людьми).
Основой большинства семантических моделей являются базовые модели системного анализа (модель "черного ящика", модель состава и модель структуры) и модели семантических сетей. В последнее время для построения этого вида моделей активно используется объектно-ориентированный подход.
Семантические модели не заменимы на ранних этапах проектирования сложных систем, когда формируется концепция системы. Интегрированная семантическая модель системы позволяет представить общую картину, составить обобщенное описание, в котором подчеркнуты основные сущности, а детали скрыты. Главное в такой модели - краткость и понятность. Такая модель может служить основой для построения более детальных моделей, описывающих отдельные аспекты, подсистемы. Таким образом, семантическая модель может служить каркасом для построения других моделей, в том числе и математических. Она служит для структуризации информации об объекте.
Вопрос 2
Любая компания является сложной системой, для которой невозможно построить единую формальную модель, охватывающую абсолютно все детали. Поэтому необходима не одна, а несколько согласованных моделей, которые являются основой для построения более детальных моделей.
В модели бизнеса должны найти отражение:
1.Функция компании во внешнем мире : что она делает, для кого, с какой целью. Необходимо описать окружающую среду компании, включающую клиентов, партнеров, субподрядчиков и т.д., а также взаимодействие компании с этой средой.
2. Архитектура компании , т.е. наиболее важные статические структуры компании. Элементами структур должны быть:
Внешние и внутренние процессы компании;
Функции (отдельные шаги процессов);
Продукция (выход процессов и функций);
Ресурсы, как человеческие, так и технические.
Элементы могут быть охарактеризованы параметрами, позволяющими описывать их состояния. Для описания структур необходимо также отразить отношения между элементами, в том числе:
Отношения между процессами, отдельными функциями (шагами) процессов;
Отношения между участниками процесса - различного рода ресурсами, средствами и продукцией;
Отношения между людьми (отношения подчиненности, коммуникации и т.д.).
3. "Динамика" бизнеса , т.е. выполнение бизнес-процессов во времени. Динамика отражается в виде потока событий, т.е. последовательности выполнения операций и передачи стимулов к их выполнению.
Методика построения моделей компании должна позволять строить понятные и обозримые модели. Модель должна исключать ненужные детали, акцентируя внимание на наиболее существенных аспектах. Необходимо, чтобы язык описания модели был достаточно выразителен.
Методика должна быть достаточно формализована, т.е. должна включать в себя некоторые довольно четкие процедуры или техники генерации компонент модели. Желательно, чтобы методика поддерживалась инструментальными компьютерными системами. Использование инструментальных систем поддержки существенно облегчает процесс разработки больших проектов, особенно при коллективной разработке, в которой участвуют различные группы разработчиков.
Вопрос 3
Наибольшее распространение получили 2 группы методологий моделирования бизнес-процессов:
1. Методика построения П-О-моделей (прецедент- объект - моделей), Данная методика предполагает последовательное построение двух типов моделей бизнеса: внешней (прецедентной или П-модели) и внутренней (объектной или О-модели).
Внешняя или прецедентная модель (П-модель) описывает бизнес так, как он виден извне, т.е. как он воспринимается клиентами и другим окружением. П-модель отражает представление о том, что делает бизнес, а не как делает.
Что такое "прецедент ". Прецедент - это "внешний" бизнес-процесс, ориентированный на клиента. Прецедент заканчивается получением продукта - измеримой потребительской ценности для некоторого индивидуального потребителя бизнес-системы.
Прецеденты могут иметь множество вариантов хода событий. Каждый конкретный прецедент (вариант) называется экземпляром . Экземпляр реализует конкретный поток событий в конкретных условиях для конкретного клиента. Похожие варианты хода событий группируются в классы прецедентов.
Можно рассматривать класс, как обобщенный прецедент. Например, класс прецедентов "Продажа" описывает общий ход событий, выполняемых при продаже любого продукта любому клиенту. Конкретный экземпляр прецедента "Продажа" может отличаться в деталях, например, в зависимости от того, новый это клиент или нет, компетентный или несведущий и т.п.
Построение П-модели начинается с выделения прецедентов и элементов окружения - клиентов, партнеров, поставщиков. Окружение моделируется при помощи действующих лиц, которые называются субъектами . Субъекты обозначают все то в окружении, что взаимодействует с бизнесом. Субъектом может быть: человек (например, клиент, покупатель); другая компания (например, организация-поставщик, субподрядчик); техническая система (например, компьютерная система другой компании).
Так же, как и для прецедентов, для субъектов различают понятия класса и экземпляра. Класс субъекта описывает общие характеристики некоторого типа субъектов, а экземпляр - характеристики конкретного субъекта.
После идентификации субъектов и прецедентов бизнес-системы необходимо описать взаимодействия между ними. На рис. 3.1 представлена графическая модель взаимодействия прецедентов и субъектов.
Отношения, представленные на данной модели, называются отношениями коммуникации . Они отражают реальные отношения прецедентов с окружением, заключающиеся в обмене веществом (сырьем, инструментами, готовой продукцей), энергией и информацией. Т.о. отношения коммуникации моделируют материальные, энергетические и информационные потоки.
Следующий шаг в построении П.модели - описание прецедента последовательностью мелких шагов. Такое описание называется потоком событий . С точки зрения системного подхода осуществляется декомпозиция процесса-прецедента на подпроцессы-события.
Рассмотрим для примера описание прецедента "Продажа продукта". Основной поток событий:
1. Продавец получает заявку клиента
2. Если в заявке указывается готовый продукт, то продавец проверяет наличие требуемого продукта на складе. Далее прецедент продолжается с шага 5.
3. Если в заявке указывается заказной продукт, продавец уточняет сведения о заказе и передает их проектировщику продукта
4. Проектировщик модифицирует продукт в соответствии с требованиями клиента
5. Продавец принимает от клиента оплату
6. Продавец сообщает отправителю количество продукта и адрес клиента и заказывает транспорт
7. Отправитель доставляет клиенту продукт.
Каждый шаг (событие) прецедента представляет собой некоторое действие, переводящее прецедент в новое состояние. В свою очередь, новое состояние прецедента является стимулом для выполнения следующего шага (события). Таким образом, прецедент рассматривается как машина состояний-событий .
Вопрос 4
Описание О-модели базируется на понятии "объект". Объекты представляют участников процессов и различного рода сущности (продукция, предметы, задачи и т.д.). Различают классы объектов, описывающие общие характеристики некоторого типа объектов, и экземпляры , описывающие характеристики конкретного объекта. О-модель, представленную в терминах классов объектов, называют идеальной моделью. Такая модель не учитывает некоторых деталей реализации модели на практике. О-модель, описанную в терминах экземпляров объектов, называют реальной. Она учитывает особенности конкретной реализации.
Выделяются следующие типовые классы объектов:
1. Интерфейсные - объекты, осуществляющие взаимодействие с окружением, т.е. с субъектами. Примерами интерфейсных объектов являются Продавец, Регистратор, Секретарь. В роли интерфейсного объекта может выступать не только человек. Это может быть, например, часть информационной системы - графический интерфейс пользователя.
2. Управляющие - активные объекты, управляющие процессами, но не имеющие контакта с окружением. Типичные примеры управляющих объектов в компании - это Разработчик продукции, Менеджер проекта.
3. Объекты-сущности - пассивные объекты, которые обрабатываются бизнесом. Как правило, объекты-сущности не являются человеческими или техническими ресурсами. Типичные примеры сущностей в компании - Продукция, Заказ, Извещение.
Один и тот же объект может участвовать не только в одном прецеденте, он может принимать участие во многих событиях в бизнесе. Кроме того, как и в случае с субъектами, один реальный человек или техническая система может выполнять роли нескольких объектов. Например, продавец продукции кроме роли интерфейсного объекта, выполняющего контакт с клиентом, может играть роль менеджера.
Объекты (классы и экземпляры) связываются отношениями . Бинарное отношение связывает два объекта. Оно может быть как однонаправленным, так и двунаправленным.
В графической модели взаимодействия объектов прецедента объекты изображаются треугольниками (интерфейсные - с буквой "и" внутри, управляющие - с буквой "у" внутри), а отношения между объектами - дугой (стрелкой). На рис. 3.4 представлена модель взаимосвязей объектов для прецедента "Продажа заказного продукта", описанного в п.3.2.1.
 |
Отношения, представленные на данной модели, относятся к двум типам: отношения коммуникации (изображены сплошной стрелкой) и отношения использования (изображены пунктирной стрелкой). Отношения коммуникации отражают материальные, энергетические и информационные потоки между различными объектами, а также между объектами и субъектами. Отношение использования означает, что один объект некоторым образом использует другой. Например, объект "Продавец" формирует объект "Адрес клиента", объект "Отправитель продукта" использует "Адрес клиента" для получения информации о том, куда доставлять продукт.
Для того, чтобы иметь представление обо всех ролях и обязанностях объекта, нужно составить описание объекта . Описание объекта состоит из двух частей: описание состояний и описание поведения. Для составления описания состояний объекта, прежде всего, необходимо выделить все его характеристики, свойства, называемые атрибутами. Атрибут должен иметь имя, диапазон возможных значений, а для экземпляра объекта еще и конкретное текущее значение атрибута. Например, объект "Заказ" может иметь атрибуты, указывающие название заказываемого товара, его характеристики, количество, имя клиента, заказавшего товар и т.д. Как правило, состав атрибутов одинаков для всего класса объекта. Различные экземпляры объекта отличаются лишь набором конкретных значений атрибутов.
Различают постоянные атрибуты, значения которых не изменяются в ходе выполнения прецедента и переменные, которые определяют различные состояния объекта. Например, объект «Заказ» может иметь переменный атрибут, указывающий, находится ли заказ в стадии изготовления товара, отправки товара или он уже выполнен.
Описание поведения объекта заключается в выявлении всех его обязательств , т.е. всех взаимодействий объекта с другими объектами и субъектами в ходе выполнения прецедента.
©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2017-10-11