maran program engineering (Маран Программная инженерия), страница 9

3.25 приведена кооперативная диаграмма, соответствующая приведенной на рис. 3.23 диаграмме последовательностей.Объект_1 :Класс1Объект_3 :Класс_21:2:3:Объект24:Рис. 3.24На этой диаграмме показаны три объекта, принадлежность к классу одного из них (Объект2) не установлена. Наличие сплошной линии между объектами показывает, что между ними могут передаваться сообщения. Сами сообщения показаны рядом с линиями. Цифры у сообщений показывают очередностьих возникновения. Рядом с сообщениями может быть указан метод класса адресата.

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

Замена одного компонента на другой с таким же интерфейсом и функционалом не должна влиять на работу системы в целом. Естьтермин «компонентно-ориентированная разработка»: использование в новойразработке созданных ранее компонентов с целью снижения затрат при создании нового программного средства.46Рис. 3.25На рис.

3.26 показана диаграмма компонентов. Все классы должны содержаться в компонентах. Другими словами, компоненты состоят из классов.«компонент»Component1Рис. 3.263.9. Диаграмма развертыванияВ наше время редко когда разрабатывается приложение, функционирующее на одном компьютере. Поэтому возникает необходимость показать, какиекомпоненты на каких компьютерах работают и как эти компьютеры связаны.Для этого служит диаграмма развертывания.

В версии UML 2.5 имеется возможность показать разные типы узлов сети и связей между ними. Проектирование сетей — это самостоятельная интересная задача. При проектировании программного обеспечения необходимо учитывать и многие особенности функционирования сетей. Например, можем ли мы рассчитывать, что компьютерысвязаны между собой всегда, или должны предусмотреть и их автономную работу. Обсуждение этой проблематики выходит за рамки данного пособия.473.10. Язык OCLПри объектно-ориентированном анализе и проектировании рассмотренных выше средств (разные диаграммы) недостаточно для построения точных инепротиворечивых моделей сложных систем. Часто необходимо определитьдополнительные условия на компоненты диаграммы.

Традиционно для этогоиспользовали естественный язык, но такие описания страдают неоднозначностью и нечеткостью.Для адекватного отражения семантики основных процессов в анализируемой предметной области был разработан язык OCL [8]. OCL является языком формальных выражений, которые используются для записи отдельных ограничений. Этот язык дополняет составленные на UML графические модели.Выражения на OCL никогда не могут изменять значения атрибутов и состояниесистемы, они могут только учитываться при осуществлении таких изменений.Язык OCL не является традиционным языком программирования: в немнет средств для записи алгоритмов решаемых задач.

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

В модели выражения используются для записи некоторых условий, которым должны удовлетворять всеобъекты некоторого класса. В таком случае выражение называется инвариантом. Выражения также могут задавать пред- и постусловия операций. Ограничимся рассмотрением на примерах применения OCL для написания пред- и постусловий операций и инвариантов классов.1. x1.max(x2)--нахождение максимумаpost: if x1>=x2 then result=x1 else result =x2 endif2. x.floor()-- нахождение наибольшего целогоpost: result<=x1 and (result+1)>x3.

i1.div(i2)-- целочисленное делениеpre: i2<>0post: if i1/i2 >= 0 then result = (i1/i2).floor()else result = -(i1/i2).floor()endif48pre: задает предусловие, т. е. условие, которое должно быть выполненоперед операцией, в противном случае операция не может быть выполнена (неопределена);post: задает постусловие, которое выполняется после операции.Примечание. В предусловиях и постусловиях не задают условия на типыданных, для которых определена данная операция, или принадлежность результата к типу. В примере 1 тип данных несущественный; в примере 2: х долженбыть вещественным числом, результат будет целым; в примере 3: х1 и х2 должны быть целыми, результат тоже будет целый.Рассмотрим использование инвариантов класса.

Инвариант — это условие, которое должно выполняться всегда, за исключением времени внесенияизменений. Для каждого инварианта необходимо задать контекст. Пусть заданкласс, представленный на рис. 3.27.СотрудникФамилияИмяВозрастСтаж_в_фирмеОбщ ий_стажДата_рожденияИзменить_возраст ()Рис. 3.27Для задания контекста используем выражение:context Сотрудник invself.Общий_стаж >= self.Стаж_в_фирмеself.Общий_стаж <= self.Возраст — 16self.Общий_стаж >= 0self.Возраст >= 16Служебное слово self означает ссылку на текущий контекст (в данномслучае Сотрудник), а слово inv означает инвариант.

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

Очевидно, что инварианты класса являются постусловиями всех егоопераций.494. Выполнение этапов анализаи проектирования на языке UML4.1. Основные положенияВ предыдущих главах были рассмотрены средства для выполнения анализа и проектирования программного обеспечения. В этой главе будет рассмотрена методика использования этих средств, точнее, будет рассмотрен унифицированный процесс разработки программного обеспечения (The Unified SoftwareDevelopment Process) согласно [8].

Фундаментальные принципы унифицированного процесса (в дальнейшем УП) заключаются в следующих утверждениях:• УП управляется вариантами использования;• УП является архитектурно-ориентированным;• УП является итеративным и инкрементным.Рассмотрим эти утверждения подробнее.Любой программный продукт создается для обслуживания пользователей. Очевидно, для его построения мы должны знать, в чем нуждаются потенциальные пользователи. Понятие пользователь — это необязательно человек;это может быть и техническое устройство, для управления которым создаетсяновая программа, или другой программный продукт, с которым новой программе предстоит взаимодействовать.

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

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