Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Анализ деятельности предприятия).pdf
Добавлен: 28.06.2023
Просмотров: 25
Скачиваний: 3
Преимущества и недостатки объектно-ориентированного подхода
В отличие от структурного подхода объектно-ориентированный имеет ряд преимуществ:
- описание системы в виде объектов больше соответствует содержательному смыслу предметной области. Например, при использовании структурного подхода БД должна удовлетворять требованиям нормализации, в соответствии с которыми данные по одному и тому же объекту (сущности из реального мира) могут храниться в нескольких таблицах;
- сущности реального мира, как правило, обладают поведением, что в объектно-ориентированном проектировании отражается с помощью определения методов класса. В структурном подходе данные (атрибуты) и алгоритмы (методы) существуют отдельно друг от друга;
- объединение атрибутов и методов в объекте (классе), а также инкапсуляция позволяют добиться большей внутренней и меньшей внешней связности между компонентами системы. Это облегчает решение проблем:
- адаптации системы к изменению существующих или появлению новых требований;
- сопровождения системы на разных стадиях жизненного цикла;
- повторного использования компонентов;
- объектно-ориентированный подход позволяет легче организовать параллельные вычисления, так как каждый объект обладает собственными значениями характеристик (атрибутов) и поведением, за счет чего можно добиться его автономной работы;
Case-средства, поддерживающие объектно-ориентированный подход, на основе информации об объектах позволяют достичь большей степени автоматизации кодогенерации. Case-средства, поддерживающие структурный подход, хорошо справляются с генерацией структур БД.
Однако следует отметить, что эта структура должна удовлетворять требованиям нормализации. В связи с чем автоматическая кодогенерация (например, экранов или функций обработки данных) возможна лишь в редких случаях.
Анализ деятельности предприятия
Характеристика предприятия
Основной деятельностью компании ОАО «РЖД» является предоставление транспортных услуг. Для обеспечения постоянной и бесперебойной работы организации используется большое количество компьютерного оборудования. Обслуживание компьютерной техники производит отдельный филиал – Главный Вычислительный Центр. Так как территория, которую обслуживает компания, покрывает всю территорию Российской Федерации, для улучшения управляемости филиал разделен на структурные подразделения – информационно-вычислительные центры каждой дороги, в частности, Октябрьскую Железную дорогу обслуживает Санкт-Петербургский Информационно-Вычислительный Центр, который на территории данной зоны ответственности производит полное обслуживание всего комплекса вычислительных систем, сетей и программного обеспечения.
В каждом вычислительном центре существуют Региональные Вычислительные Центры (РВЦ), делящие всю территорию на более мелкие участки. Они занимаются поддержкой пользователей по вопросам, связанным технической работоспособностью вычислительных систем, то есть: либо мелким ремонтом на месте, либо при серьезных неисправностях- отправкой техники в отдел, занимающийся ремонтом (отдел РПО). В отделе РВЦ есть инженер, который занимается снабжением всех удаленных площадок (удаленные площадки (группы) требуются в связи с большой территорией обслуживания) резервом вычислительной техники, всеми необходимыми расходными материалами, а также доставкой из/в ремонт неисправной аппаратуры и ее дальнейшей передачей в отдел РПО для ремонта. Резерв техники необходим для предоставления подмены на оперативных рабочих местах (в основном связанных с безопасностью движения (в соответствии с регламентом)) в случаях невозможности ремонта на месте или невозможности устранения неисправности на месте в установленный срок.
Обоснование необходимости проектирование ИС
Исходя из вышеописанного, необходимо разработать «АРМ инженера по снабжению», который будет реализовывать взаимодействие между инженером по снабжению и руководителями площадок (групп). Взаимодействие заключается в следующем.
На каждой площадке должен быть оперативный резерв вычислительной техники и комплектующих - значит необходимо спроектировать модуль, с помощью которого можно будет оперативно, в реальном времени отслеживать наличие резерва. Наличие должно отслеживаться по каждой площадке отдельно и по категориям техники (системные блоки, мониторы, принтеры лазерные, принтеры матричные и т. д.). Диаграмма представлена на рис 1.
Рис. 1. Диаграмма вариантов использования модуля «Резерв»
На каждой площадке для ее нормального функционирования должны быть расходные материалы, соответственно, для своевременного снабжения (для своевременного заказа машины в гараже или при наличии уже заказанного рейса для комплектации в полном объеме отправки) - необходимо спроектировать модуль для регистрации заявок по расходным материалам руководителями удаленных площадок, просмотра и закрытия (в случае удовлетворения) этих заявок инженером по снабжению. Модуль должен содержать общее количество в остатке на складе, историю выдачи расходных материалов по площадкам и по категориям. Диаграмма представлена на рис. 2.
Рис. 2. Диаграмма вариантов использования модуля «ЗИП»
На каждой площадке скапливается неисправная техника и комплектующие, ожидающие отправки или уже отправленные в ремонт - соответственно необходим модуль, реализующий контроль за ходом ремонта, путем регистрации руководителем площадки заявки на ремонт (с внесением всех актуальных данных о балансовой единице, нуждающейся в ремонте) и далее внесением инженером по снабжению необходимых пометок о ходе ремонта. Модуль должен хранить историю ремонтов техники. Диаграмма представлена на рис. 3.
Рис. 3. Диаграмма вариантов использования модуля «Ремонт»\
Дополнительные требования к АРМу: разграничение уровней доступа (в частности руководитель площадки должен иметь права на регистрацию и просмотр заявок, а инженер по снабжению права на закрытие заявок и т.п.).
Реализация объектно-ориентированного подхода при проектировании ИС
Выбор средств объектно-ориентированного подхода
UML (Unified Modeling Language — унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки программного обеспечения. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна генерация исходного кода.
Для проектирования UML диаграмм приложения использовалось CASE-средство (от Computer Aided Software/System Engineering) Jude Community. Case–средства позволяют моделировать бизнес процессы, компоненты программного обеспечения, структуру и деятельность организаций. Использование CASE-средств оптимизирует эффективность проектирования, снижает вероятность расходы и вероятности ошибок.
Jude Community – мощное средство для проектирования программных комплексов любой сложности. С его помощью можно провести весь цикл разработки программы – от идеи до генерации кода. Серьезным преимуществом данной программы является ее свободное распространение.
Преимущества от использования:
- унифицированное средство общения между разработчиками;
- ускорение разработки;
- увеличение продуктивности.
Поскольку проектируемый АРМ будет состоять из программного приложения и базы данных, целесообразным является разработать диаграмму вариантов использования, диаграммы последовательностей и кооперативную диаграмму средствами JUDE. Разработка базы данных будет производится специализированным case-средством с возможностью генерации исходного кода – ER Win.
Результаты применения объектно-ориентированного подхода
Диаграмма вариантов использования (Use case diagram) позволяет сделать анализ бизнес-процессов, отображая приложение в статическом состоянии. В диаграмме описываются только функции, выполняемые актерами. Актером является пользователь, выполняющий определенную роль в системе.
Рис.4. Диаграмма вариантов использования
Диаграмма взаимодействия - это диаграмма, на которой представлено взаимодействие, состоящее из множества объектов и отношений между ними, включая и сообщения, которыми они обмениваются. Этот термин применяется к видам диаграмм с акцентом на взаимодействии объектов (диаграммах кооперации, последовательности и деятельности).
Существует два вида диаграмм взаимодействия: диаграммы последовательности (Sequence diagrams) и диаграммы кооперации (collaboration diagrams).
По результатам проведенного анализа бизнес-процессов можно составить диаграмму последовательности, основанную на обмене информацией между объектами. На рисунке 5 показан данный вид диаграммы для наиболее значимого прецедента.
Рис.5. Диаграмма последовательности: составление заявки на ЗИП
Диаграммы сотрудничества в большей степени заостряют внимание на связях между объектами, чем диаграммы последовательности событий. В принципе, на данной диаграмме представлена такая же информация, как и на диаграмме последовательности, но по-другому. Из нее легче понять связи между объектами, но труднее - последовательность событий. На рисунке 6 показан данный вид диаграммы.
Рис. 6. Диаграмма сотрудничества
Диаграммы деятельности позволяют моделировать сложный жизненный цикл объекта, с переходами из одного состояния (деятельности) в другое. Но этот вид диаграмм может быть использован и для описания динамики совокупности объектов. Они применимы и для детализации некоторой конкретной операции, причем предоставляют для этого больше возможностей, чем "классическая" блок-схема. Диаграммы деятельности описывают переход от одной деятельности к другой, в отличие от диаграмм взаимодействия, где акцент делается на переходах потока управления от объекта к объекту. На рисунке 7 показан данный вид диаграммы.
Рис. 7. Диаграмма активности
Заключение
В работе рассмотрены основные понятия, касающиеся применения объектно-ориентированного подхода к проектированию информационных систем. В ходе работы была предложена методика проектирования и описания бизнес-процесса предприятия и выполнено проектирование автоматизированного рабочего места инженера по снабжению регионального вычислительного центра.
Разработанный АРМ позволяет существенно упростить документооборот отдела, оперативно отслеживать наличие: резерва на площадках, потребность в расходных материалах; создавать заявки на ремонт техники, отслеживать его ход и просматривать историю.
Список использованной литературы
- Введение в системы баз данных – СПб: Издательский дом "Вильямс", 200. - 848 с.;
|
|
|
- Дейв Крейн, Эрик Паскарелло, Даррен Джеймс. AJAX в действии: Учебник – М.: Вильямс, 2006. 450 – 490 с.
- Диго С.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2005. – 592 с.
- Информационные системы: Учебник для вузов. 2-е изд. СПб: "Питер", 2010. - 656 стр.
- Кристиан Дари, Богдан Бринзаре, Филип Черчез-Тоза, Михай Бусика. AJAX и PHP. Разработка динамических веб-приложений: Учебник – М.: Символ Плюс, 2006.
- Разработка программного обеспечения - СПб : "Питер", 20100. - 592 стр.
- Реляционные базы данных: практические приемы оптимальных решений. – СПб.: БХВ-Петербург, 2011 – 400с.:ил;
- Симионов Ю.Ф., Боромотов В.В. Информационный менеджмент. — Ростов н.Д: Феникс, 2006, 250с., ил.