Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Основные понятия объектно-ориентированного проектирования).pdf
Добавлен: 01.04.2023
Просмотров: 140
Скачиваний: 2
СОДЕРЖАНИЕ
1. Теоретические основы объектно-ориентированного подхода
1.1 Основные понятия объектно-ориентированного проектирования
1.2 Пример объектно-ориентированного анализа
1.3 Процесс объектно-ориентированного проектирования
2. Объектно-ориентированный подход в программировании
2.1 Технологии программирования
2.2 Сущность объектно-ориентированного подхода к программированию
3. Внедрение объектно-ориентированного подхода в трудовую деятельность
3.1 Анализ работы менеджера по продажам
3.2 Определение недостатков существующей системы обработки информации
3.3 Обоснование необходимости разработки информационной системы
3.4 Выбор и обоснование варианта реализации задач автоматизации
3.5 Описание выходных документов
- построение модели состояний для формализации жизненных циклов объектов и отображение этой модели диаграммами и таблицами переходов, взаимодействие между объектами осуществляется путем передачи сообщений о происходящих с ними событиях.
- разработка модели процессов, в которой действия в моделях состояний расчленяются на фундаментальные и многократно используемые процессы.
В работе Г. Буча “Объектно-ориентированное проектирование с примерами применения” отмечаются следующие альтернативные подходы к ООА:
- Метод неформального описания, в котором выделяются существительные и глаголы в описании предметной области. Существительные здесь рассматриваются в качестве кандидатов для образования классов, а глаголы – как кандидаты в операции над классами;
- структурный анализ, при котором на основе модели системы, представленной диаграммами потоков данных, выделяются внешние события и объекты, база данных, поток управления, преобразования потока управления. Далее, на основе анализа потока данных и потока управления, выделяются классы и методы классов.
1.2 Пример объектно-ориентированного анализа
Пусть требуется разработать пакет программ для решения расчетных задач, настраиваемый на конкретную предметную область. Каждая предметная область определяется совокупностью переменных и связей между этими переменными - формулами и алгоритмами для вычисления некоторых переменных по известным значениям других переменных. Такой пакет должен состоять из двух частей, универсальной, обеспечивающей ввод и представления данных пользователям и общее управление работой пакета, а также функциональной части, содержащей алгоритмы вычислений для конкретной предметной области.
Предметная область ППП для решения расчетных задач формально может быть описана совокупностью трех множеств:
- множества данных X;
- множества функциональных связей (задач, решаемых с использованием пакета) F;
- множества связей по определению R.
При использовании пакета пользователь может вводить некоторые данные из заранее определенного их набора и запрашивать решение одной или нескольких задач, а затем выводить вычисленные данные на экран, в файл или на принтер. Пакет должен настраиваться на конкретную предметную область путем определения множеств X, F и R и подключения соответствующего набора обрабатывающихся модулей (подпрограмм).
Объектно-ориентированный анализ проще всего начать с неформального описания и построения словаря предметной области. В данном случае такой словарь может включать следующие понятия:
Данные (множество X): множество данных, элемент множества данных.
Элемент множества данных должен описываться его типом, уровнем агрегирования и наличием или отсутствием конкретного значения;
Задачи (множество F): множество задач, элемент множества задач (конкретная задача), набор аргументов (входных и выходных данных задачи), аргумент задачи;
Связи по определению (множество R): множество связей, элемент множества связей, тип связи (старший - младший, функция-предикат);
Поскольку каждая задача должна реализовываться вызовом некоторого обрабатывающего модуля (подпрограммы), добавим соответствующие понятия.
Модули (множество M): множество модулей, элемент множества модулей, список параметров модуля, параметр модуля.
Элементы перечисленных множеств находятся между собой в определенных отношениях. Элемент множества задач использует элементы множества данных для передачи аргументов связанному с задачей модулю. Элементы множества связей либо связывают между собой пары данных, либо описывают некоторый предикат, аргументами которого служат элементы множества данных.
Кроме понятий - существительных следует выделить понятия - глаголы (действия), относящиеся к понятиям - существительным. В рассматриваемом примере действиями могут быть:
- определить новый элемент множества данных, задач или связей;
- добавить новый элемент в множество (данных, задач, связей);
- удалить элемент из множества (данных, задач, связей);
- ввести значение элемента множества данных;
- вывести на экран (в файл, на принтер) значение элемента множества данных;
- выполнить задачу.
Предполагается, что перечисленные действия должны выполняться по командам пользователя. Следовательно, все предыдущие рассуждения необходимо повторить для процесса диалога с пользователем. Отличие заключается лишь в том, что для организации диалога, как правило, применяются готовые инструментальные средства и свойственные им основные понятия: диалоговое окно, объект ввода строкового данного, независимые и зависимые, списки строк.
Результаты ООА документируются наборами диаграмм и таблиц, отражающих как структуру выделенных классов объектов, так и отношения между ними.
Понятия, которые принимаются как кандидаты в используемые классы, более подробно описываются по специальному шаблону, который включает следующие характеристики класса:
- имя класса, т.е. присвоенный ему идентификатор;
- множественность экземпляров класса (0/1/n);
- иерархия класса ( базовые классы);
- структура и интерфейс класса.
Здесь под структурой понимаются как атрибуты класса (элементы-данные), так и действия (методы). Данные и методы разбиваются по уровням доступа.
Под интерфейсом класса понимаются элементы-данные, доступные из экземпляров других классов, и методы, которые могут быть вызваны из других классов.
Для классов желательно определить жизненные циклы экземпляров класса: когда, при каких условиях создается экземпляр класса, когда изменяется его состояние и когда он уничтожается.
Поскольку в объектно-ориентированной системе экземпляры классов обмениваются сообщениями, для каждого класса следует определить поступающие его экземплярам сообщения и на их основе построить диаграммы перехода (описать класс как конечный автомат). В ряде случаев для каждого объекта целесообразно построить модели состояний и определить списки событий, изменяющих состояние объектов.
После выделения классов и их неформального описания могут быть построены модели процессов, которые должны быть реализованы в будущем программном изделии. В такой модели отражаются внешние события (действия пользователя) и вызываемые этими событиями действия с экземплярами классов.
Например, в рассматриваемом примере процесс определения нового данного должен включать ввод имени данного и его описания, включающего тип данного, уровень агрегирования, границы индексов для массива. После ввода пользователем имени данного нужно проверить, является ли это имя уникальным.
После ввода границ индекса для массива также нужно проверить их допустимость. Если пользователь указал все характеристики данного правильно, нужно построить экземпляр объекта “данное” и включить его в множество данных.
1.3 Процесс объектно-ориентированного проектирования
Объектно-ориентированное проектирование (Object-Oriented Design - OOD) - это поступательный итеративный процесс. Граница между объектно-ориентированным анализом и проектированием расплывчата и построение проекта программного изделия состоит из ряда циклов, в которых уточняются описания классов и взаимодействия между ними, разрабатываются реализующие их программы, проводится их отладка и тестирование и по результатам каждого этапа уточняются рабочие документы предыдущих этапов, дорабатываются описания классов и программы. Эти циклы повторяются до получения требуемого результата.
В рассмотренном выше примере были выделены классы “множество данных” и “данное”. Пусть классу “множество данных” присвоено имя TXSet.
С учетом имеющихся инструментальных средств класс TXSet может быть построен на основе класса Array из библиотеки CLASSLIB, т.е. это множество может быть интерпретировано массивом. Массив представляет собой упорядоченную совокупность однотипных элементов, в то же время данные могут принадлежать различным типам и каждому типу соответствует свой набор характеристик. Это противоречие можно преодолеть, если элементами массива TXSet будут указатели на экземпляры данных.
Чтобы использовать указатели на экземпляры данных как элементы массива, все классы, определяющие типы данных, должны быть образованы из общего базового класса.
Пусть требуется обеспечить возможность использования числовых скалярных данных и массивов (векторов и прямоугольных матриц), а также данных типа строк и массива строк. Естественно определить для каждого такого типа свой класс: TDScal, TDArray, TDString, TDStringArray. В каждом из этих классов должно быть поле идентификатора данного ident, поле описания данного head и, возможно, поле flags, представляющее собой набор битов, дополняющих описание данного. Может оказаться удобным иметь и поля, содержащие количество знаков при представлении скаляра или элементов массивов (width) и количество цифр в дробной части для представления чисел (dec). Все эти данные можно объединить в классе TData, базовом для остальных классов данных. Таким образом, вместо одного класса “данное”, выделенного на этапе анализа, появилось пять классов. После этого следует вернуться к этапу анализа и оформить рабочие документы анализа для новых классов.