Файл: рименение объектно-ориентированного подхода при проектировании информационной системы ( ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД ).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 01.04.2023

Просмотров: 89

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

Объекты обладают определенными свойствами[19]. Перечислим их:

1. Инкапсуляция (encapsulation) — это механизм, который объединяет данные и методы, манипулирующие этими данными, и защищает и то и другое от внешнего вмешательства или неправильного использования. Когда методы и данные объединяются таким способом, создается объект[20].

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

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

Объект представляет собой абстракцию реальной или воображаемой сущности с четко выраженными концептуальными границами, индивидуальностью (идентичностью), состоянием и поведением[22].

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

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


Иерархия – еще одни важный термин в объектно-ориентированном подходе. Под ней подразумевается упорядочение абстракций путем расположения их по уровням[24].

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

1.3 Преимущества и недостатки объектно-ориентированного подхода

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

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

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

Г. Буч называет объектную модель естественной, так как она ориентирована на человеческое восприятие мира, а не на компьютерную реализацию[26].


Х. Мессенбок выделил такую позитивную сторону, как возможность создавать расширяемые системы (extensible systems)[27]. Расширяемость подразумевает, что существующую систему можно заставить работать с новыми компонентами, причем без внесения в нее каких-либо изменений. Компоненты могут быть добавлены на этапе выполнения.

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

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

  • инкапсуляция «на нужном уровне»;
  • повторное использование кода;
  • полиморфизм[29].

Однако наряду с положительными сторонами исследователями выявляются и недостатки. Так, Х. Мессенбок отмечает сложность использования объектно-ориентированного подхода. В качестве примеров он приводит сложность в проектировании классов, их изучении, необходимость запоминать большое количество библиотек[30].

Г.С. Петросяном была отмечена объективная сложность и недостаточная гибкость объектно-ориентированного подхода.

Т.В. Сафиулин и Т.А. Серебрякова в ходе анализа использования методологии объектно-ориентированного подхода для разработки и тестирования информационных систем выявили ряд недостатков подхода. Так, они отметили большие трудозатраты при разработке больших систем. Эта проблема является причиной следующего пункта - сложности ведения документации. В связи со сложностью иерархии появляются трудности соотнесения полей и классов с объектом. Наконец, исследователи отметили необходимость использования нескольких методов для прочтения кода[31].

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

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


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

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

Глава 2. ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА ПРИ ПРОЕКТИРОВАНИИ ИНФОРМАЦИОННЫХ СИСТЕМ

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

2.1 Применение ООП при проектировании ИС для ОАО «РЖД»

Основной деятельностью компании ОАО «РЖД» является предоставление транспортных услуг. Для обеспечения постоянной и бесперебойной работы организации используется большое количество компьютерного оборудования. Обслуживание компьютерной техники производит отдельный филиал – Главный Вычислительный Центр. Так как территория, которую обслуживает компания, покрывает всю территорию Российской Федерации, для улучшения управляемости филиал разделен на структурные подразделения – информационно-вычислительные центры каждой дороги, в частности, Октябрьскую Железную дорогу обслуживает Санкт-Петербургский Информационно-Вычислительный Центр, который на территории данной зоны ответственности производит полное обслуживание всего комплекса вычислительных систем, сетей и программного обеспечения.

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


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

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

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

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

Переходим к этапу выбора средств. UML (Unified Modeling Language — унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки программного обеспечения. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна генерация исходного кода.

Для проектирования UML диаграмм приложения использовалось CASE-средство (от Computer Aided Software/System Engineering) Jude Community. Case–средства позволяют моделировать бизнес-процессы, компоненты программного обеспечения, структуру и деятельность организаций. Использование CASE-средств оптимизирует эффективность проектирования, снижает вероятность расходы и вероятности ошибок.

Jude Community – мощное средство для проектирования программных комплексов любой сложности. С его помощью можно провести весь цикл разработки программы – от идеи до генерации кода. Серьезным преимуществом данной программы является ее свободное распространение.