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

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

Диаграмма (см. рис. 3) содержит возврат, означающий не но­вое сообще­ние, а возврат из сообщения. На диаграмме возврат отли­чается от обычных со­общений тем, что его стрелка не сплошная, а имеет вид пары линий.

Диаграммы последовательности можно также использовать для представ­ления параллельных процессов.

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

рис.4 Параллельные процессы и активизации

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

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

• создавать новую ветвь процесса (в этом случае оно связано с самой верх­ней частью активизации);

• создавать новый объект;

• устанавливать связь с уже выполняющейся ветвью процесса.

Удаление объекта показано с помощью большого знака "X". Объекты мо­гут выполнить самоуничтожение или могут быть унич­тожены посредством еще одного сообщения.

Используя механизм активизации, можно более четко показать смысл само делегирования. Без них, или без такого обозначения с помощью столбиков, ко­торое здесь используется, довольно трудно определить, где же выполняются следующие после само делегирования вызовы — то ли в вызывающем методе, то ли в вызываемом методе. Активизации вносят ясность в этот вопрос.

Глава III ПРИМЕР ИСПОЛЬЗОВАНИЯ ОБЪЕКТНО-ОРИЕНТИРО­ВАННОГО ПОДХОДА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение.

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

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

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

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

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

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

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

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

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