Правила преобразования: от архитектуры к реализации

На последнем этапе мы преобразовали архитектурный домен в домен реализации. Для этого мы выразили модули прототипных схем структуры класса как прототипный код (шаблоны кода) в выбранном языке реализации. Затем шаблоны могут заполняться либо из заполненной базы данных архитектуры, либо из специализированных схем структуры класса.

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

Рис.9.10.2. Преобразование прикладных моделей в реализацию.

A. Oodle: He зависимая от языка нотация для объектно-ориентированного проектирования

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

Нотация названа OODLE, как акроним от Object-Oriented Design LanguagE (язык объектно-ориентированного проектирования).

1 Цели

1.1 Что представлять

При разработке нотации OODLE мы стремились, чтобы она отвечала следующим требованиям:

• нотация должна представлять фундаментальные понятия OOD (включающие инкапсуляцию, наследование и полиморфизм) в интуитивной манере;

• в нотации должна быть четко выражена и представлена типизация данных. Умудренные опытом проектировщики учитывают типы данных, независимо от уровня поддержки типизации в выбранном языке реализации;

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

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

1.2 Стиль представления

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

Возможность ручного изображения

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

Никаких излишних различий

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