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

Содержание:

ВВЕДЕНИЕ

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

Проектирование экономических информационных систем - логически сложная, трудоемкая и длительная работа, для выполнения которой требуются специалисты высокой квалификации. Однако на практике разработчики иногда предпочитают пропускать этап проектирования и начинать сразу с программирования. Либо проектирование выполняется на интуитивном уровне с применением неформализованных методов. Зачастую подобные практики ведут к повышенным расходам на реализацию проекта. Согласно исследованиям, программисты и инженеры-тестировщики тратят примерно в два раза больше времени на обнаружение ошибок, допущенных на этапе проектирования. Стоимость ошибок вырастает с каждой итерацией. Так, исправление ошибки на стадии проектирования стоит в 2 раза дороже, на стадии тестирования – в 10 раз, а на стадии эксплуатации системы – в 100 раз дороже, чем на стадии анализа^[1]. Недовольство пользователей, получивших некачественное ПО, измеряется не только ценой разработки, но и репутацией компании. Таким образом, цель этапа проектирования информационных сетей – избежание увеличения затрат на разработку.

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

Исследователи называют объектно-ориентированный подход самым актуальным на сегодняшний день^[2]. Действительно, данный подход позволяет разработать хорошо структурированные и достаточно просто видоизменяемые программные системы. Благодаря ему и изменениям в организации труда повысилось качество программ, продуктивность программистов и эффективность коллективной работы. Это усиленно развивающееся направление стало стандартом во многих компаниях и программистских сообществах^[3].

Все перечисленное выше обусловило актуальность данной работы.

Цель исследования: дать характеристику объектно-ориентированному подходу к проектированию информационных систем.

Исходя из цели работы были сформулированы следующие задачи:

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

Глава 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ

1.1 ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД

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

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

Также мы обозначим основные подходы к проектированию и более подробно остановимся на объектно-ориентированном.

1.1 Проектирование как этап разработки информационной системы

Процесс разработки можно условно разделить на три этапа: проектирование, непосредственное написание кода и тестирование. Качество кода и, соответственно, готового продукта напрямую зависит от хорошо реализованного этапа проектирования. К.К. Иванов называет данный этап «чуть ли не важнейшим процессом»^[4].

Согласно ГОСТ 34.601–90 «Автоматизированные системы. Стадии создания», выделяют восемь стадий^[5]:

• формирование требований к автоматизированной системе;
• разработка концепции автоматизированной системы;
• техническое задание;
• эскизный проект;
• технический проект;
• рабочая документация;
• ввод в действие;
• сопровождение автоматизированной системы.

Д. Н. Медведев и Е.Е. Медведева описали этапы проектирования и внедрения информационной сетевой системы^[6]. Они представили шесть этапов деятельности: исследование предметной области, разработка архитектуры системы, реализация информационных систем, непосредственная физическая реализация системы, внедрение системы в процесс, сопровождение информационной системы.

При создании современных информационных систем разработчики сталкиваются с рядом проблем: выбор программных средств, выделенные ресурсов, соответствие системы бизнес-процессам и структуре организации. Особо отметим последний пункт. В нем заложена проблема функциональности информационной системы. Исследователи такие функции проектируемой программы, как решение проблем организации, оптимизация ее работы, обеспечивание получения компанией прибыли^[7].

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

В связи со всем вышеперечисленным в процессе проектирования выделяется два этапа:

1) анализ предприятия и построение существующей его архитектуры (модели);

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

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

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

1.2 Объектно-ориентированный подход

Структурный анализ (Structured Analysis, SA) и структурное проектирование (Structured Design, SD) сформировались в результате структурного программирования, появившегося в 1970-х^[9]. Методы структурного анализа дорабатывались и используются уже на протяжении многих лет.

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

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

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

Второй выделяемый вид декомпозиции – объектно-ориентированный. Структура системы определяется множеством объектов и связей между ними путем посылки сообщений, а поведение системы описывается в терминах обмена сообщениями между объектами^[10].

Второе отличие проявляется в объединении в объекте как атрибутивных данных (характеристики, свойства), так и поведения (функции, методы). В функционально-ориентированных системах функции и данные хранятся отдельно.

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

Рассмотрим более подробно объектно-ориентированный подход. А.В. Попов, А.Л. Григорьева и А.Ю. Лошманов назвали рассмотрение предметной области и логического решения задачи с точки зрения объектов основной идеей объектно-ориентированного анализа и проектирования^[12].

Л.Ю. Шевчук выделила основные идеи названного подхода, которые опираются на следующие положения:

• «Объектная модель описывает структуру объектов, составляющих систему, их атрибуты, операции, взаимосвязи с другими объектами.
• В объектной модели должны быть отражены те понятия и объекты реального мира, которые важны для разрабатываемой системы.
• Модель реального мира или его части может быть описана как совокупность взаимодействующих между собой объектов.
• Объект описывается набором параметров, значения которых определяют состояние объекта, и набором операций (действий), которые может выполнять объект.
• Взаимодействие между объектами осуществляется посылкой специальных сообщений от одного объекта к другому. Сообщение, полученное объектом, может потребовать выполнения определенных действий, например, изменения состояния объекта.
• Объекты, описанные одним и тем же набором параметров и способные выполнять один и тот же набор действий, представляют собой класс однотипных объектов»^[13].

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

Под классами объектов (object classes) Л.Ю. Шевчук понимает «группы объектов с одинаковыми свойствами, то есть с одинаковыми наборами переменных состояния и методов»^[14]. М.Е. Фленов предлагает иметь в виду «совокупность свойств, методов и событий»^[15].

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

При разработке программного обеспечения термин «объект» впервые был введен в языке Simula 67 для моделирования сущностей предметной области^[16]. Термин или схожие с ним понятия появились практически независимо в различных областях, связанных с компьютерами, в процессе разработки^[17].

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

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

Объекты обладают определенными свойствами^[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 – мощное средство для проектирования программных комплексов любой сложности. С его помощью можно провести весь цикл разработки программы – от идеи до генерации кода. Серьезным преимуществом данной программы является ее свободное распространение.

Преимущества от использования:

• унифицированное средство общения между разработчиками;
• ускорение разработки;
• увеличение продуктивности.

Поскольку проектируемый АРМ будет состоять из программного приложения и базы данных, целесообразным является разработать диаграмму вариантов использования, диаграммы последовательностей и кооперативную диаграмму средствами JUDE. Разработка базы данных будет производиться специализированным case-средством с возможностью генерации исходного кода – ER Win.

2.2 Применение ООП при проектировании ИС «Научный архив» для вузов

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

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

Информационная система «Научный архив» должна обеспечивать управление и контроль научных работ. От системы требуется соответствие следующим требованиям:

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

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

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

Помимо пользователей, в системе присутствует сущность «научная работа». Нам известно, что создавать научные работы в ИС «Научный архив» могут только пользователи с ролью «студент», а пользователи с ролью «преподаватель» имеют возможность поставить оценку данной работе. Соответственно, у сущности «научная работа» есть свойство оценки. Доступ к чтению данного свойства имеют все пользователи системы. Изменять же его могут только преподаватели и администратор системы. Также у сущности «научная работа» имеются следующие свойства: дата создания, уникальный идентификационный номер, идентификационный номер пользователя, создавшего данную сущность.

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

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

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

2.3 Применение ООП при проектировании ИС «Интранет» в организации ООО «Софт Сервис»

Для анализа применения объектно-ориентированного подхода при проектировании системы нами была выбрана организация ООО «Софт Сервис». Мы остановились на данной организации в связи с тем, что нам известна ее структура и потребности, которые мы выявили в ходе прохождения учебной практики на предприятии.

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

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

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

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

В соответствии с требованиями к данной системе мы можем выделить следующие объекты: администратор системы, карточка сотрудника, урок, нормативный документ.

Администратор системы имеет возможность создавать, редактировать и удалять карточки сотрудников, добавлять, редактировать и удалять уроки, добавлять, редактировать и удалять документы.

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Андрианов А. В. Разработка объектно-ориентированной модели процесса разработки программного проекта АСУ ТП / А. В. Адрианов // Молодой ученый. — 2018. — №21 (207). — С. 17-20.
2. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. — М.: Бином, 1998. — 560 с.
3. Вичугова А. А. Методы и средства концептуального проектирования информационных систем: сравнительный анализ структурного и объектно-ориентированного подходов / А. А. Вичугова // Прикладная информатика. — 2014. — №1(49). — С. 56-65.
4. ГОСТ 34.601–90 «Автоматизированные системы. Стадии создания» [Электронный ресурс] // «Корпоративные хранилища данных. Интеграция систем. Проектная документация». — URL: http://www.prj-exp.ru/gost/gost_34–601–90.php (дата обращения 10.01.20).
5. Грэхем И. Объектно-ориентированные методы. Принципы и практика / И. Грэхем. — М.: Вильямс, 2004. — 880 с.
6. Гутгарц Р. Д. Информационные технологии в управлении кадрами / Р. Д. Гутгард. — М.: ИНФРА-М, 2001. — 235 с.
7. Диго С. М. Базы данных: проектирование и использование: учебник / С. М. Диго. — М.: Финансы и статистика, 2005. — 592 с.
8. Крейн Д., Паскарелло Э., Джеймс Д. AJAX в действии: учебник / Д. Крейн, Э. Паскарелло, Д. Джеймс. — М.: Вильямс, 2006. — 640 с.
9. Иванов К. К. Проектирование информационных систем / К. К. Иванов // Молодой ученый. — 2017. — №19. — С. 22-24.
10. Ильясова Ф.С., Клеблеев Ш. А. Современные методологии объектно-ориентированного программирования / Ф.С. Ильясова, Ш. А. Клеблеев // Международный научный журнал «Символ науки». — 2015. — №11. — С. 118-121.
11. Инюшкина О.Г. Проектирование информационных систем (на примере методов структурного системного анализа): учебное пособие / О.Г. Инюшкина. — Екатеринбург: «Форт-Диалог Исеть», 2014. — 240 с.
12. Малышева Е. Ю., Бобровский С. М. Структурный и объектно-ориентированный подход к моделированию системы обучения [Электронный ресурс] / Е. Ю. Малышева, С. М. Бобровский // Cyberleninka. — URL: https://cyberleninka.ru/article/n/strukturnyy-i-obektno-orientirovannyy-podhod-k-modelirovaniyu-sistemy-obucheniya (дата обращения: 13.01.20).
13. Медведев Д. Н., Медведева Е.Е. Проектирование информационных систем гуманитарного профиля / Д. Н. Медведев, Е.Е. Медведева // Вестник ТГУ. — 2013. — вып. 11(27). — С. 1-7.
14. Мессенбок Х. Плюсы и минусы объектно-ориентированного программирования [Электронный ресурс] / Х. Мессенбок // Uni-Vologda. — URL: http://www.uni-vologda.ac.ru/oberon/infoart/plus&min.htm (дата обращения: 14.01.20).
15. Мухортов В. В., Рылов В. Ю. Объектно-ориентированное программирование, анализ и дизайн: метод. пособие / В. В. Мухортов, В. Ю. Рылов. — Новосибирск, 2002. — 108 с.
16. Петросян Г.С. Анализ объектно-ориентированной парадигмы и поиск лучшей альтернативы / Г. С. Петросян // Научно-технические ведомости СПбГПУ. — 2012. — № 6. — С. 87-90.
17. Попов А.В., Григорьева А.Л., Лошманов А.Ю. Объектно-ориентироованный анализ, проектирование и программирование информационной системы университета [Электронный ресурс] / А.В. Попов, А.Л. Григорьева, А.Ю. Лошманов // Электронный научный журнал «Современные проблемы науки и образования». — URL: https://www.science-education.ru/ru/article/view?id=7964 (дата обращения: 14.01.20).
18. Рудакова А. А. Объектно-ориентированный подход и объектноориентированные языки: проблемы изучения в вузе [Электронный ресурс] / А. А. Рудакова // Cyberleninka. — URL: https://cyberleninka.ru/article/n/obektno-orientirovannyy-podhod-i-obektno-orientirovannye-yazyki-problemy-izucheniya-v-vuze (дата обращения: 11.01.20).
19. Сафиулин Т.В., Серебрякова Т.А. Плюсы и минусы методологии использования объектно-ориентированного подхода для разработки и тестирования информационных систем [Электронный ресурс] / Т.В. Сафиулин, Т.А. Серебрякова // Интерактив Плюс. — URL: https://interactive-plus.ru/e-articles/391/Action391-117604.pdf (дата обращения: 11.01.20).
20. Сунгатуллина А.Т. Технологии и подходы к анализу и проектированию информационных систем [Электронный ресурс] / А.Т. Сунгатуллина // PPT online. — URL: https://en.ppt-online.org/74445 (дата обращения: 15.01.20).
21. Фленов М. Е. Библия Delphi / М. Е. Фленов. — 3-е изд., перераб. и доп. — СПб.: БХВ-Петербург, 2011. — 688 с.
22. Шевчук Л.Ю. Применение объектно-ориентированного подхода при построении интеллектуальных кадровых систем поддержки принятия решений / Л.Ю. Шевчук // Горный информационно-аналитический бюллетень. — 2006. —№6. — С. 224-227.

1. Инюшкина О.Г. Проектирование информационных систем (на примере методов структурного системного анализа. — Екатеринбург, 2014. — 240 с. ↑

2. Ильясова Ф.С., Клеблеев Ш. А. Современные методологии объектно-ориентированного программирования // Международный научный журнал «Символ науки». — 2015. — №11. — С. 118-121. ↑

3. Рудакова А. А. Объектно-ориентированный подход и объектноориентированные языки: проблемы изучения в вузе [Электронный ресурс]. — URL: https://cyberleninka.ru/article/n/obektno-orientirovannyy-podhod-i-obektno-orientirovannye-yazyki-problemy-izucheniya-v-vuze (дата обращения: 11.01.20). ↑

4. Иванов К. К. Проектирование информационных систем // Молодой ученый. — 2017. — №19. — С.22. ↑

5. ГОСТ 34.601–90 «Автоматизированные системы. Стадии создания» [Электронный ресурс]. — URL: http://www.prj-exp.ru/gost/gost_34–601–90.php (дата обращения 10.01.20). ↑

6. Медведев Д. Н., Медведева Е.Е. Проектирование информационных систем гуманитарного профиля // Вестник ТГУ. — 2013. — вып. 11(27). — С. 1-7. ↑

7. Иванов К. К. Проектирование информационных систем // Молодой ученый. — 2017. — №19. — С.22-24. ↑

8. Андрианов А. В. Разработка объектно-ориентированной модели процесса разработки программного проекта АСУ ТП // Молодой ученый. — 2018. — №21 (207). — С. 17-20. ↑

9. Инюшкина О.Г. Проектирование информационных систем (на примере методов структурного системного анализа. Екатеринбург, 2014. С. 240. ↑

10. Вичугова А. А. Методы и средства концептуального проектирования информационных систем: сравнительный анализ структурного и объектно-ориентированного подходов // Прикладная информатика. — 2014. — №1(49). — С. 56-65. ↑

11. Сунгатуллина А.Т. Технологии и подходы к анализу и проектированию информационных систем [Электронный ресурс]. — URL: https://en.ppt-online.org/74445 (дата обращения: 15.01.20). ↑

12. 19. Попов А.В., Григорьева А.Л., Лошманов А.Ю. Объектно-ориентироованный анализ, проектирование и программирование информационной системы университета [Электронный ресурс] / А.В. Попов, А.Л. Григорьева, А.Ю. Лошманов // Электронный научный журнал «Современные проблемы науки и образования». — URL: https://www.science-education.ru/ru/article/view?id=7964 (дата обращения: 14.01.20). ↑

13. Шевчук Л.Ю. Применение объектно-ориентированного подхода при построении интеллектуальных кадровых систем поддержки принятия решений // Горный информационно-аналитический бюллетень. — 2006. —№6. — С. 224-227. ↑

14. Там же. С. 225. ↑

15. Фленов М. Е. Библия Delphi / М. Е. Фленов. — 3-е изд., перераб. и доп. — СПб.: БХВ-Петербург, 2011. — С. 43. ↑

16. Мухортов В. В., Рылов В. Ю. Объектно-ориентированное программирование, анализ и дизайн: метод. пособие. Новосибирск, 2002. 108 с. ↑

17. Диго С. М. Базы данных: проектирование и использование: учебник. — М.: Финансы и статистика, 2005. — 592 с. ↑

18. Фленов М. Е. Библия Delphi / М. Е. Фленов. — 3-е изд., перераб. и доп. — СПб.: БХВ-Петербург, 2011. — С. 43. ↑

19. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. — М.: Бином, 1998. — 560 с. ↑

20. Грэхем И. Объектно-ориентированные методы. Принципы и практика. — М.: Вильямс. — 2004. — 880 с. ↑

21. Гутгарц Р. Д. Информационные технологии в управлении кадрами / Р. Д. Гутгард. — М.: ИНФРА-М, 2001. — 235 с. ↑

22. Диго С. М. Базы данных: проектирование и использование: учебник. — М.: Финансы и статистика, 2005. — 592 с. ↑

23. Крейн Д., Паскарелло Э., Джеймс Д. AJAX в действии: учебник. — М.: Вильямс, 2006. — 640 с. ↑

24. Мухортов В. В., Рылов В. Ю. Объектно-ориентированное программирование, анализ и дизайн: метод. пособие. Новосибирск, 2002. 108 с. ↑

25. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. — М.: Бином, 1998. — 560 с. ↑

26. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. — М.: Бином, 1998. — 560 с. ↑

27. Мессенбок Х. Плюсы и минусы объектно-ориентированного программирования [Электронный ресурс]. — URL: http://www.uni-vologda.ac.ru/oberon/infoart/plus&min.htm (дата обращения: 14.01.20). ↑

28. Малышева Е. Ю., Бобровский С. М. Структурный и объектно-ориентированный подход к моделированию системы обучения [Электронный ресурс]. — URL: https://cyberleninka.ru/article/n/strukturnyy-i-obektno-orientirovannyy-podhod-k-modelirovaniyu-sistemy-obucheniya (дата обращения: 13.01.20). ↑

29. Петросян Г.С. Анализ объектно-ориентированной парадигмы и поиск лучшей альтернативы // Научно-технические ведомости СПбГПУ. — 2012. — № 6. — С. 87-90. ↑

30. Мессенбок Х. Плюсы и минусы объектно-ориентированного программирования [Электронный ресурс]. — URL: http://www.uni-vologda.ac.ru/oberon/infoart/plus&min.htm (дата обращения: 14.01.20). ↑

31. Сафиулин Т.В., Серебрякова Т.А. Плюсы и минусы методологии использования объектно-ориентированного подхода для разработки и тестирования информационных систем [Электронный ресурс]. — URL: https://interactive-plus.ru/e-articles/391/Action391-117604.pdf (дата обращения: 11.01.20). ↑