Построение объектной модели предметной области "организация процессов спортивного клуба" с применением языка моделирования UML. Основные принципы построения объектной модели

ТЕМА 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

Объектная модель существующего бизнеса показывает как, и за счет чего реализуются прецеденты. Данная модель раскрывает внутреннее устройство бизнеса, а именно: какие виды ресурсов используются для реализации прецедентов и каким образом они взаимодействуют. Описание объектной модели базируется на понятии "объект". Объекты представляют участников процессов и различного рода сущности (готовая продукция, заказ и т.д.).

Интерфейсные объекты, исследуемого бизнес-процесса:

• 1. Менеджер по работе с клиентами. Атрибуты: ФИО, должность, заработная плата. Обязанности: взаимодействует с клиентами, оформляет заказы, принимает оплату от клиентов за заказы.
• 2. Материально-ответственный кладовщик. Атрибуты: ФИО, должность, заработная плата. Обязанности: взаимодействие с поставщиками, принимает материалы и подписывает счет-фактуру.
• 3. Водитель-экспедитор. Атрибуты: ФИО, должность, заработная плата. Обязанности: доставка готового изделия клиенту.

Управляющие объекты, исследуемого бизнес-процесса:

• 1. Проектировщик. Атрибуты: ФИО, должность, заработная плата. Обязанности: проектирование изделия, управление исполнением проекта, контроль.
• 2. Оператор автоматизированного учета. Атрибуты: ФИО, должность, заработная плата. Обязанности: ведение автоматизированного учета, работа с базой данных.
• 3. Мебельный мастер (Сборщик). Атрибуты: ФИО, должность, заработная плата. Обязанности: изготовление продукта в соответствии с проектом.

Объекты-сущности, исследуемого бизнес-процесса:

• 1. Чек - документ, выдаваемый по факту оплаты заказа.
• 2. Каталог - документ отражающий ассортимент выпускаемой продукции.
• 3. Бланк заказа - документ, в который входит номер заказа, дата заказа, информация о клиенте, выбранный тип, эскиз изделия, пожелания клиента.
• 4. Проект изделия - проект заказанной мебели.
• 5. Заявка на материалы - документ, характеризующий необходимые материалы и их объемы.
• 6. База данных - программа, позволяющая вести материальный учет в фирме.
• 7. Материалы - необходимы для производства заказного изделия.
• 8. Счет-фактура - документ, подписываемый по факту отгрузки материалов.
• 9. Готовое изделие - результат производства, характеризуется принадлежностью к какому-либо заказу.

В таблице 5.1 приведено описание взаимосвязи объектов друг с другом.

Таблица 5.1 Описание взаимодействия объектов друг с другом

Примечание: В случае если необходимые материалы имеются на складе, то пункты 18, 19, 20, 21 данной таблицы пропускаются.

Динамическая модель взаимодействия подразделений и заказчика, в прецеденте "Продажа заказного продукта" изображена на рисунке 5.1 Динамическая модель взаимодействия подразделения, сотрудника и заказчика, в прецеденте "Оформление заказа" изображена на рисунке 5.2 Динамическая модель взаимодействия подразделения, сотрудников и заказчика, в прецеденте "Проектирование" изображена на рисунке 5.3 Динамическая модель взаимодействия сотрудников, в прецеденте "Изготовление" изображена на рисунке 5.4.

Рисунок 5.1 Диаграмма последовательности прецедента "Продажа заказного продукта"

Рисунок 5.2 Диаграмма последовательности прецедента "Оформление заказа"

Рисунок 5.3 Диаграмма последовательности прецедента "Проектирование"

Рисунок 5.4 Диаграмма последовательности прецедента "Изготовление"

Построение объектной модели предметной области "организация процессов спортивного клуба" с применением языка моделирования UML

1. ОСНОВНЫЕ ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ МЕТОДОЛОГИИ

1.1 Основные понятия объектно-ориентированного подхода

предметный язык программирование модель

С давних пор в программировании использовалась структурированная процедурно-ориентированная модель. Выбор целей проекта осуществляется одним из двух подходов, называемых «сверху вниз» и соответственно «снизу вверх»

1. Подход «сверху вниз» подразумевает, что задача разбивается на подзадачи, те в свою очередь, на подзадачи следующего уровня и т.д. Этот процесс называемый декомпозицией длится до тех пор, пока упрощение подзадач не сводится к элементарным функциям, которые могут быть формализованы.

2. Подход «снизу вверх» подразумевает, что пишутся процедуры для решения простых задач, затем они последовательно объединяются в более сложные процедуры пока не достигается нужный эффект.

Важными понятиями программирования являются процедурно-ориентированное программирование и объектно-ориентированное программирование.

Процедурно-ориентированное программирование - программирование на императивном языке, при котором последовательно выполняемые операторы можно собрать в подпрограммы, то есть более крупные целостные единицы кода, с помощью механизмов самого языка.

Объектно-ориентированное программирование (ООП) - это стиль программирования, который фиксирует поведение реального мира таким способом, при котором детали его реализации скрыты.

Объект - это некая отдельная сущность, выделяющаяся среди других сущностей своими свойствами, поведением, взаимодействием с другими объектами приложения.

Применение такой технологии позволяет представить структуру программы в виде множества взаимодействующих друг с другом объектов. В результате такого взаимодействия, осуществляемого путем передачи сообщений между объектами, реализуются заданные функции программы. Приняв сообщение, объект может выполнить определенное действие, называемое методом.

Между ООП и процедурно-ориентированным программированием существуют два важных различия:

1. В ООП программист сначала выделяет классы из описания предметной области, затем строится объектная модель решения задачи и только после этого переходит к анализу их методов и свойств.

2. Методы и свойства ассоциируются с классом, предназначенным для выполнения соответствующих операций.

Если проанализировать, каким образом человек решает разнообразные практические задачи в окружающем его мире, то можно понять, что этот мир также является объектно-ориентированным. Например, чтобы попасть на работу, человек, как правило, взаимодействует с таким объектом, как транспортное средство. Транспортное средство, в свою очередь, состоит из объектов, которые, взаимодействуя друг с другом, приводят его в движение, благодаря чему человек реализует свою задачу - добирается до нужного пункта. При этом ни водитель, ни пассажир не обязаны знать каким, образом взаимодействуют объекты, из которых состоит транспортное средство.

В объектно-ориентированном программировании, как и в реальном мире, пользователи программ изолированы от логической схемы, необходимой для выполнения задач. Например, для печати страницы в текстовом редакторе пользователь вызывает определенную функцию нажатием кнопки на панели инструментов, но не видит происходящих при этом внутренних процессов. При печати страницы во время работы программы происходит сложное взаимодействие объектов, которые, в свою очередь, взаимодействуют с принтером.

При создании объектно-ориентированной программы предметная область представляется в виде совокупности объектов, которые объединены в классы. Выполнение программы состоит в том, что объекты обмениваются сообщениями (взаимодействуют между собой). При представлении реального объекта, принадлежащей предметной области с помощью программного класса, необходимо выделить в реальном объекте его существенные особенности и проигнорировать многие другие свойства, ограничиваясь лишь теми, которые нужны для решения практической задачи. Такой прием называется абстракцией.

Абстракция - это выделение существенных характеристик объекта, отличающих его от других объектов. Причем список существенных свойств зависит от целей моделирования, и для разных задач может быть совершенно различным. Например, объект «крыса» с точки зрения биолога, изучающего миграции, ветеринара, или повара будет иметь совершенно разные характеристики.

Класс - это совокупность объектов, имеющих общие свойства и поведение. Таким образом, класс можно определить как некую общность конкретных объектов, как описание - какими они должны быть и что они должны делать. Если объекты реально существуют в приложениях, то класс - это абстракция, объединяющая объекты в одну группу согласно их свойствам и поведению в среде окружения, в которой они существуют и взаимодействуют. Например, кнопка Button1 в форме со всеми своими конкретными свойствами и действием является объектом класса Button.

Поведение - характеристика того, как один объект воздействует на другие объекты или изменяется сам под их воздействием. Поведение влияет на способ изменения состояний объекта.

В основе объектно-ориентированной технологии программирования лежат «три кита»: инкапсуляция, наследование и полиморфизм.

Инкапсуляция (encapsulation) - свойство объединять внутри одной структуры состояние и поведение, и скрытие внутреннего устройства объекта и деталей реализации (от слова «капсула»). Важное свойство любого объекта его обособленность. Детали реализации объекта, т.е. внутренние структуры данных и алгоритмы их обработки, скрыты от пользователя объекта и недоступны для непреднамеренных изменений. Объект используется через интерфейс - совокупность правил доступа. Например, для того чтобы переключить телевизионную программу, нам достаточно на пульте дистанционного управления набрать ее номер, что запустит сложный механизм, который в итоге и приведет к желаемому результату. Нам совершенно необязательно знать, что происходит в пульте дистанционного управления и телевизоре, нам лишь достаточно знать, что телевизор обладает такой возможностью (методом) и как ее можно активировать. Инкапсуляция, или сокрытие реализации, является основополагающим свойством ООП. Она позволяет создавать пользовательские объекты, обладающие требуемыми методами, и далее оперировать ими, не вдаваясь в устройство этих объектов. Таким образом, инкапсуляция - механизм, который объединяет данные и методы обработки (манипуляции) этими данными и защищает и то, и другое от внешнего вмешательства или неправильного использования. Инкапсуляция кода внутри класса обеспечивает невозможность «сломать» этот код при любом изменении деталей реализации отдельных классов. Поэтому можно использовать объект в другом окружении, и быть уверенным, что он не испортит не принадлежащие ему области памяти. Если же все-таки надо что-то изменить или дополнить в классе, то используются механизмы наследования и полиморфизма.

Наследование (inheritance) - основанная на иерархии способность классов включать в себя свойства и поведение классов-предков, а также добавлять к ним свое собственное поведение и свойства. Каждый год в мире пишется множество программ и важно использовать уже написанный код. Преимущество объектно-ориентированного программирования состоит в том, что для объекта можно определить наследников, корректирующих или дополняющих его поведение. При этом нет необходимости не только повторять исходный код родительского объекта, но даже иметь к нему доступ. Таким способом упрощается модификация программы и создание новых программ на основе существующей. Только благодаря наследованию можно использовать объекты, исходный код которых недоступен, но в которые требуется внести изменения. Таким образом, при наследовании можно не просто добавлять новый функционал, но и изменить существующий. И во многом это обеспечивается благодаря полиморфизму.

Полиморфизм (polymorphism) («много форм») - возможность использовать одинаковые выражения для обозначения разных операций, возможность классов-наследников по-разному реализовывать метод, описанный для класса-предка, т.е. возможность во время выполнения программы с помощью одного и того же имени выполнять разные действия или обращаться к объектам разного типа. Полиморфизм реализуется через переопределение метода в классах-наследниках (метод имеет одно имя и одинаковые параметры, но работает по-разному) - это механизм виртуальных методов через динамическое связывание (dynamic binding). Также полиморфизм реализуется как «перегрузка» методов (метод имеет одно имя и разные параметры) - это, например, использование знака + для обозначения сложения в классе вещественных или целых чисел и классе строк: похожие сообщения дают совершенно разные результаты. Полиморфизм обеспечивает возможность абстрагирования общих свойств.

Модульность - это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.
В процессе разделения системы на модули могут быть полезными два правила. Во-первых, поскольку модули служат в качестве элементарных и неделимых блоков программы, которые могут использоваться в системе повторно, распределение классов и объектов по модулям должно учитывать это. Во-вторых, многие компиляторы создают отдельный сегмент кода для каждого модуля. Поэтому могут появиться ограничения на размер модуля. Динамика вызовов подпрограмм и расположение описаний внутри модулей может сильно повлиять на локальность ссылок и на управление страницами виртуальной памяти. При плохом разбиении процедур по модулям учащаются взаимные вызовы между сегментами, что приводит к потере эффективности кэш-памяти и частой смене страниц.

Свести воедино столь разноречивые требования довольно трудно, но главное - это уяснить, что вычленение классов и объектов в проекте и организация модульной структуры есть независимые действия. Процесс вычленения классов и объектов составляет часть процесса логического проектирования системы, а деление на модули - этап физического проектирования. Разумеется, иногда невозможно завершить логическое проектирование системы, не завершив физическое проектирование, и наоборот. Два этих процесса выполняются итеративно.

Типизация - это способ защититься от использования объектов одного класса вместо другого, или по крайней мере управлять таким использованием.

Параллелизм - это свойство, отличающее активные объекты от пассивных.

Сохраняемость - способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства.

В программирование основные понятия ООП перешли из других областей знаний, таких как философия, логика, математика и семиотика, причем, не претерпев особых изменений, по крайней мере, того, что касается сути этих понятий. Объектный способ декомпозиции (представления) является естественным и применяется на протяжении многих веков. Поэтому неудивительно, что в процессе эволюции технологии программирования он занял подобающее место.

Таким образом, в процессе разработки объектно-ориентированных программ необходимо:

1. определить множество образующих ее классов объектов (декомпозиция);

2. для каждого класса объектов задать набор необходимых данных (полей);

3. для каждого класса объектов задать набор действий (методов), выполняемых объектами;

4. для каждого класса объектов указать события, на которые будут реагировать объекты, и написать соответствующие процедуры-обработчики.

В исходном программном коде должны содержаться описания классов для всех программных объектов. Кроме того, должны быть описаны переменные, у которых в качестве типов указаны имена соответствующих классов. Экземпляры классов (объекты) создаются в процессе выполнения программы.

После своего создания экземпляр класса должен получить значения для всех своих полей. Разные экземпляры одного и того же класса могут иметь различные значения полей, но обладают одними и теми же методами. Поля класса недоступны для непосредственного обращения, в том числе, и присваивания. Это сделано для повышения надежности программ. Вместо непосредственного присваивания значения полю объекта должно быть выполнено обращение к специальному методу соответствующего класса, который выполняет такое присваивание и осуществляет контроль корректности вводимого значения. Аналогичным образом, для прочтения значения поля могут также использоваться специальные методы класса. Для связи полей с методами чтения/записи их значений используются члены класса, называемые свойствами. Пользователь, вводя данные для записи их в полях объекта или считывая значения полей, имеет дело со свойствами, представляющими эти поля. Поэтому обычно используется термин «значения свойств» вместо термина «значения полей».

Членами класса могут быть:

1. поля, используемые для хранения данных;

2. свойства, как средства обращения к закрытым полям;

3. методы, задающие функциональность объектов;

4. события и их обработчики, как средства управления программами.

Автоматизация решения задач управления деятельностью ООО "Мир Компьютеров"

Построение концептуальной модели информационной системы МУП "РПКХБ"

Пакет Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования. Позволяет разрабатывать как высокоуровневые...

Построение объектной модели предметной области "организация процессов спортивного клуба" с применением языка моделирования UML

В технологии ООП взаимоотношения данных и алгоритма имеют более регулярный характер: во-первых, класс (базовое понятие этой технологии) объединяет в себе данные (структурированная переменная) и методы (функции). Во-вторых...

Программирование в Delphi математических процессов

Проект системы учета заказов на грузоперевозку автотранспортной компании "ТрансАвто"

Основным каналом коммуникации в компании являются письменные сообщения в форме отчетов, бюллетеней, состоящих традиционным (бумажным) способом, что значительно снижает скорость работы. Основная работа выполняется вручную...

Проектирование информационных систем средствами BPwin

Разработка информационной системы автоматизации рабочего места библиотекаря

Разработка объектно-ориентированной модели информационной подсистемы для деканата ВУЗа (учет успеваемости студентов)

Эффективное управление базой данных студентов невозможно без системы автоматизации. Информационная система «Деканат» предназначена для ведения личных дел студентов и может работать отдельно или в составе ИС «Электронные ведомости»...

Разработка объектно-ориентированной модели информационной системы учебной библиотеки

Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем (ИС), создаваемых в различных областях деятельности человека...

Разработка ООМД заключается в разработки модели данных с использованием объектно-ориентированного подхода к моделированию...

Разработка схемы базы данных задачи "Учет фонда библиотеки" для Харьковского колледжа текстиля и дизайна

При выборе СУБД для реализации той или иной системы необходимо учитывать все особенности имеющихся на сегодняшний день технологий. Так учитывая то, что наиболее развитыми можно считать ОО и ER модели...

Зависимости между классами (объектами)

С каждым объектом связана структура данных, полями которой являются атрибуты этого объекта и указатели функций (фрагментов кода), реализующих операции этого объекта (отметим, что указатели функций в результате оптимизации кода обычно заменяются на обращения к этим функциям). Таким образом, объект - это некоторая структура данных, тип которой соответствует классу этого объекта.

Между объектами можно устанавливать зависимости по данным. Эти зависимости выражают связи или отношения между классами указанных объектов. Примеры таких зависимостей изображены на рисунке 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 использует зависимости при интерпретации диаграмм, описывающих систему.

Теперь у нас есть все необходимые понятия, чтобы описать процесс построения объектной модели. Этот процесс включает в себя следующие этапы:

• определение объектов и классов;
• подготовка словаря данных;
• определение зависимостей между объектами;
• определение атрибутов объектов и связей;
• организация и упрощение классов при использовании наследования;
• дальнейшее исследование и усовершенствование модели.

Объектная модель

Объектно-ориентированная технология основывается на так называемой объектной модели. Основными принципами ее построения являются: абстрагирование, инкапсуляция, модульность, иерархичность, типизация, параллелизм и сохраняемость. Каждый из этих принципов сам по себе не нов, но в объектной модели они впервые применены в совокупности.

Объектно-ориентированный анализ и проектирование принципиально отличаются от традиционных подходов структурного проектирования: здесь нужно по-другому представлять себе процесс декомпозиции, а архитектура получающегося программного продукта в значительной степени выходит за рамки представлений, традиционных для структурного программирования. Отличия обусловлены тем, что структурное проектирование основано на структурном программировании, тогда как в основе объектно-ориентированного проектирования лежит методология объектно-ориентированного программирования.

Методы структурного проектирования помогают упростить процесс разработки сложных систем за счет использования алгоритмов как готовых строительных блоков. Аналогично, методы объектно-ориентированного проектирования созданы для того, чтобы помочь разработчикам применять мощные выразительные средства объектного и объектно-ориентированного программирования, использующего в качестве блоков классы и объекты.

. (object-oriented analysis, ООА) направлен на создание моделей реальной действительности на основе объектно-ориентированного мировоззрения.

Объектно-ориентированный анализ - это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области.

. (object-oriented design, ООД)

Программирование прежде всего подразумевает правильное и эффективное использование механизмов конкретных языков программирования. Проектирование, напротив, основное внимание уделяет правильному и эффективному структурированию сложных систем. Определим объектно-ориентированное проектирование следующим образом:

Объектно-ориентированное проектирование - это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы.

В данном определении содержатся две важные части: объектно-ориентированное проектирование

1) основывается на объектно-ориентированной декомпозиции;

2) использует многообразие приемов представления моделей, отражающих логическую (классы и объекты) и физическую (модули и процессы) структуру системы, а также ее статические и динамические аспекты.

Именно объектно-ориентированная декомпозиция отличает объектно-ориентированное проектирование от структурного, в первом случае логическая структура системы отражается абстракциями в виде классов и объектов, во втором - алгоритмами.

. (object-oriented programming, OOП)

Объектно-ориентированное программирование - это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования.

В данном определении можно выделить три части:

1) OOП использует в качестве базовых элементов объекты, а не алгоритмы;

2) каждый объект является экземпляром какого-либо определенного класса;

3) классы организованы иерархически .

Программа будет объектно-ориентированной только при соблюдении всех трех указанных требований. В частности, программирование, не основанное на иерархических отношениях, не относится к OOП, а называется программированием на основе абстрактных типов данных.

Выделяют пять основных разновидностей стилей программирования, которые перечислены ниже вместе с присущими им видами абстракций:

Невозможно признать какой-либо стиль программирования наилучшим во всех областях практического применения. Например, для проектирования баз знаний более пригоден стиль, ориентированный на правила, а для вычислительных задач - процедурно-ориентированный. По накопленному опыту объектно-ориентированный стиль является наиболее приемлемым для широчайшего круга приложений; действительно, эта парадигма часто служит архитектурным фундаментом, на котором основываются другие парадигмы.

Каждый стиль программирования имеет свою концептуальную базу. Каждый стиль требует своего умонастроения и способа восприятия решаемой задачи. Для объектно-ориентированного стиля концептуальная база - это объектная модель. Она имеет четыре главных элемента:

• абстрагирование;
• инкапсуляция;
• модульность;
• иерархия.

Эти элементы являются главными в том смысле, что без любого из них модель не будет объектно-ориентированной. Кроме главных, имеются еще три дополнительных элемента:

• типизация;
• параллелизм;
• сохраняемость.

Называя их дополнительными, имеется в виду, что они полезны в объектной модели, но не обязательны.

Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя.

Абстракция основывается на понятиях клиента и сервера.

Клиентом называется любой объект, использующий ресурсы другого объекта (называемого сервером ).

Мы будем характеризовать поведение объекта услугами, которые он оказывает другим объектам, и операциями, которые он выполняет над другими объектами. Такой подход концентрирует внимание на внешних проявлениях объекта и приводит к идее контрактной модели программирования, когда внешнее проявление объекта рассматривается с точки зрения его контракта с другими объектами, в соответствии с этим должно быть выполнено и его внутреннее устройство (часто во взаимодействии с другими объектами). Контракт фиксирует все обязательства, которые объект-сервер имеет перед объектом-клиентом. Другими словами, этот контракт определяет ответственность объекта, то есть то поведение, за которое он отвечает.

Каждая операция, предусмотренная этим контрактом, однозначно определяется ее формальными параметрами и типом возвращаемого значения. Полный набор операций, которые клиент может осуществлять над другим объектом, вместе с правильным порядком, в котором эти операции вызываются, называется протоколом. Протокол отражает все возможные способы, которыми объект может действовать или подвергаться воздействию. Он полностью определяет, тем самым, внешнее поведение абстракции со статической и динамической точек зрения.

Инкапсуляция - это процесс отделения друг от друга элементов объекта, определяющих его устройство и поведение. Инкапсуляция служит для того, чтобы изолировать контрактные обязательства абстракции от их реализации.

Абстракция и инкапсуляция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, а инкапсуляция занимается внутренним устройством. Чаще всего инкапсуляция выполняется посредством скрытия информации, то есть маскировкой всех внутренних деталей, не влияющих на внешнее поведение. Обычно скрываются и внутренняя структура объекта, и реализация его методов. Практически это означает наличие двух частей в классе: интерфейса и реализации. Интерфейс отражает внешнее поведение объекта, описывая абстракцию поведения всех объектов данного класса. Внутренняя реализация описывает представление этой абстракции и механизмы достижения желаемого поведения объекта. Принцип разделения интерфейса и реализации соответствует сути вещей: в интерфейсной части собрано все, что касается взаимодействия данного объекта с любыми другими объектами; реализация скрывает от других объектов все детали, не имеющие отношения к процессу взаимодействия объектов.

Модульность - это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.

В процессе разделения системы на модули могут быть полезными два правила. Во-первых, поскольку модули служат в качестве элементарных и неделимых блоков программы, которые могут использоваться в системе повторно, распределение классов и объектов по модулям должно учитывать это. Во-вторых, многие компиляторы создают отдельный сегмент кода для каждого модуля. Поэтому могут появиться ограничения на размер модуля. Динамика вызовов подпрограмм и расположение описаний внутри модулей может сильно повлиять на локальность ссылок и на управление страницами виртуальной памяти. При плохом разбиении процедур по модулям учащаются взаимные вызовы между сегментами, что приводит к потере эффективности кэш-памяти и частой смене страниц.

Свести воедино столь разноречивые требования довольно трудно, но главное – это уяснить, что вычленение классов и объектов в проекте и организация модульной структуры есть независимые действия. Процесс вычленения классов и объектов составляет часть процесса логического проектирования системы, а деление на модули - этап физического проектирования. Разумеется, иногда невозможно завершить логическое проектирование системы, не завершив физическое проектирование, и наоборот. Два этих процесса выполняются итеративно.

Иерархия - это упорядочение абстракций, расположение их по уровням.

Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия "is-a") и структура объектов (иерархия "part of").

Важным элементом объектно-ориентированных систем и основным видом иерархии "is-a" является упоминавшаяся выше концепция наследования. Наследование означает такое отношение между классами (отношение родитель/потомок), когда один класс заимствует структурную или функциональную часть одного или нескольких других классов (соответственно, одиночное и множественное наследование ). Иными словами, наследование создает такую иерархию абстракций, в которой подклассы наследуют строение от одного или нескольких суперклассов. Часто подкласс достраивает или переписывает компоненты вышестоящего класса.

Если иерархия "is а" определяет отношение "обобщение/специализация", то отношение "part of" (часть) вводит иерархию агрегации. В иерархии "part of" класс находится на более высоком уровне абстракции, чем любой из использовавшихся при его реализации.

Типизация - это способ защититься от использования объектов одного класса вместо другого, или по крайней мере управлять таким использованием.

Параллелизм - это свойство, отличающее активные объекты от пассивных.

Сохраняемость - способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства.