Анализ : ООА - анализ пространства

Объект-ориентированный анализ. Статические модели

Введение

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

ООА содержит два основных раздела:

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

• Динамические (поведенческие) модели - модели, предназначенные для описания изменения предметов с течением времени и их взаимодействия между собой.

Если мы рассматриваем ООА как инструмент, дополняющий анализ процессов, то:

• Статические модели позволяют выявить и описать владельца, ценность, материалы, инструменты и управление процесса.

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

Объекты и классы

Объекты, свойства, значения

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

Отсюда основное ограничение применимости - OOA возможно только тогда, когда можно отделить предмет анализа от окружающего мира. Все что можно отделить от окружающего пространства называется объектом.

Пример: Что бы указать на доску в классе - достаточно ткнуть в неё пальцем. Убедиться, что доска может быть отделена от окружающего пространства - мы можем сказать вот тут еще доска, а вот тут уже не доска. Ткнуть пальцем в предмет, расположенный в соседнем кабинете уже не получится, ни автор, ни получатели его не видят.

Что бы получатель мог идентифицировать предмет самостоятельно - надо передать ему какие-то характеристики. Эти характеристики должны быть наблюдаемыми. Если получатель не способен их пронаблюдать - значит не может ими воспользоваться. Во-вторых, эти характеристики должны быть измеримыми. Это значит, что результат наблюдений можно выразить в формальных единицах, и сравнить с переданным шаблоном. Инструмент для измерения должен быть доступен обоим сторонами - и автору и получателю информации. Каждая такая характеристика (наблюдаемая и измеримая) называется свойством (property). Конкретные значения для измерений называются значениями (values).

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

Инструмент должен давать объективные измерения. Оговорка: Личное мнение может быть объективным измерением, при условии, что и автор и получатель информации могут обратиться к тому же самому человеку и получить тот же ответ, на тот же самый вопрос. Т.е. такой человек выступает как инструмент для измерения. Это не практично и не удобно, но технически возможно.

Пример: Доска не может быть красивой в абсолютном смысле. Каждый имеет своё представление о красоте. В то же время, если мы выберем одного человека, и он будет отвечать на этот вопрос и автору и получателю информации - измерение становится объективным, хотя и не удобным инструментом - человеком. Вывод - когда есть необходимости вводить субъективные измерения - четко должен быть указан источник - конкретный человек. Впрочем, таких характеристик следует избегать.

Получив набор измерений и шаблон значений, получатель информации может идентифицировать предмет.

Методы

Сама по себе идентификация не несет в себе большой ценности для получателя. Объект идентифицируется не просто так, а для того, что бы его использовать. То, как можно использовать объект называется методом. Очень важно не путать метод с поведением объекта. Метод - это то, как мы можем применить объект для получения какой-то пользы. Поведение - это то, что объект может делать (или с объектом можно сделать).

Пример с доской: Как мы можем применить доску? Правильные ответ - доска может сохранять информацию написанную на ней маркером. В то же время "писать" не является методом доски - это метод человека который пишет на ней.

Еще пример: Аналогично, пилить дерево - не метод пилы. Это метод плотника. Он использует пилу в этом процессе, но обращаемся мы к все-таки к плотнику, а не к пиле. Везти - метод водителя, а не автомобиля.

Классы

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

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

Пример: Доска вообще - это класс. Конкретная доска в которую мы можем ткнуть пальцем - это объект.

Важно помнить - хотя объяснения как воспользоваться предметом делаются в терминах классов (пример: возьмите любой карандаш), непосредственно действия производятся конкретным объектом (пример: вот этим карандашом).

Запись класса в UML

Класс в UML изображается в виде прямоугольника разделенного на три части горизонтальными линиями.

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

В средней части перечисляются свойства класса. Свойства класса записываются в виде: название : способ измерения

В нижней части перечисляются методы класса. Методы класса записываются в виде название (перечень используемых объектов (их классы)) : создаваемый объект (если создается)

Пример:

Границы анализа

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

Пример: Нельзя анализировать доску вообще. Доска с точки зрения её производителя, с точки зрения транспортной компании, с точки зрения магазина и с точки зрения школы - абсолютно разные вещи. Более того, даже в контексте школы доска с точки зрения уборщика и с точки зрения лектора тоже разные вещи. Таким образом, доску можно эффективно описать только в контексте школы (ограничение пространства) и с точки зрения лектора (ограничение использования).

Отношения

Что такое отношение?

Объекты не существуют в анализируемой модели сами по себе. Они связаны между собой. Для описания этих связей, язык OOA предлагает четыре вида горизонтальных отношений (отношений между разнородными объектами), различающихся по прочности от слабых (weak) до прочных (strong) и один вид отношений между сходными объектами. Рассмотрим сначала горизонтальные отношения, от слабых к сильным.

Зависимость

Самые слабый вид отношений - зависимость (dependency). Такая зависимость возникает между двумя объектами, которые существуют сами по себе и имеют ценность сами по себе, но один из них знает как или может использовать другой объект.

Примером зависимости является отношение между лектором и доской. Лектор сам по себе имеет ценность, доска сама по себе имеет ценность, но лектор может пользоваться способностью доски хранить информацию в рамках своего поведения (чтения лекций).

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

Вырожденные классы

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

Сущность

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

Для описания таких объектов используется специальный случай классов - сущность (entity). Такие классы не имеют методов, но имеют только свойства. По сути, их метод использования заключается в том, что эти свойства можно менять.

Для отображения сущностей на диаграмме используется класс с незаполненным блоком методов и стереотипом entity (стереотип, как мы помним, указывает на способ использования элемента языка UML).

Интерфейс

Так же, при описании реальных процессов не всегда важен конкретный способ которым можно достигнуть нужного результата. Например, когда мы хотим поговорить с человеком, который не рядом с нами - мы можем ему позвонить, причем конкретный способ реализации - проводной телефон, сотовый телефон, skype - для нас не важен, важен только достигнутый результат. Т.е. мы имеем дело не с реальный объектом, а с соглашением об использовании, которому могут соответствовать различные реальные объекты. Еще одним примером является профессия. Объектом в данном случае является человек - а вот его профессия - повар, программист, писатель - это способ использования данного объекта.

Для отображения сущностей на диаграмме используется класс с незаполненным блоком свойств и стереотипом interface.

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

Ассоциация

Когда мы рассматривали сущность Счет, мы использовали в качестве примера Кассира, а не Клиента, потому что отношения зависимости между клиентом и счетом не применимы. Проверим: является ли клиент банка клиентом без счета? Нет. Правило что “участника отношения "зависимость" имеют смысл сами по себе” – нарушено.

Для описания отношений, при которых каждый объект может существовать сам по себе, но как минимум один из них не имеет смысла без второго или попадает в границы анализа только в связи со вторым объектом - используется отношение ассоциации (association). Ассоциация отображается в виде сплошной линии. Со стороны каждого из объектов могут быть указаны:

Над линией - роль объекта в ассоциации. Роль - это, чаще всего, соглашение об использовании объекта в рамках ассоциации.

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

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

Если количество объектов может быть различным - то множественность задается в виде: минимальное количество..максимальное количество.

Например:

• 1..5 - от одного до пяти

• 0..2 - не больше двух, может быть ни одного

• 0..* - сколько угодно, включая "ни одного" (может быть записано как просто *)

• 1..* - сколько угодно, но хотя бы один объект должен быть.

В случае если только один из объектов "знает как" использовать другой, то ассоциация является направленной. Направленность ассоциации указывается при помощи стрелочки направленной на объект который используют.

Агрегация и композиция

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

Если разрыв отношений приводит к разрушению "целого" - то это отношение называется композицией. Например отношение человек - мозг это композиция. Если мы убираем мозг - человек умирает и перестает существовать как объект.

Агрегация и композиция отображаются в виде сплошной линии с ромбом со стороны "целого". В случае агрегации ромб не закрашен, а случае композиции ромб закрашен. Как правило, ни роль ("целое"), ни множественность (1) со стороны целого не указываются. Роль со стороны частей может быть указана если важно подчеркнуть поведение в рамках которого целое пользуется частью. Множественность указывается всегда.

Композиция является самым прочным отношением.

Обобщение

Обобщение (generalization) позволяет связать подобные объекты. Обобщение всегда проводится от частного к общему и всегда проводится по способу использования для достижения одинаковых целей.

Простейшим примером обобщения является отношение между интерфейсом и конкретным предметом. "Средство голосовой связи" является обобщением для классов "Проводной телефон", "Сотовый телефон" и "Skype".

Обобщение отображается в виде треугольной стрелочки направленной от частного к общему.

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

Однако, обобщения могут быть применены не только в случае интерфейсов. Например, доска, тетрадь и iPad с точки зрения ведения лекции могут быть обобщены как "средство ведения записей" (это пример с сущностью). С точки зрения лечения переломов - для врача нет разницы между мужчиной, женщиной и ребенком (если не затрагивать специфические переломы). Достаточно ввести обобщение "человек" (это пример с полноценным классом - обладающим как свойствами, так и методами).

Пример неправильного применения обобщения: Допустим в ходе анализа мы обнаружили сходное поведение у бухгалтера, директора и дворника. Все они используют штамп для того что бы ставить печать. Если мы опустим правило "для сходных результатов" и введем обобщение "тот, кто ставит печать" – и соответственно опишем это поведение только для такой искусственной сущности - то, даже если в начале наша модель будет правильно - то при изменении поведения одной из сущностей нам может повезти, и мы вспомним об обобщении - и тогда нам придется делать лишнюю работу для разделения общей сущности назад, или не повезет - и изменение будет сделано в общей сущности, поменяв поведение всех остальных. Например, изначально все ставили круглый штамп. Но потом у дворника штамп которым он двери опечатывает стал треугольными. Если мы поменяем поведение общей сущности - поведение поменяется и у директора и у бухгалтера - и наша модель перестанет описывать действительность правильно. Дополнительная проблема заключается в том, что обычно будет проверена только модель дворника, а остальные даже не будут проверяться - их-то менять не просили.

Абстрактные классы

Введение отношения обобщения приводит к появлению абстрактных классов. Абстрактный класс - это такой класс, для которого нельзя создать объект. Например, нет объекта просто "Человек". Есть объект Мужчина или Женщина.

Абстрактные классы помечаются стереотипом abstract. Желательно так же, для методов, поведение которых значительно различается в частных классах указывать их как виртуальные. Например для абстрактного класса "человек" поведение в случае "есть" будет одинаковым, а поведение в случае "поиск партнера" будет разным. Виртуальность показывается отображением свойства или метода курсивом:

Влияние границ анализа на поиск отношений

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

Использование отношений для декомпозиции

Помимо полноты и отсутствия избыточности при передаче информации, хороший анализ должен быть понятным получателю. Свойства человеческого мозга ограничивают сложность одной воспринимаемой целиком системы 5±2 объектами и не более чем тремя связями с каждым объектом. Большинство реальных систем содержат большее количество объектов и связей между ними. Для упрощения процесса написания (впрочем, как и анализа) используются следующие приемы:

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

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

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

Более того, в рамках описываемой на этом уровне системы - нам, к примеру, не важно устройство кассовой машины. Мы можем ввести её как отдельный объект, а далее, по необходимости - провести дальнейший анализ (разбор на составные части но уже в рамках только кассового аппарата и его использования).

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

Такие процессы разделения сложного на простые элементы называются декомпозицией.

Совместное применение OOA и анализа процессов

Задача аналитика описывать мир как он есть. Аналитик не должен думать, не должен делать предположений, какими бы логичными они не казались и как бы ему не казалось что он где-то это уже видел.

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

1) Аналитик последовательно отвечает на три вопроса: "что?", "зачем?" и "как?". Первый вопрос - это вопрос идентификации. Наблюдая мир аналитик обнаруживает объект и описывает их (см. объекты и классы) - как набор наблюдаемые и измеримых свойств при помощи которых объект можно надежно идентифицировать. Второй вопрос - аналитик определяется с какой целью объект присутствует в наблюдаемом мире. Ответ на этот вопрос называет ответственностью (responsibility) объекта. Ответ на вопрос "как" - это методы объекта - каким образом можно воспользоваться объектом в рамках его ответственности. Те же вопросы применимы и к действиям. Сначала аналитик наблюдает действие и определяет его границы - когда начинается и когда заканчивается (включая наблюдаемые и измеримые критерии начала и конца действия), выясняет зачем выполняется этой действие. Обратите внимание что критерии конца действия - это еще не ответ на вопрос зачем. Например процесс готовки заканчивается измерением характеристик блюда, которые указывают на готовность, но это не отвечает на вопрос зачем варили. А варить могли что бы продать, или что бы накормить семью. И дальше уже рассматривается "как".

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

2) Второй шаблон работы применяется к анализу процессов. При наблюдении процесса всегда присутствуют как минимум два объекта - один объект называется контроллер - это человек или объект непосредственно выполняющий действия и получающий приказ на их выполнение. Шаги процесса - это методы этого объекта, действия в рамках процесса - поведение этого объекта. Практически всегда при совершении действий контроллер использует другие объекты в своем поведении - такие объекты, если у них нет своего поведения называются сущностями. Сущности, как правило, - это следствие формализации человеческой деятельности. Примерами сущностей являются банковский счет, бухгалтерская книга, отчет, правило, регуляция, закон. Если объект обладает собственным поведением - то это уже не сущность, а инструмент. Иногда в процессе участвуют инструменты которые явно выходят за границы процесса. Например кассир в магазине может использовать карточный терминал, поведение которого по большей части происходит в банке, который явно находится вне границ магазина. Такие инструменты называются boundaries (не путать с borders - границами анализа). Для них мы определяем только интерфейс использования и никогда в рамках анализа не занимаемся исследованием поведения.

Boundaries всегда указывают на точки соприкосновения различных процессов, и чаще всего результат деятельности boundary будет ценностью процесса, происходящего внутри boundary.

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