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

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

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

2.1. Smalltalk и GUI

Термин “объектно-ориентированный” окончательно утвердился с появлением языка программирования Smalltalk, который был создан в исследовательском центре Xerox в Пало Альмо. Он основывался не только на языке Simula, но и на диссертации Алана Кая (Alan Kay), выполненной в университете штата Юта. Как отмечено в работе [659], эти исследования были основаны на представлении маленького, но универсального персонального компьютера, способного решать любые задачи управления информацией. Первой версией подобного устройства была машина Flex, которая получила название Dynabook. Smalltalk — это, по сути, программное обеспечение для Dynabook, сильно зависимое от понятия классов языка Simula, а также понятия наследования и структурных особенностей языка Lisp.

Lisp (LISt Processing) означает “обработка списков”. Этот язык, изначально разработанный Джоном Маккарти приблизительно в 1958 году, стал основным языком реализации для многих ранних работ в области искусственного интеллекта.

Smalltalk объединил понятие класса из Simula с набором функциональных абстракций, подобных Lisp, хотя, как языки программирования, Smalltalk и Lisp достаточно не похожи.

Следующий этап, который пришелся на 1980-е годы, продемонстрировал рост интереса к интерфейсу пользователя (UI). Самый известный пионер в области коммерческих продуктов, компания Xerox, а позже и компания Apple заинтересовали мир удобным WIMP интерфейсом, и много идей в Smalltalk прочно связано с этими разработками [2].

WIMP — это сокращение от Windows, Icons, Menus (иногда Mice), Pointers, которое обозначает стиль графического интерфейса пользователя (Graphical User Interface — GUI).

С одной стороны, объектно-ориентированное программирование способствовало разработке таких интерфейсов — особенно это касается Lisa и Macintosh от компании Apple — а с другой, стиль объектно-ориентированных языков находился под влиянием идеологии WIMP. Наиболее очевидное следствие этого — это большое (по сравнению с другими сферами) множество библиотечных объектов для разработки интерфейса. Одной из основных причин успеха объектно-ориентированного программирования была сложность таких интерфейсов и сопутствующая этому высокая цена реализации. Можно предположить, что без присущей объектно-ориентированному коду возможности повторного использования было бы невозможно обеспечить столь широкое распространение таких интерфейсов. Например, известно, что для разработки Apple Lisa, предшественника Macintosh, потребовалось более 200 человеко-лет работы, большая часть которой ушла на разработку интерфейса. На протяжении этого периода влияние WIMPстиля было настолько сильным, что все терминалы были постепенно оборудованы внешними интерфейсами WIMP, такими как Microsoft Windows, или им подобными. С учетом курса на стандартизацию в открытых системах на основе UNIX также учитывались аспекты UI, причем в качестве немаловажного фактора выступала конкурентная борьба OpenLook, OSF Motif и других подобных программ. В этом смысле объектно-ориентированный подход наложил свой отпечаток на отрасль компьютеризации и определил тот внешний вид экрана, какой мы привыкли видеть с 1993 года.

2.2. Система управления проектами Redmine

Информационная система Redmine представляет собой веб-приложение для управления проектами. Центральным понятием предметной области являются пользователи и задачи. Основой для идентификации, аутентификации в системе есть пользователь, это могут быть сотрудники и клиенты которые участвуют в разных ролях проектах, задачах. Роль пользователя определяет доступность участия в различных проектах. Назначается роль в каждом проекте, пользователь может иметь несколько ролей. Приложение написано на объектно-ориентированном языке программирования Ruby, работает на веб-Фреймворке Ruby on Rails, серверную часть приложения устанавливают обычно на Linux подобные системы, доступ в клиентскую часть осуществляется через веб браузер. В системе присутствует связь Объект - Пользователь. Есть Супер Пользователь - это администратор, который управляет системой на уровне предоставления доступа пользователям, создание логики работы системы, занесение названий трекеров, статусов, полей, установкой плагинов, архивация базы данных и т.д., но также может быть участником любых проектов и выполнять задачи от других пользователей системы. Руководитель проекта создает проект и делегирует другим участникам роли в зависимости от выполняемых функций в проекте. Система оповещений отправляет пользователям письма на их электронные ящики о статусе задач, уведомляет о новых задачах. Схема 7 показывает, какие могут быть связи в информационной системе.

Схема 7. Связи между пользователями системы и объектами

Структура системы Redmine:

Пользователи системы – это те, кто используют систему;
Роли – создаются пользователями, понятным названием. Непосредственно права доступа назначаются из предлагаемого системой списка прав;
Проекты – это объекты, которые допускают иерархическую вложенность, благодаря этой сущности можно вести одновременно несколько проектов и разграничивать роли, организовать связи и совместную выполняемость;
Трекеры – по-простому это метка или принадлежность, в ООП это подкласс класса Задача. Примеры трекеров: Ошибка, Снабжение, Согласовано и т.д.
Задачи – главное понятие системы. У каждой задачи есть Автор, Описание, привязка к Трекеру, Кому назначена задача, Наблюдатель за ходом выполнения. У каждой задачи есть статусы, например: В работе, Отклонена, Закрыта и т.д. На каждую задачу задается оценочное время выполнения, прикрепляются файлы.
Отслеживание изменения параметров задач – отслеживание изменений параметров задач пользователями в системе регулируется двумя сущностями: Запись журнала изменений и Измененный параметр. Пользователи, редактируя задачу, ведут диалог, а система отслеживает и записывает историю действий;
Связи между задачами – задачи могут быть взаимосвязаны, задача является подзадачей для другой или предшествовать ей.
Учет затраченного времени (на задачу и на проект) – благодаря этой сущности можно оценить, сколько времени было затрачено каждым пользователем, и какой вклад внес каждый в реализацию проекта;
Привязка репозиториев – интеграция с различными внешними системами управления версиями. Интеграция заключается в отслеживании изменений во внешнем репозитории, фиксации изменений в базе данных, анализу изменений с целью привязке к задачам. В интеграции участвуют три сущности: Репозиторий, Редакция и Изменение.

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

Редакция – отображение редакции репозитория, привязана к задаче и к автору-пользователю.

Изменение – хранит все действия над файлами в каждой редакции.

Получение уведомлений – уведомляет пользователей об изменениях, на сайте, возможность подключения почтовых систем, RSS каналов подписки.

Эту Информационную Систему обычно используют для разработки программного обеспечения, используя репозитории в которой существует версионность объектов. Жизненный цикл задач в Redmine начинается от создания задачи, с указанием исполнителя, сроков выполнения, до статуса Выполнена или Закрыта. Жизненный цикл задачи - Схема 8.

Схема 8. Жизненный цикл задачи

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

В книге автора Алистера Коберна «Современные методы описания функциональных требований к системам», описаны примеры написания и поведение бизнес-процессов. Пример сценария использования, который может быть реализован в системе Redmine.

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

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

Например, рассмотрим простой алгоритм ниже.

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

2.3. Примеры реализации полиморфизма в PHP, UML

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

Она определяется как набор спецификаций, созданных и распределенных Object Management Group. UML является расширяемым и масштабируемым.

Цель UML заключается в предоставлении общего словаря объектно-ориентированных терминов и Diagramming методов, которые достаточно богаты, чтобы смоделировать любой проект разработки систем на основе анализа посредством реализации. Программные продукты, которые позволяют рисовать UML схемы, примеры: Microsoft Visio, IBM Rational Rose, ArgoUML, StarUML

Компоненты UML

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

Пример UML обозначения для класса

Экземпляр Диаграмма UML-нотации

Экземпляр объекта с атрибутами

Операции, выполняемые на объектах.

Constructor/Destructor - Создание новых экземпляров класса и удаление существующих экземпляров класса. Например, при добавлении нового сотрудника.
Query - Доступ состояние без изменения значения, не имеет побочных эффектов. Например, найти адрес конкретного работника.
Update - Изменение значения одного или нескольких атрибутов и влияют на состояние объекта, например, изменение адреса работника.

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

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

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

Нижняя часть - описаны методы класса. Видимость членов класса атрибутов и методов, обозначения перед именем:

Публичный – «+»
Приватный – «-»
Защищенный – «#»
Производный – «/» можно совмещать с другими
Пакет – «~»

Типы областей действий для членов класса: экземпляр и классификатор.

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

Классификатор – вызов метода не меняет состояние объекта, значения полей одинаковы для всех экземпляров в данной единицы трансляции.

Схема 9. Простая схема покупки товара в языке проектирования UML

Выше представлена схема номер 9 покупки товара. Activity diagram создана с помощью свободно распространяемого программного обеспечения Violet UML Editor.

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