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

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

Язык UML находится в процессе стандартизации, проводимом ОМG (Object Management Group) – организацией по стандартизации в области объектно-ориентированных методов и технологий, и в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии программного обеспечения (ПО). Язык UML принят на вооружение практически всеми крупнейшими компаниями – производителями ПО. Кроме того, практически все мировые производители САSЕ-средств, помимо Rational Software (Rational Rose) поддерживают UML в своих продуктах (Paradigm Plus, System Architec, Microsoft Visual Modeler, Delphi, PowerBuilder и др.).

Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических, технических и др. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый ОМG в 1997 году, предлагает следующий набор диаграмм для моделирования:

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

---

Рассматривая диаграмму UML, необходимо помнить, что основной принцип UML заключается в том, что любая информация на конкретной диаграмме может быть подавлена. Это подавление может носить глобальный характер – скрыть все атрибуты – или локальный – не показывать какие-нибудь конкретные классы. Поэтому по диаграмме вы никогда не можете судить о чем-нибудь по его отсутствию (Фаулер M. UML Основы, 3 е издание. – Пер. с англ. – СПб: Символ Плюс, 2004. – С. 41).

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

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

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

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

---

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

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

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

ГЛАВА 3. ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД ПРИМЕНИТЕЛЬНО К ЭКОНОМИЧСЕКИМ ИНФОРМАЦИОННЫМ СИСТЕМАМ

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

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

Составим для данного примера диаграмму вариантов использования (рисунок 1).

Идея описания функциональных требований в виде вариантов использования была сформулирована в 1986 г. Иваром Якобсоном. (Вендров А. М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2006 - С. 179).

---

Достоинства диаграммы вариантов использования заключаются в том, что она:

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

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

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

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

• Кто использует систему непосредственно?
• Кто отвечает за эксплуатацию системы?
• Какое внешнее оборудование используется системой?
• Какие другие системы взаимодействуют с данной системой?

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

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

---

Рисунок 1

По данной диаграмме составим описания вариантов использования (таблица 1, таблица 2), рассмотрев принцип действия актера “материально ответственное лицо” при приеме и выдаче товара.

Таблица 1. Описание варианта использования «Приём/поставка товара»

1. Главный раздел
Имя варианта использования	Приём/поставка товара
Актеры	Материально ответственное лицо, Поставщик
Цель	Принять товар на склад
Краткое описание	Материально ответственное лицо принимает товар на склад от поставщика согласно приходным ордерам
Тип	Базовый
2. Раздел «Типичный ход событий»
Действия актера	Отклик ПК
1. Материально ответственное лицо запрашивает просмотр карточки складского учета	2. ПК показывает окно карточки складского учета
3. Материально ответственное лицо запрашивает изменение записи в карточке складского учета	4. ПК показывает окно с записями карточки складского учета
5. Материально ответственное лицо изменяет записи в карточке складского учета	6. ПК подтверждает изменение записей в карточке складского учета
7. Материально ответственное лицо запрашивает оформление приходного ордера	8. ПК показывает окно оформленного приходного ордера

Таблица 2. Описание варианта использования «Выдача/получение товара»

1. Главный раздел
Имя варианта использования	Выдача/получение товара
Актеры	Материально ответственное лицо, Получатель
Цель	Выдать товар со склада
Краткое описание	Материально ответственное лицо выдаёт товар со склада получателю согласно расходным ордерам
Тип	Базовый
2. Раздел «Типичный ход событий»
Действия актера	Отклик ПК
1. Материально ответственное лицо запрашивает просмотр карточки складского учета	2. ПК показывает окно карточки складского учета
3. Материально ответственное лицо запрашивает изменение записи в карточке складского учета	4. ПК показывает окно с записями карточки складского учета
5. Материально ответственное лицо изменяет записи в карточке складского учета	6. ПК подтверждает изменение записей в карточке складского учета
7. Материально ответственное лицо запрашивает оформление расходного ордера	8. ПК показывает окно оформленного расходного ордера

---