Реферат: Объектно-ориентированный подход к проектированию программного обеспечения на примере работы налоговой инспекции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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