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

ГЛАВА 3. ИСПОЛЬЗОВАНИЕ УНИФИЦИРОВАННОГО ЯЗЫКА МОДЕЛИРОВАНИЯ НА ПРИМЕРЕ НАЛОГОВОЙ ОРГАНИЗАЦИИ

В качестве предметной области, как и в главе 2, рассматривается работа подразделения учета налогоплательщиков-организаций.

На начальной стадии (или стадии формирования требований) стро­ится на­чальная диаграмма вариантов использования (рис.5).

Рис.5 Начальная диаграмма вариантов использования

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

• Кто использует систему непосредственно?

• Кто отвечает за эксплуатацию системы?

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

• Какие другие системы взаимодействуют с данной системой?

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

На стадии проектирования уточняется диаграмма вариантов использова­ния и строится архитектура системы, основой которой являются диаграммы классов. В данном примере ограничимся построением диаграммы классов и диаграммы взаимодействия. Диаграммы взаимодей­ствия строятся для уточне­ния диаграммы вариантов использования и перехода к диаграммам классов. Так, диаграмма последовательности (рис. 6) иллюстрирует один из возможных сценариев развития событий в рамках варианта использования "Зарегистриро­вать налогоплатель­щика". Предполагается, что налогоплательщик ставится на учет впер­вые и все его документы в полном порядке.

Структура программной системы описывается с помощью не­скольких диа­грамм классов, главная из которых представляет собой диаграмму пакетов (по­добную диаграммам, представленным в приложении рис. 8 и 9), а остальные диа­граммы раскрывают содержимое каждого из пакетов. При построении диа­граммы классов предметной области выделение этих классов (классов-сущно­стей) может быть анало­гично выделению сущностей в процессе моделирования данных. Данные классы должны иметь концептуальный характер и отвечать на вопрос "что?", а не "как?". Начальный список может быть со­ставлен следую­щим образом:

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

Рис. 6 Диаграмма последовательности для варианта использования

"Зарегистрировать нало­гоплательщика"

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

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

Рис. 7 Диаграмма классов предметной области

Определяются действия (операции), выполняемые каждым клас­сом. При определении операций нужно учитывать следующие реко­мендации:

• каждая операция должна выполнять одну простую функцию;

• название операции должно отражать результат функции, а не то,

как она выполняется.

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

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

ЗАКЛЮЧЕНИЕ

Итак, объектная модель является концептуальной базой объектно-ориентированного подхода (ООП).

В основе ООП, лежит объектная декомпозиция.

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

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

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

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

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

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

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Анисимов В.В. Проектирование информационных систем. Электронный ресурс: https://sites.google.com/site/anisimovkhv/learning/pris.
2. Буч Г., Якобсон А., Рамбо Дж., UML. Классика CS. Издание второе, - СПб.: Питер, 2006. - 736 с.
3. Галямина И.Г., Управление процессами, - СПб.: Питер, 2013. - 304 с.
4. Грекул В. И., Денищенко Г. Н., Коровкина Н. Л.— Проектирование информационных систем: учебное пособие / 2-е изд., испр. — М.: Интернет-Университет информационных технологий (ИНТУИТ.РУ): БИНОМ. Лаборатория знаний, 2010 .С 299.
5. Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом “Вильяме”, 2005. — 1328 с.: ил. — Парал. тит. англ.
6. Диго С.М., Базы данных. Проектирование и создание: Учебно-методический комплекс. – М.: Изд. центр ЕАОИ. 2008. – 171 с.
7. Дубейковский В.И., Эффективное моделирование с CA ERwin Process Modeler (BPwin; AllFusion Process Modeler), - М.: Диалог-МИФИ, 2009, - 384 с.Кириллов, В. В., Введение в реляционные базы данных / В. В. Кириллов, Г. Ю. Громов. — СПб.: БХВ-Петербург, 2009. — 464 с.
8. Иващенко И.Г. Проектирование интерактивных мультимедиасистем : метод. Указания по выполнению лабораторных работ / И.Г. Иващенко. — М. : МГУП им. Ивана Федорова, 2011. —100 с.
9. Иващенко И.Г. Теория информационных процессов и систем : метод. Указания по выполнению лаб. работ / И.Г. Иващенко. — М. МГУП имени Ивана Федорова, 2013. — 292 с.
10. Информационные системы : учеб. Пособие для вузов / под ред. В.Н. Волковой, Б.И. Кузина. — СПб. : Изд-во СПбГТУ, 1998. — 213 с.
11. Коваленко В.В. Проектирование информационных систем / В.В. Коваленко. — М. : Форум, 2014. —320 с.
12. Коцюба И.Ю., Чунаев А.В., Шиков А.Н. Основы проектирования информационных систем. Учебное пособие. – СПб: Университет ИТМО, 2015. – 206 с.
13. Ларман К., Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку, - М.: Вильямс, 2013. - 736 с.
14. Леоненков А.В., Самоучитель UML 2, - СПб.: БХВ-Петербург, 2007. - 576 с.
15. Маклаков С.В., Туманов В.Е., Проектирование реляционных хранилищ данных, - М.: Диалог-МИФИ, 2007, - 336 с.
16. Максимович Г.Ю. Информационные системы : учеб. пособие. 2-еизд. испр. и доп. / Г.Ю. Максимович, А.Г. Романенко, О.Ф. Самойлюк. — М. Российский государственный гуманитарный университет, 2007. — 289 с.
17. Меняев М.Ф. Управление проектами. MS Projeсt : учеб. пособие / М.Ф. Меняев. — М. : Омега-Л, 2005. — 276 с.
18. Методы и средства проектирования информационных систем и технологий: метод. Указания по выполнению лабораторных работ / И.Г. Иващенко; Моск. гос. ун-т печати имени ИванаФедорова. — М.: МГУП имени Ивана Федорова, 2015. —160 с.
19. Мишенин А.И. Теория экономических информационных систем: учебник / А.И. Мишенин. – М. : Финансы и статистика, 2001. — 240 с.
20. Новиков Ф.А., Иванов Д.Ю., Моделирование на UML [Электронный ресурс]: Интернет книга. - Электронные данные. - 2013. - Режим доступа: http://book.uml3.ru.
21. Новиков Ф.А., Иванов Д.Ю., Моделирование на UML. Теория, практика, видеокурс, - СПб.: Профессиональная литература, 2010. - 640 с.
22. Петров В.Н. Информационные системы : учебник / В.Н. Пет-ров. — СПб.: Питер, 2002. — 688 с.
23. Рамбо Дж., Блаха М., UML 2.0. Объектно-ориентированное моделирование и разработка, - СПб.: Питер, 2007. - 544 с.
24. Репин В.В., Елиферов В.Г., Процессный к управления. Моделирование бизнес-процессов, - М.: Манн, Иванов и Фербер, 2013. - 544 с.
25. Роберт Дж. Мюллер, Проектирование баз данных и UML, - М.: Лори, 2013, - 432 с.
26. Советов Б. Я., Базы данных: теория и практика : Учебник для бакалавров / 2-е изд., - М.: Юрайт, 2012. - 464 с
27. Фатрелл Роберт T. Управление программными проектами. Достижение оптимального качества при минимуме затрат / Роберт T. Фатрелл, ДональдФ. Шафер, Линда И. Шафер. М.: Вильямс, 2003. —1117 c.