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

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

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

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

Добавлен: 01.04.2023

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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


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

ЗАКЛЮЧЕНИЕ

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

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

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

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