Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Преимущества и недостатки объектно-ориентированного подхода).pdf

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

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

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

Буч отмечает также ряд следующих преимуществ объектно- ориентированного подхода:

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

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

3. Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию.

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

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

При переходе от структурного подхода к объектному, как при всякой смене технологии, необходимо вкладывать деньги в приобретение новых инструментальных средств. Здесь следует учесть и расходы на обучение (овладение методом, инструментальными средствами и языком программирования). Для некоторых организаций эти обстоятельства могут стать серьезными препятствиями.

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

Анализ деятельности предприятия

Характеристика предприятия

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

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

Обоснование необходимости проектирование ИС

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

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

Рисунок 2. Диаграмма вариантов использования модуля «Резерв»

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

Рисунок 3. Диаграмма вариантов использования модуля «ЗИП»

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

Рисунок 4. Диаграмма вариантов использования модуля «Ремонт»

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

Реализация объектно-ориентированного подхода при проектировании ИС

Выбор средств объектно-ориентированного подхода

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

Rational Rose – мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта будет возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм.

В распоряжение проектировщика системы Rational Rose предоставляет следующие типы диаграмм, последовательное создание которых позволяет получить полное представление о всей проектируемой системе и об отдельных ее компонентах^[1]:

Use case diagram (диаграммы прецедентов);

Activity diagram (диаграммы активности);

Sequence diagram (диаграммы последовательностей действий);

Рассмотрим процесс моделирования архитектуры и поведения системы при помощи языка UML.

Use case diagram (диаграмма вариантов использования) – диаграмма, на которой отражены отношения вариантов взаимодействия компонентов системы. Каждый вариант использования представляет собой некоторое действие которое выполняет система в ответ на какие-то воздействия, которые оказывает внешний объект (таким объектом может быть пользователь). Таким образом, получается, что диаграмма Use Case описывает взаимодействия пользователя с системой.

Sequence diagram (диаграмма последовательностей) – диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. Описание системы на основе диаграмм последовательностей предполагают исследование системы с точки зрения того, как взаимодействуют между собой её отдельные элементы в рамках одного варианта использования (Use Case). Каждый вариант использования можно рассматривать в виде взаимодействия компонентов системы. Таким образом, получается, что компоненты системы могут вызывать друг друга и вызывать сами себя. Описание взаимодействия средствами языка UML сводится к построению диаграммы последовательностей.

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

Структурные диаграммы (Structure Diagrams) – это диаграммы описывающие систему как набор элементов, а так же взаимодействия между этими элементами.

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

Диаграмма дает представление об аппаратном обеспечении, о его компонентах и связи между этими компонентами, а так же дает четкое понимание о необходимых при развертывании аппаратных требованиях системы.

Component diagram (диаграмма компонентов) — статическая структурная диаграмма, показывающая разбиение программной системы на структурные компоненты и связи (зависимости) между этими компонентами. В качестве физических компонент могут выступать базы данных, файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п. Диаграмма компонентов для проектируемой системы ПОП будет иметь следующий вид (рис.5):