Файл: Моделирование предметной области «Управление домашними финансами» с помощью UML (Описание предметной области. Постановка задачи).pdf

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

2 глава. Проектная часть

2.1. Выбор средства для моделирования предметной области решаемой задачи

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

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

Концепции объектно-ориентированного подхода и распределенных вычислений стали базой для создания консорциума Object Management Group (OMG), членами которой являются более 500 ведущих компьютерных компаний (Sun, DEC, IBM, HP, Motorola и др.). Основным направлением деятельности консорциума является разработка спецификаций и стандартов для создания распределенных объектных систем в разнородных средах. Базисом стали спецификации под названием Object Management Architecture (ОМА).

ОМА состоит из четырех основных компонентов, представляющих спецификации различных уровней поддержки приложений:

• архитектура брокера запросов объектов (CORBA – Common Object Request Broker Architecture) определяет механизмы взаимодействия объектов в разнородной сети;
• объектные сервисы (Object Services) являются основными системными сервисами, используемыми разработчиками для создания приложений;
• универсальные средства (Common Facilities) являются высокоуровневыми системными сервисами, ориентированными на поддержку пользовательских приложений (электронная почта, средства печати и др.);
• прикладные объекты (Application Object) предназначены для решения конкретных прикладных задач.

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

Существует несколько объектно-ориентированных методов, авторами наиболее распространенных из них являются Г. Буч, Д. Рамбо, И. Джекобсон. В настоящее время наблюдается процесс сближения объектно-ориентированных методов. В частности, указанные выше авторы создали и выпустили несколько версий унифицированного метода UML (Unified Modeling Language – унифицированный язык моделирования).

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

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

Современные CASE-средства поддерживают процессы инжиниринга и автоматизированного реинжиниринга.

Идеальное объектно-ориентированное CASE-средство должно содержать четыре основных блока: анализ, проектирование, разработка и инфраструктура.

Сравнительный анализ CASE-систем показывает, что на сегодняшний день одним из наиболее приближенных к идеальному варианту CASE-средств является семейство Rational Rose фирмы Rational Software Corporation. Следует отметить, что именно здесь работают авторы унифицированного языка моделирования Г. Буч, Д. Рамбо и И. Джекобсон, под руководством которых ведется разработка нового CASE-средства, поддерживающего UML.

Выделим основные критерии оценки и выбора CASE-средств.

1. функциональные характеристики:
   1. среда функционирования: проектная среда, программное обеспечение/технические средства, технологическая среда;
   2. функции, ориентированные на фазы жизненного цикла: моделирование, реализация, тестирование;
   3. общие функции: документирование, управление конфигурацией, управление проектом;
2. надежность;
3. простота использования;
4. эффективность;
5. сопровождаемость;
6. переносимость.

На сегодняшний день существует не так много объектно-ориентированных CASE-средств. Самым распространенным и востребованным на рынке является IBM Rational Rose.

IBM Rational Rose – CASE-средство предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. IBM Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML – Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования.

Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант – Rational Rose/C++ – позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

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

• Вводить данные.
• Получать данные.
• Создавать отчет.

Вариант использования [1] «Получить данные» включает такие компоненты, как «Учет доходов» и «Учет расходов». В результате получается следующую use-case диаграмму:

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

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

• идентификатор человека;
• Ф.И.О. Человека;
• возраст человека.

Человек имеет определенные виды доходов:

• Основной доход.
• Дополнительный доход.
• Государственные пособия.
• Депозит.

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

Следовательно, сущность имеет следующие атрибуты:

• идентификатор дохода;
• тип дохода;
• частота дохода;
• размер дохода.

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

Сущность «дополнительный доход» имеет следующие атрибуты:

• идентификатор дохода;
• тип дохода;
• размер дохода.

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

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

• идентификатор депозита;
• тип депозита;
• частота начисления;
• размер суммы;
• процент;
• срок, на который взят депозит.

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

• идентификатор персонального дохода;
• идентификатор человека;
• идентификатор дохода.

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

Рассмотрим проектирование информационной системы с точки зрения универсального языка моделирования UML.

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

Рис. 13 «Диаграмма вариантов использования»

Диаграмма развертывания представлена на рис. 14

Рис. 14 «Диаграмма развёртывания»

Т.к. каждое отношение может быть представлено отдельной таблицей, то с учетом всех известных данных структура БД «Учет личных финансов» состоит из десяти таблиц:

1. Таблица «Человек»;
2. Таблица «Основной доход»;
3. Таблица «Дополнительный доход»;
4. Таблица «Государственные пособия»;
5. Таблица «Депозит»;
6. Таблица «Персональный основной доход»;
7. Таблица «Персональный дополнительный доход»;
8. Таблица «Персональные государственные пособия»;
9. Таблица «Персональный депозит»;
10. Таблица «Расходы».

Рассмотрим более подробно каждую таблицу:

1. Таблица «Человек»

Man

1. Таблица «Основной доход»

Basic_income

3) Таблица «Дополнительный доход»

Additional_income

4) Таблица «Государственные пособия»

State_grants