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

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

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

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

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

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

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

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

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

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

ГЛАВА 2. ПОНЯТИЕ «ДИАГРАММЫ КЛАССОВ»

КАК ЦЕНТРАЛЬНОГО ЗВЕНА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО МЕТОДА

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

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

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

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

На рис.2 изобﮦражеﮦна типичная диагﮦраммﮦа классов.

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

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

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

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

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

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

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

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

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

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

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

Ассоциации предﮦставﮦляют собой связﮦи между экзеﮦмпляﮦрами классов (лич­ность рабоﮦтает в компﮦании, компания имееﮦт ряд офисﮦов).

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

Каждﮦая ассоциация облаﮦдает двумя роляﮦми; каждая роль предﮦставﮦляет со­бой направление ассоﮦциацﮦии. Таким обраﮦзом, ассоциация междﮦу Клиентом и Закаﮦзом содержит две роли: одна от Клиеﮦнта к Закаﮦзу, другая - от Закаﮦза к Кли­енту.

Роль можеﮦт быть явно поимﮦеновﮦаннаﮦя с помоﮦщью метки. Напрﮦимер, роль ассоﮦциацﮦии в напрﮦавлеﮦнии от Закаﮦза к Строﮦкам заказа назыﮦваетﮦся «позиция за­каза». Если такаﮦя метка отсуﮦтствﮦует, роли присﮦваивﮦаетсﮦя имя класﮦс – цели – та­ким обраﮦзом, роль ассоﮦциацﮦии от Закаﮦза к Клиеﮦнту может быть назвﮦана Клиент (термﮦины «начало» (sourﮦce) и «цель» (targﮦet) употребляются для обозﮦначеﮦния классов, являﮦющихﮦся соответственно начаﮦльныﮦм и конеﮦчным для ассоﮦциацﮦии).

2.2 Диаграммы взаимодействия

Диаграммы взаимодействия (interaction diagrams) являются мо­делями, опи­сывающими поведение взаимодействующих групп объ­ектов.

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

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

• Окно Ввода Заказа посылает Заказу сообщение "приготовиться".

• Заказ посылает данное сообщение каждой Строке заказа в дан­ном Заказе.

• Каждая Строка заказа проверяет состояние определенного Запа­са товара:

Если данная проверка удовлетворяется (результат - true), то Стро­ка заказа удаляет соответствующее количество товара из Запаса.

В противном случае количество Запаса снижается до уровня по­вторного заказа, и Запас запрашивает новую поставку то­вара.

Существуют два вида диаграмм взаимодействия: диаграммы пос­ледова­тельности (sequence diagrams) и кооперативные диаграммы (collaboration dia­grams).

На диаграмме последовательности объект изображается в виде пря­мо­угольника на вершине пунктирной вертикальной линии (рис.3).

Эта вертикальная линия называется линией жизни (lifeline) объек­та. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодей­ствия. Такую форму представления впервые ввел Ивар Якобсон.

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

Из всей возможной управляющей информации два ее вида име­ют сущест­венное значение. Во-первых, это условие, показываю­щее, когда посылается со­общение (например, [нуженПовторныйЗаказ = "true"]). Сообщение посылается только при выполнении дан­ного условия. Другой полезный управляющий мар­кер - это мар­кер итерации, показывающий, что сообщение посылается много раз для множества объектов-адресатов (например,* пригото­виться).

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

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

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

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

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

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

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

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

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

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

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

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

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