Домой |
Ссылки ]
Edited
by
Перевод
Метод
OOSE
(Object-Oriented Software Engineering) -
это систематизированный метод промышленной разработки
программного обеспечения
(ПО),
разработанный
Подход OOSE распознает три различных вида объектов, отделяющих управление и координацию сценариев использования системы от интерфейса и от сущностей, составляющих прикладные понятия. Путём отделения друг от друга внешнего поведения, внутренней структуры и динамики, каждое из них можно изменять и расширять независимо от остальных. Как и остальные методы, OOSE включает понятия прикладных и системных сущностей, но в отличие от большинства методов не ограничивает всю разработку жёсткими рамками только этих разновидностей объектов. В результате получается более прочная модель приложения: ПО в своей основе более приспособлено к изменению и расширению, а его компоненты могут быть повторно использованы в процессе разработки.
Метод делит всю разработку на процессы или действия, которые в отличие от традиционных фаз разработки, могут повторяться и перекрываться. Эти действия вырабатывают последовательность тесно связанных моделей, что облегчает неразрывность разработки через последовательное моделирование и высокую степень следования требованиям. Используя этот подход, можно через последовательность стадий создавать очень большие и сложные системы на основе независимого анализа отдельных видов использования. Сила этого метода, следовательно, возрастает с увеличением размера разрабатываемой системы.
Все системы меняются в течение своего цикла жизни. Это нужно учитывать при разработке систем, которые предполагают существование более чем одной версии, что относится практически ко всем системам. Большинство методов разработки. сегодня концентрируются на новой разработке (см. рис. 1),. лишь кратко рассматривая работу по ревизии, хотя известно,. что изменения составляют самую большую часть общего цикла жизни большинства систем. Истинно промышленный процесс, следовательно, должен концентрироваться на изменениях системы. Система обычно разрабатывается через изменения в некотором числе версий, как показано на этом рисунке. Новая разработка с этой точки зрения - только лишь особый случай первой версии. Новая разработка,. тем не менее,. важное действие. Она устанавливает. архитектурную. философию и составляет основу системы, которая должна сохраняться в течение всей последующей разработки.. Ошибочная основа будет иметь серьёзные последствия. для цикла жизни системы.
Рис. 1. Первая версия системы
представляет лишь малую часть затрат
всех ресурсов разработки
В разработке, управляемой видами использования, мы фокусируем внимание на изменениях в конкретном продукте. Таким образом, подход описывает, как одна версия должна быть изменена в следующей версии. Уникальное свойство этой модели цикла жизни то, что здесь нет специальной фазы сопровождения. Все действия в течение цикла жизни фактически суть изменения конкретной модели.
Вместо фокусирования внимания на том, как нужно управлять отдельным проектом, мы фокусируем внимание на том, как нужно разрабатывать некоторый продукт (готовое приложение) и как сопровождать его в течение всего цикла жизни. Это означает, что вместо общепринятого каскадного описания, мы разделяем разработку продукта на процессы, каждый из которых описывает одно действие по управлению продуктом. Процессы работают в сильно взаимодействующей манере. Каждый процесс управляет отдельной фазой или действием разработки системы. Например, большинство типов проектов будут включать некоторые проектные действия. Таким образом, продукт будет управляться некоторым числом процессов. Разработка затем расширяется на все такие процессы и они существуют в течение всего цикла жизни системы. Вся разработка, следовательно, управляется этими процессами и каждый процесс может, в свою очередь, состоять из некоторого числа взаимодействующих процессов.
Проект разработки системы, следовательно, выполняется некоторым числом действий, каждое из которых состоит из более детальной и конкретной разработки предыдущих шагов. Поэтому, разработка системы - это постепенная трансформация различных моделей разрабатываемой системы. Первая модель описывает требования заказчика, а последняя является полностью оттестированной программой. Между этими крайними точками располагаются несколько других моделей.
Итак, цикл жизни разработки строится из различных процессов, которые кооперируются для преобразования продукта из одной версии в другую путём изменения различных моделей. Главные процессы суть анализ, конструирование и тестирование. Они описывают действия, которые выполняются при разработке продукта и которые "существуют" в течение всего цикла жизни продукта. Когда требуется новая версия продукта, . эти процессы активизируются группой разработчиков (см. рис. 2).
Рис. 2. Процессы взаимодействуют при разработке новой версии системы.
В процессе анализа мы создаём концептуальную картину системы, которую хотим построить. Здесь разрабатываются различные модели с целью достичь понимания системы, а также для обратной связи наиболее существенных аспектов системы с заказчиком и с процессом конструирования. В процессе конструирования мы разрабатываем систему из модулей, созданных во время анализа. Сюда входят проектирование и реализация, а в результате получается полная система. Процесс тестирования объединяет систему, проверяет и решает, следует ли передавать её на поставку. Процесс комплектования, связанный главным образом с процессом конструирования, разрабатывает и сопровождает повторно использованные компоненты - полностью реализованные конструктивные части, которые могут быть использованы в нескольких приложениях, главным образом во время конструирования. Процесс комплектования не привязан к конкретному продукту, это "многопродуктный" процесс. Мы не будем далее обсуждать процесс комплектования.
То, что требования к информационной системе, как и к технической системе, полностью не известны в начале проекта - скорее правило, чем исключение. Знания системы растут по мере продвижения работы. Когда начинает действовать первая версия системы, появляются новые требования, а старые изменяются. Таким образом, система не может быть полностью разработана в предположении, что спецификация требований остаётся неизменной в течение разработки, что для больших систем занимает несколько лет.
Во многих случаях лучше разрабатывать систему шаг за шагом, начиная с нескольких её основных функций. Как только станет ясен подходящий путь и придёт лучшее понимание того, как должна развиваться система, можно добавить новые функции. Таким образом, наращивание идёт постепенно до тех пор, пока не будет готов окончательный продукт, обычно ко времени выпуска продукта. Такая пошаговая стратегия также обеспечивает наиболее быструю обратную связь в течение процесса разработки. На практике, пошаговая разработка системы означает, что мы можем разбить систему на части, соответствующие обслуживающим запросам заказчика. Каждая новая стадия расширяет систему новой функцией до тех пор, пока окончательный продукт не будет включать в себя всю требуемую систему. Все последовательные выпуски системы также разрабатываются пошаговым образом. Чтобы последовательная разработка была успешной, существенно, чтобы поздние стадии не вызывали изменения результатов ранних стадий. Поэтому важно понять требования, формирующие основу всей системы, как можно раньше. Каждая стадия разрабатывается в цикле и тестируется перед тем как будет завершена. Это означает, что процессы протекают несколько раз для каждой версии системы.
Цель процесса анализа - проанализировать, определить и описать систему, которая должна быть построена. Разрабатываемые модели будут описывать что должна делать система. Основа моделирования - требования заказчика или конечного пользователя к системе, выраженные в некоторой форме. Поэтому важно провести диалог с клиентами и предполагаемыми пользователями, чтобы убедиться в том, что строящаяся система именно та, которая требуется. На фазе анализа мы строим модели, которые облегчат нам понимание системы.
Разрабатываемые в процессе анализа модели полностью ориентированы на приложения, а не на среду реализации. Это "существенные" модели, которые не зависят от операционной системы, языка программирования, СУБД, распределения процессов, конфигурации аппаратуры. Это и будет нашим определением анализа: моделирование системы без учёта реальной среды реализации. Цель состоит в том, чтобы сформулировать проблему и построить модели, которые могут решить её при идеальных условиях. Поскольку модели целиком проблемно-ориентированы и не уделяется никакого внимания реальной среде реализации, эти модели довольно просто могут быть разработаны от постановки задачи до их функционирования. Мы, следовательно, можем сконцентрироваться целиком на проблеме как таковой и отбросить на первом этапе технические детали. Модели, основанные на проблемно-ориентированных понятиях, можно обсуждать с пользователями без употребления реализационных терминов.
В конечном счёте, система должна быть адаптирована к среде реализации: это делается на этапе конструирования. Тот факт, что во время анализа среде реализации не посвящается много внимания, гарантирует, что результирующая архитектура системы будет основана на самой проблеме без влияния условий, превалирующих на этапе реализации. Конечно, невозможно разрабатывать систему полностью без учёта реализации, поскольку модели и их архитектура должны быть реализуемы. Другое большое преимущество этой процедуры то, что модели анализа могут оставаться нетронутыми и применимыми, если и когда условия реализации меняются.
На этапе анализа разрабатываются две различных модели: модель требований и модель анализа. Они основаны на спецификациях требований и дискуссиях с будущими пользователями системы. Первая, модель требований, должна определить границы системы и те действия, что происходят внутри системы. Для этой цели мы разрабатываем концептуальную картину системы, используя объекты проблемной области, а также описания специального интерфейса, если это важно для системы.
Кроме того, мы описываем систему как набор "видов использования", которые выполняются некоторым числом "актёров". Актёры составляют среду использования системы, а виды использования - это то, что происходит внутри системы. Вид использования - одно из уникальных понятий методологии OOSE.
Модель анализа - архитектурная модель, используемая для анализа целостности системы. Она даёт концептуальную конфигурацию системы, состоящую из различных классов объектов: активных контроллеров, проблемных сущностей, интерфейсных объектов. Цель этой модели - найти прочную и расширяемую структуру для системы как основу для конструирования. Каждый тип объекта имеет специальную цель для такой прочности: вместе они составят общую функциональность, которая была определена в модели требований. Для управления разработкой модель анализа может группировать объекты в подсистемы.
Модель анализа состоит из общей функциональной спецификации разрабатываемой системы, без учёта среды реализации. Модель проектирования, разрабатываемая в процессе конструирования, включает в себя части этой среды, язык реализации, СУБД, и т.п. Модели анализа и проектирования обе суть модели системы, но каждая имеет различную цель. Способность слежения за системой улучшается благодаря тому, что объекты одной модели могут прямо соответствовать объектам другой модели.
Мы конструируем систему на основе моделей анализа и требований, создаваемых в процессе анализа. Процесс конструирования заканчивается тогда, когда завершается кодирование и составные части протестированы.
Процесс тестирования следует за процессом конструирования. Здесь все виды использования системы тестируются и проверяются на правильность. Это не означает, что мы должны ждать перед началом сертификации системы, когда все части будут сконструированы. Вместо этого мы пытаемся сделать как можно больше параллельно. Мы даже пытаемся начать конструирование до того, как будет завершена фаза анализа.
Какова же цель процесса конструирования? Разве нельзя написать текст программы прямо из модели анализа, которая уже описывает и объекты системы, и как они относятся друг к другу? Есть три главные причины необходимости процесса конструирования.
Конструирование делится на две фазы: проектирование и реализацию, каждая из которых разрабатывает модель. Модель проектирования - дальнейшее уточнение и формализация модели анализа, в которой учитывается влияние среды реализации. Модель реализации - фактическая реализация системы.
Тестирование доказывает, что построена правильная система. Тестирование традиционно дорого, в основном из-за того, что много ошибок не может быть обнаружено, пока не будет достигнут конец разработки. Систематический и хорошо организованный подход к разработке системы по необходимости должен повышать качество системы и уменьшать стоимость тестирования. Чтобы тестирование было эффективным, стремятся к тому, чтобы каждый тест обнаруживал ошибку. Поэтому используют различные типы и методы тестирования. Далее мы сформулируем некоторые ключевые принципы тестирования.
Компонентное тестирование выполняется на специальном компоненте, который может быть разного размера, от класса до целой подсистемы. Первоначально компонент тестируется структурно (т.е. как "белый ящик"). Это означает, что мы используем наши знания о внутреннем устройстве компонента. У нас есть различные критерии покрытия для тестов, минимальный из которых покрывает все операторы текста программы. Однако критерии покрытия бывает трудно определить из-за полиформизма, когда много ветвлений управления в объектно-ориентированных программах происходят неявно. Использование наследования также усложняет тестирование, поскольку нам приходится заново тестировать операции на различных уровнях и иерархии наследования. Тем не менее, полиформизм повышает независимость объектов, делая их легче тестируемыми как отдельные части. Далее, поскольку у нас меньше текста программы, то и тестировать легче.
Тестирование спецификации компонента делается в основном по протоколу объекта (так называемое тестирование "чёрного ящика"). Здесь для нахождения подходящих случаев для тестов мы используем "эквивалентное разбиение". В методологии OOSE тестирование выполняется в течение всей разработки. Даже интегральное тестирование можно начинать на ранних стадиях разработки. Экземпляры различных классов можно объединять непрерывно в течение процесса разработки. Понятие вида использования имеет решающее значение для фактической интеграции, когда объединяется один вид использования за один раз. Планирование тестов должно быть сделано на ранней стадии вместе с идентификацией тестов.
Здесь мы обсудим различные модели, получаемые во время разработки системы сообразно с методологией OOSE.
Модель требований состоит из модели видов использования, описаний интерфейса пользователя и объектной модели проблемной области.
Модель видов использования основывается на актёрах и видах использования (см. рис. 3). Эти понятия помогают определить, что существует вне системы (актёры) и что система должна уметь делать.
Рис. 3. Пример модели вида использования: система управления полётами
Актёры представляют нечто, взаимодействующее с системой, т.е. все, что нуждается в обмене информацией с ней. Акте - не пользователь, а роль, которую пользователь может играть по отношению к системе. Пользователь - это человек (или, иногда, устройство), который использует систему. В отличие от многих других объектов, актёры непредсказуемы в своих действиях.
Мы рассматриваем актёры как классы, а пользователей - как экземпляры этих классов. Такие экземпляры существуют только когда пользователь что-то делает в системе. Один и тот же человек может, следовательно, появится в виде экземпляров нескольких актёров. Например, система может иметь пилотов и пассажиров в качестве актёров. Джим Смит - . пользователь, который иногда действует в роли пилота, иногда - пассажира, выполняя различные виды использования в зависимости от взятой на себя роли.
Каждый актёр может выполнять несколько различных действий с системой и, таким образом, участвовать в операциях системы. Используя систему, актёр выполняет поведенчески определённую последовательность транзакций в диалоге с системой. Такая специальная последовательность - то, что понимается под видом использования. Это особый способ использования системы. Набор видов использования составляет завершённую функциональность системы, которую нужно построить. Каждый вид использования имеет описание и система должна быть способна выполнить всё, что описано в модели видов использования.
Примером вида использования может быть "подтверждение полёта, которое должен сделать пилот". Точно как и в случае с актёрами, мы рассматриваем вид использования как класс. Когда выполняется вид использования, мы рассматриваем это как порождение экземпляра класса. Экземпляр существует, пока действует вид использования. Модель видов использования структурируется различными отношениями между видами использования.
Разработанная вышеуказанным способом модель системы управляется видами использования. Когда мы хотим поменять поведение системы, мы заново моделируем соответствующие актёры и виды использования. Таким образом, вся архитектура системы будет управляться в соответствии с тем, что пользователь хочет сделать с системой. Если мы имеем возможность отслеживать все модели, мы сможем модифицировать систему по новым требованиям. Мы просто спрашиваем пользователей, что они хотят изменить (какой вид использования) и смотрим прямо туда, где эти изменения следует сделать в других моделях.
Модель требований облегчает обсуждение требований и предпочтений с пользователями системы, что даёт уверенность в том, что мы определяем правильную систему. Модель легко понимать и формулировать с точки зрения интересов пользователя. Поскольку это первая из разрабатываемых моделей, мы можем оценить, насколько удобно пользователю то, что мы собираемся проектировать, прежде чем начнётся построение реальной системы. Для поддержки модели видов использования часто бывает полезно разработать модели интерфейсов для видов использования. Прототипы интерфейсов могут имитировать виды использования, показывая пользователям, что они увидят при выполнении отдельных видов использования разрабатываемой системы.
Кроме того, для связи с потенциальными пользователями и для получения стабильной основы для описания видов использования, часто бывает полезна обзорная логическая объектная модель предметной области. Такая модель состоит из объектов, представляющих сущности или конструкции из предметной области, и служит для поддержки разработки модели требований.
Модель требований формулирует спецификацию функциональных требований, основанную на нуждах пользователей системы. В действительности, модель требований эффективно служит как часть спецификации требований и могла бы использоваться для предложений по разработке системы.
Модель видов использования является центральной, управляющей формированием всех остальных моделей. Она разрабатывается в кооперации с объектной моделью предметной области и может быть выражена в терминах объектов этой модели. Функциональность, определяемая видами использования, далее структурируется в логическую, независимую от реализации модель анализа, которая стабильна и устойчива против изменений. Эта модель далее адаптируется к фактической среде разработки и затем уточняется в виде модели проектирования, где виды использования применяются для описания того, как протекают связи между объектами проектирования. Виды использования затем реализуются в виде текста программы. Наконец, виды использования становятся средством тестирования системы, в первую очередь во время интеграционного тестирования.
После того, как модель требований, определяющая границы системы и её внутреннее поведение, разработана и одобрена пользователями (клиентами), фактическая разработка системы начинается с модели анализа. Эта модель определяет логическую структуру системы, независимую от среды реализации.
Хотя для реализации системы можно взять за основу модель предметной области, разработанную при определении модели требований, в большинстве случаев это не даст хороших результатов. Исходя из нашего опыта, модель анализа представляет более стабильную и легче поддерживаемую структуру системы, которая будет далее использоваться в течении всего цикла жизни системы. Поскольку большинство изменений будут идти от среды реализации, они не окажут воздействия на логическую структуру. При обсуждении адаптации к фактической среде реализации мы увидим, что желательно иметь как можно меньше изменений этой идеальной, логической, стабильной структуры.
Многие методы объектно-ориентированного анализа распознают только один основной тип объекта. Применяя три различных вида объектов, мы получаем структуру, более приспосабливаемую к изменениям. Типы объектов, используемые в модели анализа, - сущность, интерфейс и объект управления (см. рис. 4).
Рис. 4. Типы объектов, используемые в модели анализа при структурировании системы
Каждый тип объекта имеет различную цель. Объект-сущность моделирует информацию в системе, которую следует хранить после завершения вида использования системы. Все виды поведения, естественным и тесным образом связанные с этой информацией, помещаются в объект-сущность. Пример сущности - человек с его (её) соответствующими личными данными и поведением. Интерфейсный объект моделирует поведение и информацию, которые зависят от интерфейса системы. Поэтому всё, что относится к интерфейсу с системой, помещают в интерфейсные объекты. Пример интерфейсного объекта - функции интерфейса пользователя при запросе информации о человеке. Объект управления (или, иначе, контроллер) моделирует действие, которое не связано непосредственно ни с каким другим объектом. Обычно это поведение, состоящее из операций над несколькими различными объектами, выполняющее некоторые вычисления и затем возвращающее результат интерфейсному объекту. Пример контроллера - вычисление налогов с использованием нескольких различных факторов. Такое поведение могло бы быть помещено в любой другой тип объектов (поскольку последние также могут моделировать поведение), но в действительности поведение не принадлежит фактически ни одному из объектов.
Поскольку все системы изменяются, стабильность системы заключается в локализации изменений, которые должны затрагивать только один объект. Распределение функциональности системы упорядоченным образом по этим трём типам объектов помогает изолировать изменения. Изменения в любой части интерфейса системы должны воздействовать только на интерфейсные объекты.
Изменения в функциональности могут произойти различными путями. В объектно-ориентированной системе функциональность может быть распределена по всем типам объектов. Однако если изменение включает функциональность, связанную с информацией, хранящейся в системе (например, как вычислять возраст человека), такое изменение обычно будет воздействовать на объект-сущность, представляющий эту информацию. Изменение в функциональности интерфейса (например, как получить и собрать информацию о человеке) должны воздействовать только на соответствующий интерфейсный объект. Изменения в функциональности,.включающие несколько объектов (например, как вычислять налоги по нескольким различным критериям) будут при правильном проектировании локализованы в объекте управления, поскольку такая функциональность, одинаковая для одного или нескольких видов использования, помещается в контроллере. Таким образом, при помощи орех различных типов объектов мы ограничиваем области вероятных изменений.
Очевидно, что наиболее стабильные системы не могут быть построены с использованием только объектов, соответствующих "реальному миру" или сущностям предметной области. Объекты-сущности в нашей модели анализа часто будут очень похожи на модели, разработанные методами, основанными исключительно на таких объектах реального мира. Объекты-сущности часто представляют объекты предметной области, хотя это не всегда необходимо. В других методах, однако, поведение, которое более соответствовало бы объектам управления, обычно можно найти распределённым по нескольким различным объектам (сущностям) или оно включает более сложные межобъектные взаимодействия, что усложняет введение изменений в такое поведение.
Более чем 20-летний опыт разработки объектно-ориентированных систем в области телекоммуникаций привёл нас к следующим заключениям. Анализ изменений, сделанных в этих системах, показал, что часто типичным объектам проблемной области присваивается слишком много функциональности. Когда вносятся изменения, поведение оказывается слишком специализированным, чтобы облегчить повторное использование объектов в новых операциях. Со временем, к такому объекту может быть добавлено большое число ограничений или специальных операций (в одной из систем к одному объекту было добавлено 23 операции, которые оказались уникальными для одного вида использования). Выделение более специализированных функций в объекты управления даёт в результате более общее поведение в объектах-сущностях. Тогда объект-сущность будет содержать функции, более способствующие повторному использованию его в различных, в том числе новых, видах использования, а объект управления будет содержать в себе функции взаимодействия, которые в противном случае могли бы быть рассыпаны по другим объектам.
В процессе конструирования мы строим систему, используя обе модели - анализа и требований. Первоначально мы создаём модель проектирования, которая представляет собой уточнение и формализацию модели анализа. Основная работа в построении модели проектирования состоит в адаптации к среде реализации. Наша цель - уточнить её настолько,.чтобы можно было достаточно просто писать по ней исходный текст программы (что делается в модели реализации). Поскольку модель анализа имеет все свойства, которые мы хотим от системы, эта структура должна формировать основу для модели проектирования. Однако, в модель будут вноситься изменения, когда мы будем вводить, например, систему управления реляционной базой данных, распределённую среду, требования производительности, конкретный язык программирования, параллельные процессы.
Когда же кончается анализ и начинается проектирование? С одной стороны, мы хотим выполнить по-возможности больше работы в модели анализа, где мы можем фокусировать своё внимание на существенном. С другой стороны, мы не хотим делать слишком много того, что нужно будет изменять при адаптации анализа к среде реализации. Что мы действительно хотим - это непрерывно уточнять модели, переключаясь на модель проектирования как только мы увидим первые последствия среды реализации. Поэтому переход от анализа к проектированию должен решаться в зависимости от конкретного приложения. Если не будет проблем адаптации к системе управления базами данных, распределённой среде, требованиям реального времени, параллельным процессам, аппаратному обеспечению и т.п., лучше подойти к модели анализа достаточно формально. Однако если эти обстоятельства будут сильно воздействовать на структуру системы, то переход к проектированию следует сделать раньше. Цель состоит в том, чтобы не переделывать работу на последующей стадии.
Это также ведёт к вопросу о том, когда следует делать изменения в модели анализа при работе над моделью проектирования. Изменение в модели проектирования, которое идёт от изменения логики системы (например, определение того, что два объекта должны быть логически связаны), должно быть включено также в модель анализа. Однако, если изменение - следствие влияния среды реализации (например, определение того что два объекта не должны прямо связываться из-за выбранной структуры процессора), тогда его не следует включать в модель анализа.
Структуры с которыми мы работаем - в основном, те же, что и в модели анализа, но их вид изменяется, поскольку это шаг в сторону реализации. Мы используем понятие блока, когда говорим о проектирование объектов, чтобы представить абстракцию того, как работает исходный текст программы. Один блок обычно реализует один объект анализа. Как и в анализе, могут быть использованы различные типы блоков. Однако блоки - не обязательно те же объекты, что и объекты анализа. В модель проектирования будут внесены изменения. Например, один блок может быть разбит на два для обработки слабо связанных процессов. Такое разбиение не должно воздействовать на модель анализа; поэтому мы не требуем, чтобы две модели были иллюстрациями одной модели.
Другое различие между моделями анализа и проектирования состоит в том, что модель анализа должна рассматриваться как концептуальная, логическая модель системы, в то время как модель проектирования должна подводить нас ближе к фактическому исходному тексту программ. Мы можем рассматривать её как схему программы, которую нужно разработать. Это означает, что мы изменяем вид модели проектирования на абстракцию текста программы, который должен быть написан позже. Таким образом, модель проектирования должна быть схемой того, как должен быть структурирован и написан текст программы. Поскольку мы хотим иметь хорошее, легко управляемое слежение за изменениями от модели анализа через модель проектирования до модели реализации (исходного текста программы), мы попытаемся отобразить объекты проектирования непосредственно в модули, используемые целевым языком программирования.
Блоки - абстракции фактической реализации системы, поэтому они будут содержать исходный текст программы. Чтобы знать, как реализовывать блоки, нам нужно дальше уточнить модель проектирования описанием того, как блоки будут взаимодействовать во время выполнения программы. Для описания взаимодействия блоков мы используем сигналы. Сигнал посылается от одного блока к другому для запуска некоторого действия в этом объекте. Это действие может послать новые сигналы другим блокам.
Блоки прямо соответствуют модулям в целевом языке. Например, в Cи++ типичный блок будет отображаться в один файл (фактически в два, с расширениями .h и .с), включающий один или несколько классов. В Аде естественно отображать блок в пакет. На целевой модуль ссылаются как на объектный модуль. Например, в Cи++ объектный модуль - класс, в Аде - пакет. Интерфейсы блоков будут отображаться в объектные модули конкретного языка и служить как интерфейсы этих модулей (файл .h в Cи++ , часть спецификации в пакете Ады). Блок может поэтому быть реализован одним или несколькими объектными модулями.
В течение процесса конструирования сложность возрастает очень сильно. Существенно уметь справляться с этой сложностью. Мы группируем объекты в подсистемы, которые могут быть использованы в моделях как анализа, так и проектирования. Они рекурсивным образом могут включать другие подсистемы. Таким образом, мы иерархически структурируем систему, чтобы справиться с её сложностью. Высший уровень - это системный уровень, который фактически является приложением и также определяет границы приложения.
Диаграммы взаимодействий применяются в модели проектирования для описания того, как в каждом виде использования обрабатываются взаимодействия связанных объектов. Взаимодействия происходят, когда блоки посылают и принимают сигналы друг от друга. На диаграмме взаимодействий каждый блок, участвующий в данном виде использования, представляется вертикальной колонкой.
Обычно, внешняя среда системы, её граница, представляется самой левой колонкой. Она представляет интерфейс со всем, что находится вне блоков диаграммы (например, с внешними актёрами) и может следовательно соответствовать различным внешним интерфейсам системы. Слева от границы системы мы описываем последовательности взаимодействий. Это описание текстуальное, в виде структурного текста или псевдокода. В случае псевдокода используются конструкции целевого языка программирования для облегчения перехода к фактической реализации. Текст описывает что происходит в отдельной части вида использования, называемой операцией. Колонка (т.е. блок), которой принадлежит операция, обозначается прямоугольником, представляющим операцию.
Диаграммы взаимодействий управляются событиями. Новое событие приводит к возникновению новой операции. Эти события - сигналы, которые посылаются от одного объекта другому и инициируют операцию. Рис. 5 даёт пример диаграммы взаимодействий.
Рис. 5. Пример диаграммы взаимодействий в системе утилизации мусора
На диаграмме вид использования
начинается, когда клиент нажимает кнопку старта. После этого блок customer
panel (панель клиента) активизирует внешние по отношению к системе сенсоры.
Теперь клиент может начать загрузку пустых бутылок, консервных банок
и упаковочных корзин. Это решается
оператором DO...WHILE, который заканчивается, когда клиент запрашивает
квитанцию. Сдаваемые предметы проверяются этим циклом; если предмет принят, мы
увеличиваем число предметов этого типа, загруженного клиентом и общее число за
день. Заметим, что увеличение общего числа за день поручается блоку Receipt
Basis (База приёмки).
Модель реализации состоит из исходного текста программы с сопровождающими комментариями. Заметим, что мы не требуем объектно-ориентированного языка программирования; метод может быть использован с любым языком для получения объектной структуры системы. Тем не менее, объектно-ориентированный язык предпочтительнее, поскольку все фундаментальные понятия могут быть легко отображены в конструкции языка.
Основа реализации - модель проектирования, определяющая интерфейс каждого блока и описывающая поведение, ожидаемое от этого интерфейса. Хотя очень желательно иметь тесное соответствие между блоками и фактическими модулями, это не всегда возможно в более сложных средах. В одном из проектов один блок-сущность завершился реализацией 17 классов Си++. Однако это была сложная реализация из-за использования системы управления реляционной базой данных, требующей таких вещей как преобразование, поиск по ключу, обработку ошибок, управления версиями и т.д. Это необычный случай. Как правило, один блок будет отображаться на один-пять объектных модулей.
Очень мощное средство реализации - способность повторно использовать компоненты. Это полностью реализованные части системы, позволяющие строить систему из более мощных понятий (высоких абстракций), чем может предложить язык программирования. Компоненты могут рассматриваться как завершённые строительные элементы, которые прямо можно использовать в нашей системе.
Метод, или методология, - это запланированная процедура, с помощью которой шаг за шагом достигается заданная цель. Большинство методов описывают (часто абстрактно), как следует мыслить и рассуждать при разработке программной системы. Многие также задают последовательность шагов и подшагов, которым нужно следовать, и которые описывают, как нужно выполнять работу, подразумевая некоторую основополагающую архитектуру. Это означает, что описание метода формулируется в терминах понятий архитектуры, которая должна быть реализована.
На основе спецификаций требований и дискуссий с предполагаемыми пользователями разрабатываются две различные модели: модель требований и модель анализа. Модель требований задаёт границы системы и определяет, какие функции предлагает система. Эта точка зрения разработчика на то, что что хочет заказчик, и она служит в качестве контракта между разработчиком и клиентом. Существенно то, что эта модель должна быть понятна людям, не знакомым с объектной ориентацией и системой OOSE. Модель требований обычно состоит из трёх частей: модели видов использования, объектной модели предметной области и описания пользовательского интерфейса. Модель видов использования определяет функциональность, которую система предлагает с точки зрения пользователя и определяет, что должно происходить внутри системы. Она использует актёры для представления ролей, которые могут играть пользователи, и виды использования для представления того, что пользователи могут делать в системе. Каждый вид использования - завершённый круг событий в системе с точки зрения пользователя. Если необходимо, может также быть разработано описание интерфейса пользователя. Оно определяет в деталях как должен выглядеть интерфейс пользователя, когда выполняется заданный вид использования. Чтобы дать концептуальную картину и лучшее понимание системы, мы применяем объекты для представления частных случаев предметной области. Эта модель будет служить в качестве общей базы для всех людей, вовлечённых в анализ требований, - как разработчиков, так и заказчиков.
Чтобы определить, какие следует применять виды использования, мы определяем при помощи актёров поведение пользователей системы. Актёры моделируют потенциальных пользователей. Актёр - это тип или категория пользователя. Когда пользователь что-то делает, он действует как частный случай такого типа. Один человек может представлять (играть роль) нескольких различных актёров. Актёры, следовательно, определяют роли, которые могут играть пользователи. Актёры моделируют нечто, требующее обмена информацией с системой, или пользователя-человека или другие системы, которые взаимодействуют с данной системой. Актёры составляют нечто внешнее по отношению к разрабатываемой системе, поэтому должны быть заданы границы, определяющие пределы системы.
Актёры, которые будут использовать систему непосредственно и наиболее регулярно (возможно, в своей повседневной работе) называются первичными актёрами. Каждый акте будет выполнять одну или более основных задач системы. Кроме этих первичных участников есть другие, наблюдающие и поддерживающие систему, называемые вторичными актёрами. Вторичные актёры существуют для того, чтобы первичные могли использовать систему. Чаще бывает проще найти акте ров, моделирующих людей, нежели машины или другие системы.
Как только мы определили, что есть вне системы, её функции внутри можно определить через виды использования. Вид использования - особый случай выполнения некоторой части функций системы. Каждый вид использования составляет последовательность взаимосвязанных транзакций, выполняемых некоторым актёром в диалоге с системой. Полный набор видов использования определяет все варианты использования системы.
Актёры - главное средство для нахождения видов использования. Полная функциональность системы определяется путём спецификации всего того, что будет способен делать каждый актёр при взаимодействии с системой. Чтобы определить виды использования, мы можем прочитать спецификацию требований с точки зрения актёров и провести дискуссию с теми пользователями, которые будут действовать в качестве актёров, задавая им ряд вопросов, например:
Не всегда понятно, какая функциональность должна быть помещена в отдельный вид пользования, а какая является только вариантом другого вида использования. Если различия небольшие, их лучше описать как варианты одного вида использования. Если различия больше, они должны быть описаны как отдельные виды использования. Например, для вида использования "телефонный вызов", если вызванная сторона не отвечает - будет ли это отдельным видом использования? Хотя он включает совершенно различное поведение, он логически тесно связан и вероятно является вариантом вызова с ответом.
Идентификация видов использования часто происходит итеративно. Как только картина стабилизируется, каждый вид использования описывается более подробно. Вначале делается основной шаг, на котором описываются наиболее важные последовательности, дающие лучшее понимание вида использования. Варианты основного шага и ошибки, которые могут возникать, описываются как альтернативы. Эти альтернативные описания не разрабатывались ранее, поскольку модель требований обычно подвергается нескольким изменениям.
Когда детально описываются и анализируются виды использования, как правило, вскрываются неясные места в спецификации требований. Неопределённые требования, таким образом, становятся ясными на ранней стадии разработки. Поскольку виды использования часто фокусируются на отдельных функциональных областях приложения, появляется возможность разрабатывать виды использования для различных областей раздельно, соединяя их вместе позже при формировании полной модели требований. Так что мы можем сосредоточиться на одной проблеме за раз, собирая позже результаты вместе, без необходимости рассматривать сразу всю проблему.
Одним из мощных понятий, используемых при структурировании и связи описаний видов использования, является отношение "основанный на". Основанный на относится к тому, как одно описание вида использования может быть вставлено в другое описание, тем самым расширяя последнее. Таким образом, расширение видов использования можно описывать компактно, позволяя легко добавлять и изменять функциональность. Вид использования, не основанный на, должен содержать в себе завершённый курс действий, целиком независимый от включённой последовательности. Первоначальное описание не содержит никаких ссылок на другие курсы, которые могут быть включены, что позволяет избежать чрезмерной сложности и зависимости. Описывая основные виды использования независимо от внешних действий, мы можем добавлять новые расширения без изменения первоначального описания.
При описании видов использования и их связи с потенциальными пользователями часто бывает удобно описывать более подробно интерфейс пользователя. Например, мы можем задавать черновые наброски того, что пользователь будет видеть на экране, когда выполняется заданный вид использования, или более сложное моделирование, использующие программы-прототипы пользовательского интерфейса. Таким способом вид использования может быть смоделирован так, как он будет появляться перед пользователем ещё до того, как мы даже начали думать о его реализации. Этот метод сокращает возможности недопонимания. Описание пользовательского интерфейса - существенная часть описания вида использования и должна сопутствовать последнему.
При разработке интерфейсов, будущие пользователи должны быть вовлечены в этот процесс на ранней стадии, чтобы новые интерфейсы отражали их логическое видение системы. Один из наиболее фундаментальных принципов разработки интерфейса человека с компьютером состоит в том, чтобы поддерживать соответствие между концептуальной картиной системы, которую видит пользователь, и реальным поведением системы. Используя модель проблемной области как концептуальную базу для определения конструкций и семантики системы, а также интерфейса пользователя, этот интерфейс может быть построен в соответствии с логическим представлением пользователя о системе.
Задачи системы бывает довольно трудно определить и выделить, особенно в тех случаях, когда требования к системе противоречивы. Использование объектов проблемной области помогает в разработке логического представления задачи, особенно объектов, имеющих прямые аналоги в среде и о которых система должна обрабатывать информацию. Модель проблемной области также поддерживает определение видов использования, задавая понятия, с которыми система будет работать. Глоссарий, применяемый для формирования функциональности вида использования, особенно важен, когда в его определении участвуют несколько человек. Главное преимущество такой модели - её применимость как средства коммуникации. Поскольку клиентам и пользователям будут знакомы все понятия, модель может быть использована при определении того, что система будет делать. Предлагая клиентам нарисовать картину их видения системы и обосновать её, мы можем обеспечить эволюцию модели предметной области. Общая терминология по виду использования сокращает возможные недоразумения между разработчиками и потенциальными клиентами.
Модель требований, как она описана до сих пор, достаточна для определения функциональности системы. Эта модель, однако, может быть развита для улучшения её повторной используемости и для подготовки перехода к модели анализа. Такое улучшение в основном включает идентификацию и выделение похожих частей видов использования, называемых абстрактными видами использования. Абстрактные виды использования не возникают сами по себе, но служат для описания общих частей в других видах использования. Общие части нужно описывать только один раз, а не в каждом виде использования, где есть похожее поведение. Изменения в этих общих частях автоматически повлияют на все виды использования, разделяющие эти части. Виды использования, которые фактически должны выполняться, называются конкретными видами использования.
Абстрактные виды использования обозначаются через абстрактные актёры. Абстрактный актёр обычно описывает роль, играемую по отношению к системе. Различные актёры, способные играть похожие роли, могут наследовать свойства от общего абстрактного актёра. Преимущество моделирования абстрактных актёров состоит в выражении похожих частей видов использования. Если некоторый вид использования или его часть выполняется несколькими различными актёрами, этот вид использования должен определяться по отношению только к одному актёру, а не к нескольким.
Виды использования - это ядро, содержащееся во всех действиях при разработке последовательных моделей и помогающее сохранять чёткий взгляд на проблему. Контролируя работу посредством видов использования, мы добиваемся естественно дисциплинированного подхода. Зная число и сложность видов использования, мы также облегчаем оценку работы, включённой в последовательные модели, и предсказуемость времени, требуемого для обработки каждого вида использования.
Как только модель требований разработана и уточнена клиентами, мы можем сконцентрироваться на структурировании системы, начав с разработки модели анализа. В модели анализа система описывается тремя типами объектов: интерфейсом, сущностью и управлением. Каждый из них имеет своё назначение и будет моделировать один аспект системы. Объекты также группируются в управляемые единицы, называемые подсистемами. Модель анализа имеет целью создание хорошей платформы для проектирования системы и формирует основу проекта.
Разработка модели анализа в действительности влечёт за собой распределение определённого видами использования поведения среди объектов модели. Объект может быть общим для нескольких различных видов использования, и мы должны определить, какой объект отвечает за представление какого поведения в каждом виде использования. Хотя это и возможно, поведение не нужно разбивать на операции на этой стадии. Вместо этого более естественный путь - применение вербального описания ответственностей, или ролей, играемых каждым объектом.
Вся функциональность, прямо зависящая от среды системы, помещается в интерфейсные объекты. Именно через эти объекты актёры взаимодействуют с системой. Задача интерфейсного объекта - транслировать действия актёров в системе в системные события и транслировать те события в системе, в которых актёр заинтересован, в нечто, представимое актёру. Иными словами, интерфейсные объекты описывают двунаправленную связь между системой и её пользователями. Интерфейсные объекты могут включать интерфейсы с другими системами и с пользователями-людьми. Интерфейсные объекты довольно просто определить, поскольку они или ясно определяются из описаний пользовательского интерфейса в модели требований, или из специфической для интерфейса функциональности, выделяемой из описаний актёров или видов использования. Если определены и выделены интерфейсные объекты, легко изменять интерфейс в системе. Поместив все, что касается интерфейса, в один объект, мы каждое изменение в этом интерфейсе делаем локальным в этом объекте.
Какое поведение в виде использования должно присваиваться отдельному интерфейсному объекту - решается в общем случае на основе потенциальных изменений. Любое изменение функциональности, прямо относящееся к интерфейсу, следует локализовать в интерфейсном объекте. Другие изменения не должны влиять на интерфейсные объекты. Для определения того, какая часть последовательности событий в виде использования должна быть размещена в интерфейсных объектах, мы смотрим на взаимодействия между актёрами и видом использования. Это означает, что мы должны посмотреть на части со следующими характеристиками:
Для моделирования информации, которую система будет обрабатывать в течение длительного времени, мы применяем объекты-сущности. Как правило, такая информация живёт дольше, чем вид использования, т.е. информация должна быть сохранена, после того, как вид использования завершён. Вместе с собственно информацией мы также размещаем в объекте-сущности поведение, естественным образом принадлежащее этой информации.
Объекты-сущности определяются из видов использования точно так же, как и интерфейсные объекты. Большинство объектов-сущностей обнаруживаются рано и очевидны из объектной модели предметной области. Но некоторые могут обнаруживаться с трудом. Объекты-сущности обычно соответствуют предметам реального мира, находящимся вне системы, хотя это и не всегда так. Слишком просто - моделировать чересчур много объектов-сущностей, полагая, что необходимо больше информации, чем вызывается на самом деле. Гораздо труднее моделировать только те объекты-сущности, которые действительно нужны. Поэтому важно работать дисциплинированным, структурным путём. Руководством должны быть виды использования: включать следует только те объекты-сущности, которые подтверждаются описаниями видов использования. Каждое место в виде использования, где нам нужно хранить информацию, - потенциальный объект-сущность.
Поведение вида использования вначале размещается в интерфейсных объектах и объектах-сущностях. Иногда только этих двух типов будет достаточно для размещения всего составляющего системы. В более сложных случаях некоторое поведение не может естественным образом быть помещено ни в интерфейсные объекты, ни в объекты-сущности. В этих случаях объекты используются, как правило, или для транзакций, или для последовательностей управления, специфичных для одного или нескольких видов использования, или для действий по отделению объектов-сущностей от интерфейсных объектов. Объекты управления, таким образом, объединяют ход событий и осуществляют связь с другими объектами. Если такое поведение распределить по уже определённым объектам, способности к изменению уменьшилась бы, поскольку изменения затронули бы несколько объектов и их труднее было бы внести. Объекты управления обычно служат в качестве клея для соединения других объектов в один вид использования. Они обычно наиболее кратко живущие из всех типов объектов и существуют только в течение выполнения одного вида использования.
Нелегко найти баланс между тем, что поместить в объекты-сущности и интерфейсные объекты, а что присвоить объектам управления. Объекты управления часто обнаруживаются прямо из видов использования. В качестве предварительной модели, объект управления может быть создан для каждого конкретного и каждого абстрактного вида использования. Каждый вид использования обычно включает интерфейсные объекты и объекты-сущности. Поведение, которое остаётся неразмещенным после выделения интерфейсов и сущностей, помещается в объекты управления, но по ряду причин имеет смысл отойти от такого первоначального подхода. Там, где не остаётся неопределённого поведения, объекты управления не нужны. Если, с другой стороны, остаётся не присвоенным поведение очень сложной натуры, оно может быть разделено между более чем одним объектом управления, каждый из которых с более ограниченными задачами, что будет проще для понимания и описания. Объект управления, связанный с несколькими различными актёрами, означал бы, что поведение отличается для каждого актёра и его следует разбить на несколько объектов управления. Цель состоит в том, чтобы привязать один актёр к одному объекту управления, поскольку изменения часто инициируются актёрами. Если каждый объект управления будет зависеть только от одного актёра, изменения в системе могут быть изолированы.
Обычно модель анализа разрабатывается для одного вида использования за один раз; относящиеся к нему интерфейсные объекты, объекты-сущности и объекты управления определяются перед тем, как перейти к следующему виду использования. Однако, поскольку объекты анализа ортогональны видам использования в смысле, что один объект может участвовать в нескольких видах использования, этот процесс - итеративный. Как только определено множество объектов, оно может быть модифицировано для приспособления к новому виду использования. Цель состоит в том, чтобы сформировать по-возможности наиболее стабильную структуру, повторно используя как можно большее число объектов.
Найти необходимые объекты обычно легко; гораздо труднее определить, какие операции и атрибуты следует предложить этим объектам. Поскольку единственный способ манипулировать объектом - через его операции, определённых операций должно быть достаточно для всех. пользователей объекта. Детальные описания видов использования имеют чрезвычайное значение для определения необходимых операций. Структурный метод, обычно используемый в конструировании, может также быть применён и в анализе для определения операций, но поскольку эти операции наверняка будут изменены при проектировании, их обычно в модели анализа не определяют.
После того, как будут определены все объекты анализа, система может содержать большое число объектов: от 30 до 100 для проекта среднего размера. Ясный обзор и понимание такой большой модели редко возможен, поэтому объекты нужно сгруппировать в один или более уровней, в зависимости от размера системы. Группы объектов называются подсистемами. Подсистемы могут содержать подсистемы. На дне иерархии подсистем располагаются объекты анализа. Группирование объектов в подсистемы нужно для уменьшения сложности и для структурирования системы с целью дальнейшей разработки и сопровождения. Подсистемы также служат как удобные единицы в организации (например, для разработки, маркетинга, продаж, рассылки). Хотя некоторые подсистемы обязательны в системе, большинство из них не обязательны.
Подсистемы самого низкого уровня, называемые сервисными пакетами, рассматриваются как единицы изменения. Они считаются неразделяемыми, или атомами: клиент берет или всю единицу или ничего. Наименьшее изменение должно касаться не более, чем одной такой подсистемы. Наиболее важный критерий разбиения на подсистемы - предсказуемые изменения системы. Одна подсистема, следовательно, должна относиться только к одному актёру, поскольку изменения обычно побуждаются актёром. Разбиение на подсистемы должно также быть основано на функциональности системы, чтобы все объекты с сильной общностью, функциональными связями были помещены в одну подсистему. Для определения объектов с сильными общими связями мы начинаем с одного объекта и изучаем его окружение. Другой критерий разбиения на подсистемы - уменьшение связей между подсистемами.
На этапе конструирования система строится на основе моделей анализа и требований. Конструирование необходимо по трём главным причинам.
Модель проектирования явно определяет интерфейсы объектов и семантику операций. Эта модель также отражает решения о том, какими будут база данных, свойства языка программирования, распределённая обработка и т.п. Модель проектирования состоит из блоков, которые являются объектами проектирования. Они составляют фактическую структуру модели проектирования и показывают, как проектируется система. Блоки будут далее реализованы в исходном коде и потому суть абстракции фактической реализации. Блок может быть реализован в исходном коде одним или несколькими объектными модулями. Объектный модуль - фактическая единица, написанная на целевом языке программирования. В объектно-ориентированном языке программирования объектные модули - фактические классы, определяемые в языке. В любом данном языке есть прямое соответствие некоторому понятию языка, например, классу в Эйфеле или пакету в Аде.
Вначале каждый объект анализа просто преобразуется в соответствующий блок. Если каждый объект анализа может быть преобразован в блок, то введённые в модель анализа изменения будут локализованы в модели проектирования и, следовательно, также в исходном коде. Преобразуемость имеет двунаправленный характер: класс (или другой объектный модуль) в исходном коде может быть обратно преобразован в модель анализа, чтобы можно было посмотреть, из чего он вырос. Такая простая архитектура системы предпочтительна вначале, но может быть изменена при подгонке к среде реализации. Например, блоки могут быть разбиты или распределены по компьютерной системе, совершенно новые блоки могут понадобиться для построения интерфейса к существующим СУБД.
Определив архитектуру системы, мы должны описать, как блоки будут взаимодействовать. Для каждого конкретного вида использования рисуется диаграмма взаимодействий, описывающая, как этот вид использования реализован через взаимодействующие блоки, посылающие и принимающие сообщения. Эти сообщения должны быть определены вместе с посылаемыми параметрами. Протоколы блоков определяются при проектировании вида использования. На основе того, какие объекты анализа предлагаются видом использования в модели анализа, соответствующие блоки включаются в диаграмму взаимодействий. Новые блоки, введённые на этапе конструирования, также могут участвовать в виде использования. Когда все виды использования, или, по крайней мере, все виды использования для конкретного блока, спроектированы, блок (блоки) может (могут) проектироваться на основе внешних требований, определённых в модели анализа.
Фактическую реализацию блоков в исходном коде можно начинать, когда стабилизируются интерфейсы. Через проектирование видов использования мы неявно определили протоколы каждого блока. По всем диаграммам взаимодействий, в которых принимает участие блок,. и всем операциям, определённым для этого блока, мы имеем полную картину требований к блоку. Обычно эти требования появляются во время проектирования отдельных видов использования разными людьми и не собраны в один документ. Тем не менее они явно существуют и привязаны к соответствующему блоку. Нетрудно выделить требования - это можно сделать даже подручными CASE-средствами. Интерфейсы блока могут быть разработаны из диаграмм взаимодействий и затем выражены на языке программирования, например, на Си++. в виде файлов-заголовков из открытых классов блока. На этой стадии можно заморозить интерфейсы блоков, что позволит вести проектирования разных блоков параллельно.
Во многих случаях блок будет соответствовать в точности одному классу и его экземплярам, что позволит легко отобразить интерфейс объекта из модели проектирования в специальный интерфейсный класс в исходном тексте. В других случаях для реализации одного блока будут нужны несколько классов: для обработки среды реализации, для реализации атрибутов, использования компонентов, отделения общих функций в абстрактные классы и т.д.
Диаграммы переходов состояний могут быть использованы как средство промежуточного уровня для понимания внутреннего устройства объекта, прежде, чем начинать фактическую реализацию. Эти диаграммы формируют упрощённое описание для улучшения понимания блока, независимо от выбранного языка программирования. Они описывают, какие сообщения блок может принимать и что будет происходить при получении этих сообщений.
После того, как закончено структурирование блоков, мы определяем классы системы. Цель состоит в разработке устойчивых, повторно используемых классов. Везде, где это возможно, два класса не должны выполнять похожие функции, если только они не связаны через наследование. Классы должны также быть хорошо согласованными и представлять функции, внутренне хорошо взаимосвязанные. Например, если половина операций класса имеет доступ к половине переменных экземпляра, а другая половина операций - к другой половине переменных, то мы должны разделить этот класс на два. Другой эвристический критерий разработки хорошего класса включает оценку потенциальной повторной используемости класса. Сделает ли изменение класс более используемым, чем другие классы? Конечно, для разработки хорошего класса нужно время и не всегда эффективно разрабатывать каждый класс в системе как можно более общим.
Заметим, что из модели анализа можно проследить все пути к исходному тексту. Когда мы читает исходный текст, мы можем также прямо проследить путь от него к модели анализа. Это свойство неоценимо в жизненном цикле системы, особенно для специалистов, занимающихся сопровождением и дальнейшей разработкой системы. Адаптация проекта к языку программирования происходит на этой поздней стадии, однако во время всего процесса проектирования мы будем сталкиваться с вопросами, как решить проблемы, появляющиеся в связи со средой реализации. Специализация к языку программирования описывает то, как мы переводим термины, используемые в проектировании, в термины и свойства языка реализации. Хотя методы, описываемые здесь, достаточно общие и независимые от фактического языка, все языки будут иметь некоторые специальные вопросы и проблемы во время реализации.
Нарисованная здесь общая картина может дать впечатление, что процесс конструирования прямой и следует по лёгкому пути. Однако реальная разработка является пошаговым процессом и часто требует сделать несколько итераций.
Этот раздел суммирует понятия моделирования, использованные в документе.
Следующие ассоциации могут быть использованы во всех моделях.
Ассоциации классов рисуются пунктирными линиями.
Ассоциации экземпляров рисуются сплошными линиями.
Подход, управляемый видами использования в OOSE, представляет развёрнутый взгляд на жизненный цикл разработки, включающий анализ, конструирование и тестирование. Описываются как метод моделирования, так и определение составляющих его процессов, что даёт мощную и хорошо определённую методологию, применимую ко всем типам проектов, особенно к большим и сложным системам, требующим применения повторяющихся и оптимизационных процессов.