Построение объектной модели программной системы. Построение объектной модели

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

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

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

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

Одним из таких средств является динамическая модель под­системы. Она строится после того, как объектная модель подсистемы построена и предварительно согласована и отлажена. Динамическая модель подсистемы состоит из диаграмм сос­тояний ее объектов подсистем.

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

Событие происходит в некоторый момент времени. Примеры событий: старт ракеты, старт забега на 100 м, начало проводки, выдача денег и т.п. Событие не имеет продолжительности (точнее, оно занимает пренебрежимо малое время).

Если события не имеют причинной связи (т.е. они логически независимы), они называются независимыми (concurrent ). Такие события не влияют друг на друга. Независимые события не имеет смысла упорядочивать, так как они могут происходить в произвольном порядке. Модель распределенной системы обязательно должна содержать независимые события и активности.

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

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

Процесс построения объектной модели включает в себя следующие этапы:

Определение объектов и классов;

Подготовка словаря данных:

Определение зависимостей между объектами;

Определение свойств объектов и связей;

Организация и упрощение классов при использовании наследования;

Дальнейшее исследования и усовершенствование модели.

Построение объектной модели задачи с использованием языка моделирования UML.

РАБОТА ВЫПОЛНЯЕТСЯ в StarUML

Время выполнения:

2 – 3 занятия

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

ПРИМЕР ЗАДАНИЯ:

Необходимо обеспечить хранение в базе данных следующей информации:

- информация о студентах

o Ф.И.О.,

o адрес,

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.

Следует отметить, что при построении данного вида диаграммы для выходного документа «Список группы» в нашем случае следует сначала выбрать группу на форме «Выбор группы» (на нее в свою очередь должны попасть данные из сущности «Группа»), а затем отобразить форму выходного документа, на которую данные поступают уже из сущности «Студент».

Базы данных. Заочники

Лабораторная работа №1

Построение объектной модели задачи с использованием языка моделирования UML.

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

Общая информация

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

Моделирование позволяет решить следующие задачи:

Визуализировать систему в ее текущем или желательном для нас состоянии;

Определить структуру или поведение системы;

Получить шаблон, позволяющий затем сконструировать систему;

Документировать принимаемые решения, используя полученные модели.

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

Прецедент (Use Case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (Actor). Прецедент применяется для структурирования поведенческих сущностей модели. Графически прецедент изображается в виде ограниченного непрерывной линией эллипса, обычно содержащего только его имя, как показано на рис. 3.

Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует два вида поведенческих сущностей:

Взаимодействие (Interaction);

Автомат (State machine).

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

Группирующие сущности являются организующими частями UML. Это блоки, на которые можно разложить модель. Есть только одна группирующая сущность, а именно пакет.

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

Аннотационные сущности – пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один тип аннотационных элементов – примечания (Note).

Примечание – это просто символ для изображения комментариев или ограничений, присоединенных к элементу или группе элементов. Графически примечание изображается в виде прямоугольника с загнутым краем, содержащим текстовый или графический комментарий, как показано на рис. 6.

В языке UML определены четыре типа отношений:

Зависимость;

Ассоциация;

Обобщение;

Реализация.

Эти отношения являются основными строительными блоками в UML и применяются для создания корректных моделей.

Зависимость (Dependency) – это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Графически зависимость изображается в виде прямой пунктирной линии, часто со стрелкой (см. рис. 7).

Ассоциация (Association) – структурное отношение, описывающее совокупность связей; связь – это соединение между объектами. Графически ассоциация изображается в виде прямой линии (иногда завершающейся стрелкой или содержащей метку), рядом с которой могут присутствовать дополнительные обозначения, например кратность и имена ролей. На рис. 8 показан пример отношений этого типа.

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

Диаграммы классов;

Диаграммы объектов;

Диаграммы прецедентов;

Диаграммы последовательностей;

Диаграммы кооперации;

Диаграммы состояний;

Диаграммы действий;

Диаграммы компонентов;

Диаграммы развертывания.

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

На диаграмме прецедентов представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения прецедентов использования. Они особенно важны при организации и моделировании поведения системы.

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

Порядок выполнения работы будет рассмотрен на примере следующего задания:

Необходимо обеспечить хранение в базе данных следующей информации:

- информация о студентах (включает Ф. И.О., домашний адрес, паспортные данные, номер зачетки, дата рождения, группа);

- информация о специальностях (наименование специальности, шифр);

- информация о группах (специальность, год поступления, номер группы).

Обеспечить выдачу документа “Список группы”, содержащего поля: порядковый номер, Ф. И.О., номер зачетки.

Построение объектной модели выполняется в пакете Rational Rose. Для этого создадим пустой проект. Начинать выполнение работы следует с диаграммы прецедентов. Ее строят в области Main секции Use Case View, как показано на рис.9.

Перед началом построения диаграммы необходимо определить роли пользователей системы (актеров) и их функции (прецеденты). В нашем случае с системой работают два актера – это «Работник учебного отдела» и «Работник деканата». В функции работника учебного отдела входит ведение списка специальностей (под ведением списка мы будем понимать добавление записей, их корректировку и удаление). Функции работника деканата включают в себя ведение списка студентов и ведение списка групп.

Построенная диаграмма изображена на рис. 10.

Далее в секции Logical View следует создать две диаграммы классов. Для этого можно создать два пакета. Первая диаграмма должна содержать классы интерфейса проектируемого приложения (см. рис. 11). Вторая диаграмма – сущности базы данных (см. рис. 12).

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

Следующий этап построения объектной модели – создание диаграмм последовательностей. Диаграммы последовательностей создаются для каждого прецедента на диаграмме прецедентов. Чтобы добавить диаграмму последовательностей к прецеденту необходимо выбрать его в дереве и вызвать на нем контекстное меню (NewàSequence Diagram) как показано на рис. 13.

Пример диаграммы последовательностей для прецедента «Ведение списка специальностей» представлен на рис. 14.

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

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

• 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 модели...