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

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

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

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

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

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

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

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

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

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

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

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

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

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

• связь "расширение" надлежит использовать при отображенье конфигураций в нор­мальном поведении системы;

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

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

Глава II ДИАГРАММЫ

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

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

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

•подтипы(частный клиент является типом клиент

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

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

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

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

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

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

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

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

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

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

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

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

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

Любая связь обладает 2-мя ролями; любая роль представляет со­бой направленность связи. Таковым образом, связь меж Клиентом и Заявкой охватывает 2 роли: 1 от Клиента к Заявке, иная - от Заявки к Кли­енту.

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

2.2 ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

(self-delegation) — сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

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