Метод Шлаера – Меллора - Shlaer–Mellor method

В Метод Шлаера – Меллора, также известный как Объектно-ориентированный системный анализ (OOSA) или Объектно-ориентированный анализ (OOA) - это объектно-ориентированный методология разработки программного обеспечения представлен Салли Шлаер и Стивен Меллор в 1988 году. Этот метод делает документированный анализ настолько точным, что становится возможным реализовать модель анализа напрямую путем перевода в целевую архитектуру, а не путем разработки изменений модели с помощью ряда моделей, более специфичных для платформы. В новом тысячелетии метод Шлаера – Меллора перешел в нотацию UML, став Исполняемый UML.[1]

Обзор

История объектно-ориентированных методов и нотаций с конца 1980-х гг.

Метод Шлаера – Меллора - одна из многих методологий разработки программного обеспечения, появившихся в конце 1980-х годов. Наиболее знакомыми были Объектно-ориентированный анализ и дизайн (OOAD) автор: Грейди Буч, Техника объектного моделирования (OMT) пользователя Джеймс Рамбо, Объектно-ориентированная разработка программного обеспечения к Ивар Якобсон и объектно-ориентированный анализ (OOA) Шлаера и Меллора.[2][3] Эти методы приняли новую объектно-ориентированную парадигму, чтобы преодолеть установленные недостатки в существующих структурированный анализ и структурированный дизайн (SASD) методы 1960-х и 1970-х годов.[4] Из этих хорошо известных проблем Шлаер и Меллор решили обратиться к:

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

Перед публикацией своей второй книги в 1991 году Шлаер и Меллор перестали называть свой метод «объектно-ориентированным системным анализом» в пользу просто «объектно-ориентированного анализа». Метод начал ориентироваться на концепцию рекурсивного дизайна (RD), которая обеспечила возможность автоматического перевода метода.

Что делает метод Шлаера – Меллора уникальным среди объектно-ориентированных методов:

  • степень объектно-ориентированной семантической декомпозиции,
  • точность Обозначение Шлаера – Меллора используется для выражения анализа, и
  • определенное поведение этой модели анализа во время выполнения.

Общее решение, принятое методами объектно-ориентированного анализа и проектирования для этих конкретных проблем со структурным анализом и проектированием, заключалось в переходе от функциональная декомпозиция к семантическая декомпозиция.[5] Например, управление пассажирским поездом можно описать как:

загрузка пассажиров, закрытие дверей, запуск поезда, остановка поезда, открытие дверей, выгрузка пассажиров.

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

Темы метода Шлаера – Меллора

Перевод v. Разработка

Цель метода Шлаера – Меллора - сделать документированный анализ настолько точным, чтобы можно было реализовать модель анализа напрямую путем перевода, а не путем разработки. В терминологии Шлаера – Меллора это называется рекурсивным дизайном. В текущей терминологии (2011 г.) мы бы сказали, что метод Шлаера – Меллора использует форму управляемая моделями архитектура (MDA) обычно ассоциируется с Единый язык моделирования (UML).

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

Это похоже на концепцию виртуальных машин, лежащих в основе Язык программирования Java и Язык программирования Ада, но существует на уровне анализа, а не на уровне программирования. Однажды спроектированная и реализованная, такая виртуальная машина может быть повторно использована в различных приложениях. Виртуальные машины Шлаера – Меллора коммерчески доступны у ряда поставщиков инструментов, в частности у Abstract Solutions, Mentor Graphics и Pathfinder Solutions.

Семантическая декомпозиция

Шлаер – Меллор предлагает семантическую декомпозицию на несколько (проблемных) областей.[6]

  • Разделение между расчетными и проектными моделями: Область анализа точно выражает Какие система должна работать, область проектирования - это модель того, как виртуальная машина Шлаера – Меллора работает для конкретной аппаратной и программной платформы. Эти модели не пересекаются, единственная связь - это обозначения, используемые для выражения моделей.
  • Разложение внутри области анализа где системные требования смоделированы и сгруппированы по конкретным, непересекающимся предметам. Чтобы вернуться к предыдущему примеру пассажирского поезда, можно создать отдельные семантические модели на основе приводов дверей, органов управления двигателями и тормозных систем. Каждая группировка рассматривается и моделируется независимо. Единственное определенное отношение между группировками - это зависимости, например. Применение пассажирского поезда может зависеть как от срабатывания двери, так и от управления двигателем. Системы торможения могут зависеть от управления двигателем.

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

Конкретная система состоит из доменов и определенных мостов между доменами. Мост описывается в терминах предположений, используемых доменом, действующим как клиент, подключенным к домену, действующему как сервер.[7]

Точный язык действий

Одно из требований для автоматическая генерация кода заключается в точном моделировании действий внутри конечные автоматы используется для выражения динамического поведения объектов Шлаера – Меллора.

Shlaer – Mellor является уникальным среди методов объектно-ориентированного анализа в графическом выражении такого последовательного поведения, как диаграммы потоков данных действий (ADFD). На практике инструменты, которые поддерживали Шлаер – Меллор, обеспечивали точный язык действий. Языки действий вытеснили подход ADFD, поэтому все действия записываются в текстовой форме.

Тест и моделирование

Трансляционный подход метода Шлаера – Меллора подходит для автоматизированных сред тестирования и моделирования.[8] (путем переключения целевой платформы во время генерации кода), и это может частично объяснить популярность метода Шлаера – Меллора и других методов на основе MDA при разработке встроенные системы, где тестирование на целевых системах, например мобильные телефоны или системы управления двигателем, особенно сложно.

Что делает такое тестирование полезным и продуктивным, так это концепция виртуальной машины Шлаера – Меллора. Как и большинство методов OOA / OOD, Shlaer – Mellor представляет собой среду передачи сообщений, управляемую событиями. В соответствии с этим общим представлением виртуальная машина Шлаера – Меллора требует наличия механизма приоритетных событий, построенного вокруг Государственные модели, что позволяет одновременно выполнять действия в разных конечных автоматах.

Поскольку любая реализация Shlaer – Mellor требует, чтобы эта модель полностью поддерживалась, тестирование в режиме моделирования может быть очень близкой моделью тестирования на целевой платформе. Хотя функциональные возможности, сильно зависящие от временных ограничений, могут быть трудными для тестирования, большая часть поведения системы очень предсказуема благодаря модели выполнения с приоритетами.

Критика

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

Грэм (1994) описал метод Шлаера – Меллора как ранний пример объектно-ориентированного анализа, который на самом деле нельзя рассматривать как объектно-ориентированный. Согласно Грэхему, в этом методе отсутствует «понятие наследования. Как описано в их книге, это было не более чем объектно-ориентированное расширение моделирование данных."[9] В соответствии с комментарием Capretz (1996) утверждает, что метод Шлаера – Меллора «не учитывает подавляющее большинство объектно-ориентированных идей и предписывается обычная графическая нотация», которая в основном заимствована »из диаграммы сущность – взаимосвязь и диаграммы потоков данных найдено в других структурированных методах ".[10]

Смотрите также

Библиография

  • Стивен Меллор (2002) Сделать модели активами, Сообщения ACM Том 45, 11: 76-87 (ноябрь 2002 г.), 2002 г.
  • Родни К. Монтроуз (2001) Объектно-ориентированная разработка с использованием метода Шлаера – Меллора. Project Technology, Inc.
  • Салли Шлаер, Стивен Меллор (1988) Объектно-ориентированный системный анализ: моделирование мира в данных, Yourdon Press. ISBN  0-13-629023-X
  • Салли Шлаер, Стивен Меллор (1991) Жизненные циклы объектов: моделирование мира в состояниях, Yourdon Press. ISBN  0-13-629940-7
  • Леон Старр (1996) Как построить объектные модели Шлаера – Меллора. Прентис Холл. ISBN  0-13-207663-2

Рекомендации

  1. ^ Меллор, Стивен; Бальцер, Марк (2002). Исполняемый UML, основа для архитектуры, управляемой моделями. Эддисон Уэсли. ISBN  0-201-74804-5.
  2. ^ Андреас Зендлер (1997) Расширенные концепции, модели жизненного цикла и инструменты для объектно-ориентированной разработки программного обеспечения. п. 122
  3. ^ Мартин Фаулер (2004) Краткое руководство по стандартному языку моделирования объектов. п. 7
  4. ^ Роберт Дж. Мюллер (1999) Дизайн баз данных для умных людей: использование Uml для моделирования данных. п. 106. Мюллер добавляет:
    Большая часть работы по объектно-ориентированному моделированию уходила корнями в моделирование данных, и при проектировании базы данных было достаточно хорошо.
  5. ^ Хасан Гомаа (2011) Моделирование и дизайн программного обеспечения: UML, варианты использования, шаблоны и архитектуры программного обеспечения. п. 10. Гомаа объясняет здесь:
    Шлаер и Меллор (1988, 1992) и Коад и Йордон (1991, 1992). Акцент в этих методах был сделан на моделирование проблемной области, сокрытие информации и наследование ...
  6. ^ Мартин Редди (2011) Дизайн API для C ++. стр.126. Редди заявляет:
    Метод Шлаера – Меллора сначала разделяет систему по горизонтали для создания общих «доменов», а затем разделяет их по вертикали, применяя отдельный анализ к каждому домену ... Одно из преимуществ этого подхода «разделяй и властвуй» заключается в том, что домены имеют тенденцию формироваться многоразовые концепции, которые можно применить к другим задачам проектирования.
  7. ^ Салли Шлаер, Стивен Меллор (1991) Жизненные циклы объектов: моделирование мира в состояниях, с.142.
  8. ^ Марсель Туссен (1996) Ада в Европе: Второй международный симпозиум Eurospace-Ada-Europe, Франкфурт, Германия, 2–6 октября 1995 г., том 2. стр.172 подтверждает:
    ... анализ и проектирование с использованием объектно-ориентированных (OO) методов (в данном случае Shlaer – Mellor) и инструмента автоматизированной разработки программного обеспечения (CASE), дающего возможность для автоматической генерации кода и большего повторного использования в последующих симуляторах.
  9. ^ Ян Грэм (1994) Объектно-ориентированные методы. стр.229
  10. ^ Луис Фернандо Капрец (1996) Объектно-ориентированное программное обеспечение: дизайн. стр.77
    Капрец описывает OOSA как «методологию анализа со связанной графической нотацией, которая основана на вариации модели отношений сущностей в сочетании с анализом структурированных систем. Нотация может применяться для описания объектов, атрибутов и отношений, если связь указывает на связь между объекты.".

внешняя ссылка