Методология oose (Object-Oriented Software Engineering)
Метод OOSE - это систематизированный метод промышленной разработки ПО, разработанный Иваром Якобсоном.
Этот метод основывается на проектировании, управляемом видами использования – подходе, центральным звеном которого является понимание того, как фактически используется система. Организуя модели анализа и проектирования на основе последовательных взаимодействиях пользователя и системы (т.е. фактических сценариях ее использования), указанная методология позволяет создавать более удобные, прочные системы, легче приспосабливаемые к изменениям.
Метод OOSE составляет основу универсального языка моделирования UML, признанного стандартным языком объектно-ориентированного анализа и проектирования.
Метод делит всю разработку на процессы или действия, которые в отличие от традиционных фаз разработки, могут повторяться и перекрываться.
Как и остальные методы, OOSE включает понятия прикладных и системных сущностей, но в отличие от большинства методов не ограничивает всю разработку жёсткими рамками только этих разновидностей объектов. В результате получается более прочная модель приложения: ПО в своей основе более приспособлено к изменению и расширению, а его компоненты могут быть повторно использованы в процессе разработки.
Подход OOSE распознает три различных вида объектов, отделяющих управление и координацию сценариев использования системы от интерфейса и от сущностей, составляющих прикладные понятия. Путём отделения друг от друга внешнего поведения, внутренней структуры и динамики, каждое из них можно изменять и расширять независимо от остальных.
Эти действия вырабатывают последовательность тесно связанных моделей, что облегчает неразрывность разработки через последовательное моделирование и высокую степень следования требованиям. Используя этот подход, можно через последовательность стадий создавать очень большие и сложные системы на основе независимого анализа отдельных видов использования. Сила этого метода, следовательно, возрастает с увеличением размера разрабатываемой системы.
Цикл жизни разработки
Все системы меняются в течение своего цикла жизни. Это нужно учитывать при разработке систем, которые предполагают существование более чем одной версии, что относится практически ко всем системам. Большинство методов разработки концентрируются на новой разработке (см. рис. 7), лишь кратко рассматривая работу по ревизии, хотя известно, что изменения составляют самую большую часть общего цикла жизни большинства систем. Истинно промышленный процесс должен концентрироваться на изменениях системы. Система обычно разрабатывается через изменения в некотором числе версий, как показано на этом рисунке. Новая разработка с этой точки зрения - только лишь особый случай первой версии. Новая разработка, тем не менее, важное действие. Она устанавливает архитектурную философию и составляет основу системы, которая должна сохраняться в течение всей последующей разработки. Ошибочная основа будет иметь серьёзные последствия для цикла жизни системы.
Рис. 7. Первая версия системы представляет лишь малую часть затрат всех ресурсов разработки
В разработке, управляемой видами использования, мы фокусируем внимание на изменениях в конкретном продукте.
Таким образом, подход описывает, как одна версия должна быть изменена в следующей версии.
Уникальное свойство этой модели цикла жизни то, что здесь нет специальной фазы сопровождения. Все действия в течение цикла жизни фактически суть изменения конкретной модели.
Вместо фокусирования внимания на том, как нужно управлять отдельным проектом, мы фокусируем внимание на том, как нужно разрабатывать некоторый продукт (готовое приложение) и как сопровождать его в течение всего цикла жизни. Это означает, что вместо общепринятого каскадного описания, мы разделяем разработку продукта на процессы, каждый из которых описывает одно действие по управлению продуктом. Процессы работают в сильно взаимодействующей манере. Каждый процесс управляет отдельной фазой или действием разработки системы. Разработка затем расширяется на все такие процессы и они существуют в течение всего цикла жизни системы. Вся разработка, следовательно, управляется этими процессами, и каждый процесс может, в свою очередь, состоять из некоторого числа взаимодействующих процессов.
Разработка системы - это постепенная трансформация различных моделей разрабатываемой системы.
Первая модель описывает требования заказчика, а последняя является полностью оттестированной программой. Между этими крайними точками располагаются несколько других моделей.
Цикл жизни разработки строится из различных процессов, которые кооперируются для преобразования продукта из одной версии в другую путём изменения различных моделей. Главные процессы суть анализ, конструирование и тестирование. Они описывают действия, которые выполняются при разработке продукта и которые "существуют" в течение всего цикла жизни продукта. Когда требуется новая версия продукта, эти процессы активизируются группой разработчиков (см. рис. 8).
Рис. 8. Процессы взаимодействуют при разработке новой версии системы.
В процессе анализа мы создаём концептуальную картину системы, которую хотим построить. Здесь разрабатываются различные модели с целью достичь понимания системы, а также для обратной связи наиболее существенных аспектов системы с заказчиком и с процессом конструирования.
В процессе конструирования мы разрабатываем систему из модулей, созданных во время анализа. Сюда входят проектирование и реализация, а в результате получается полная система.
Процесс тестирования объединяет систему, проверяет и решает, следует ли передавать её на поставку.
Процесс комплектования, связанный главным образом с процессом конструирования, разрабатывает и сопровождает повторно использованные компоненты - полностью реализованные конструктивные части, которые могут быть использованы в нескольких приложениях, главным образом во время конструирования. Процесс комплектования не привязан к конкретному продукту, это "многопродуктный" процесс.
То, что требования к информационной системе, как и к технической системе, полностью не известны в начале проекта – это скорее правило, чем исключение. Знания системы растут по мере продвижения работы.
Когда начинает действовать первая версия системы, появляются новые требования, а старые изменяются. Таким образом, система не может быть полностью разработана в предположении, что спецификация требований остаётся неизменной в течение разработки, что для больших систем занимает несколько лет.
Во многих случаях лучше разрабатывать систему шаг за шагом, начиная с нескольких её основных функций. Как только станет ясен подходящий путь и придёт лучшее понимание того, как должна развиваться система, можно добавить новые функции. Таким образом, наращивание идёт постепенно до тех пор, пока не будет готов окончательный продукт, обычно ко времени выпуска продукта.
Такая пошаговая стратегия также обеспечивает наиболее быструю обратную связь в течение процесса разработки.
На практике, пошаговая разработка системы означает, что мы можем разбить систему на части, соответствующие обслуживающим запросам заказчика. Каждая новая стадия расширяет систему новой функцией до тех пор, пока окончательный продукт не будет включать в себя всю требуемую систему.
Каждая стадия разрабатывается в цикле и тестируется перед тем как будет завершена. Это означает, что процессы протекают несколько раз для каждой версии системы.
Анализ
Цель процесса анализа - проанализировать, определить и описать систему, которая должна быть построена. Разрабатываемые модели будут описывать, что должна делать система. Основа моделирования - требования заказчика или конечного пользователя к системе, выраженные в некоторой форме. На фазе анализа мы строим модели, которые облегчат нам понимание системы.
Разрабатываемые в процессе анализа модели полностью ориентированы на приложения, а не на среду реализации. Это "существенные" модели, которые не зависят от операционной системы, языка программирования, СУБД, распределения процессов, конфигурации аппаратуры. Это и будет нашим определением анализа: моделирование системы без учёта реальной среды реализации. Поскольку модели целиком проблемно-ориентированы и не уделяется никакого внимания реальной среде реализации, эти модели довольно просто могут быть разработаны от постановки задачи до их функционирования. Система адаптируется к среде реализации на этапе конструирования.
На этапе анализа разрабатываются две различных модели:
модель требований,
модель анализа.
Они основаны на спецификациях требований и дискуссиях с будущими пользователями системы.
Модель требований, должна определить границы системы и те действия, что происходят внутри системы. Для этой цели мы разрабатываем концептуальную картину системы, используя объекты проблемной области, а также описания специального интерфейса, если это важно для системы. Кроме того, мы описываем систему как набор "видов использования", которые выполняются некоторым числом "актёров". Актёры составляют среду использования системы, а виды использования - это то, что происходит внутри системы.
Вид использования - одно из уникальных понятий методологии OOSE.
Модель анализа - архитектурная модель, используемая для анализа целостности системы, состоит из различных классов объектов:
активных контроллеров,
проблемных сущностей,
интерфейсных объектов.
Цель этой модели - найти прочную и расширяемую структуру для системы как основу для конструирования. Каждый тип объекта имеет специальную цель для такой прочности: вместе они составят общую функциональность, которая была определена в модели требований. Для управления разработкой модель анализа может группировать объекты в подсистемы.
Модель анализа состоит из общей функциональной спецификации разрабатываемой системы, без учёта среды реализации.
Модель проектирования, разрабатываемая в процессе конструирования, включает в себя части этой среды, язык реализации, СУБД, и т.п.
Конструирование
На основе моделей анализа и требований, создаваемых в процессе анализа осуществляется конструирование, процесс конструирования заканчивается тогда, когда завершается кодирование и составные части протестированы.
Какова же цель процесса конструирования? Разве нельзя написать текст программы прямо из модели анализа, которая уже описывает и объекты системы, и как они относятся друг к другу? Есть три главные причины необходимости процесса конструирования.
Модель анализа недостаточно формальна, чтобы плавно перейти к тексту программы. Мы должны уточнить объекты: какие следует предложить операции, как в точности должна выглядеть связь между различными объектами, какие посылать сообщения и т.д.
Необходимо выполнить адаптацию к фактической среде реализации. На фазе анализа мы предполагаем, что наша система окружена идеальным миром. Мы теперь должны преобразовать модель анализа из пространства анализа в пространство проектирования, принимая во внимание, например, такие факторы: требования к производительности, требования к реальному времени и параллельности действий, системное программное обеспечение, свойства языка программирования, используемую систему управления базами данных и т.д.
Мы хотим выполнить доказательство правильности результатов анализа. По мере расширения нашей системы и повышения степени её формализации, мы будем видеть, насколько хорошо модели анализа описывают систему. Во время конструирования мы можем увидеть, будут ли результаты анализа подходящими. Если мы обнаружим неясные места в моделях анализа или требований, нужно прояснить их, возможно путём возврата к процессу анализа.
Конструирование делится на две фазы: проектирование и реализацию, каждая из которых разрабатывает модель. Модель проектирования - дальнейшее уточнение и формализация модели анализа, в которой учитывается влияние среды реализации. Модель реализации - фактическая реализация системы.
Тестирование
Тестирование доказывает, что построена правильная система. Тестирование традиционно дорого, в основном из-за того, что много ошибок не может быть обнаружено, пока не будет достигнут конец разработки.