Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML).pdf

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

Буч отмечает также ряд следующих преимуществ объект­но-ориентированного подхода:

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

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

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

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

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

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

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

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

1.3. ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ

В течение достаточно длительного периода времени в процессе как объектно-ориентированного, так и традиционного структурного про­ектирования разработчики использовали типичные сценарии, помога­ющие лучше понять требования к системе. Эти сценарии трактовались весьма неформально - они почти всегда использовались и крайне ред­ко документировались. И вар Якоб­сон впервые ввел понятие "вариант использования" (use case) и придал ему та­кую значимость, что он пре­вратился в основной элемент разработки и планиро­вания проекта.

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

Когда Якобсон в 1994 г. предложил варианты использования в качестве основных элементов процесса разработки программного обеспечения, он также предложил применять для их наглядного представления диаграммы вариантов использования. На рис.1 показаны некоторые вариан­ты использования для системы торговой ор­ганизации; человеческие фигурки здесь обозначают действующих лиц, овалы - варианты использования, а линии и стрелки — различные связи между дейст­вующими лицами и вариантами использования.

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

Действующее лицо (actor) — это роль, которую пользователь играет по отношению к системе. На рис.1 четыре действующих лица: Менеджер по продажам, Оптовый торговец, Продавец и Система учета. Действующие лица пред­ставляют собой роли, а не конкрет­ных людей или наименования работ. Не­смотря на то, что на диаг­раммах вариантов использования они изображаются в виде стилизо­ванных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы (например, Система учета). Показывать на диаграм­ме действующих лиц системы следует только в том случае, когда им действительно необходимы некоторые варианты использования.

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

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

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

В дополнение к связям между действующими лицами и вариантами использования существуют два других типа взаимоотношений (см. рис.1): "исполь­зование" (uses) и "расширение" (extends) между вариантами использова­ния. Связь типа "расширение" применяется тогда, когда один вариант использования подобен другому, но несет несколько большую нагрузку.

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

Выбор применяемой связи определяется следующими обязательными правилами:

• связь "расширение" следует применять при описании изменений в нормальном поведении системы;

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

Различные разработчики подходят к описанию всех возможных исходов использования с разной степенью детализации. Например, Ивар Якобсон утверждает, что для проекта с трудоемкостью в 10 человеко-лет количе­ство исходов использова­ния может составлять около 20 (не считая взаимоотношений "использование" и "расшире­ние"). Следует предпочитать неболь­шие и детализированные исходы исполь­зования, поскольку они облегчают составление и реализацию согласованного плана проекта.

Глава 2. ДИАГРАММЫ

2.1. Диаграммы классов

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

• ассоциации (например, клиентская служба может сделать заказ);

• подтипы (частный клиентская службы является разновидностью клиента).

Рис. 2 Диаграмма классов

На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между объектами.

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

Построение диаграмм классов можно рассматривать в различных аспектах:

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

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

• аспект реализации - модель действительно определяет реали­зацию классов программного обеспечения. Этот аспект наиболее важен для програм­мистов.

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

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

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