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

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

Как мы уже отмечали, концепция абстракции в объектно-ориентированном программировании адекватно моделируется посредством ламбда-исчисления. Точнее говоря, операция абстракции в полной мере является моделью одноименного понятия ООП.

Отличия объектно-ориентированного подхода от структурного:

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

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

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

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

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

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

Глава 2. Объектно-ориентированные case-средства (Rational Rose)

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах[Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012].

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

В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

диаграммы классов;

диаграммы состояний;

диаграммы сценариев;

диаграммы модулей;

диаграммы процессов;

спецификации классов, объектов, атрибутов и операций

заготовки текстов программ;

модель разрабатываемой программной системы.

Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX)[ CASE-технологии. Современные методы и средства проектирования информационных систем / Вендров А.М.].

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

Моделирование предметной области «Управление заявками на техническое обслуживание»

Описание предметной области

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

- Создание комплексных информационных систем;

- Обслуживание парка ПК;

- Продажа программного обеспечения;

- Проектирование и монтаж локальных сетей;

- Информационная защита данных;

- Разработка фирменного стиля.

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

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

Любая деятельность компании ООО «Сервисный центр» сопровождается соответствующей документацией, что отражается в АИС «Управление обслуживающей организации», что дает возможность оперативно получать информацию различного характера[Валдайцев, С.В. Управление инновационным бизнесом: учебное пособие / С.В. Валдайцев. – М.: Юнити_Дана, 2001. 343 с.].

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

В ходе изучения деятельности организации так же были выявлены

следующие проблемы:

- В системе отсутствует функция оперативного оповещения сотрудников и руководителя о «горящей» или даже просроченной заявки.

Сотрудник видит все свои заявки, но без напоминания может пропустить срок их исполнения;

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

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

Кроме того, в отчетный период необходимо составление аналитических отчетов, включающих в себя анализ работы службы техподдержки за определенный период, что очень затруднительно[Богатин, Ю.В. Экономическое управление бизнесом: учебное пособие для вузов / Ю.В. Богатин, В.А. Швандар. – М].

Диаграмма прецедентов

Перед построением диаграммы прецедентов (рис. 1) составим таблицу распределения требований по субъектам и прецедентам:

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

Сценарий (scenario) – это последовательность шагов, описывающих взаимодействие пользователя и системы.

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

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

Прецеденты считаются важной частью языка UML. Однако удивительно то, что определение прецедентов в UML довольно скудное. В UML ничего не говорится о том, как определять содержимое прецедента. Все, что описано в UML, – это диаграмма прецедентов, которая показывает, как прецеденты связаны друг с другом. Но почти вся ценность прецедентов как раз в их содержании, а диаграмма имеет ограниченное значение[ В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

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

Можно выделить такие цели создания диаграмм прецедентов:

определение границы и контекста моделируемой предметной области на ранних этапах проектирования;

формирование общих требований к поведению проектируемой системы;

разработка концептуальной модели системы для ее последующей детализации;

подготовка документации для взаимодействия с заказчиками и пользователями системы[Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012].

Рис. 1 Диаграмма прецедентов

Диаграмма деятельности

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

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

Таким образом, диаграммы деятельности можно считать частным случаем диаграмм состояний. Они позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних деятельностей и действий. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].