2.3.3. Рабочие продукты ооап
На рис. 5 изображена информационная карта рабочих продуктов ООА. На этом рисунке видно, что схема домена и проектная матрица создаются для всей системы. Чтобы описать взаимодействие событий между различными подсистемами в пределах домена, для каждого домена создается модель взаимодействия подсистем. Большинство рабочих продуктов ООА нужны на уровне подсистем: информационная модель, модель взаимодействия объектов, модель доступа к объектам и вспомогательные таблицы, описания и списки создаются для каждой подсистемы. Ниже подсистемы находятся объекты, которые её составляют: модель состояний создается для каждого объекта и связи, которые имеют интересующее нас динамическое поведение. Действия каждой модели состояний обеспечивают следующий уровень: диаграмма потоков данных действий создается для каждого состояния каждой модели состояний. Наконец, описание процесса создается для каждого сложного процесса действия.
Рис. 5. Рабочий продукт для Автоматической Системы Разводки Печатных Плат
Литература:
Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях: Пер. с англ. — Киев: Диалектика, 1993.
Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. — Невский Диалект, 1998.
Хингстон Д., Логхид Ф., Ирвин Р. Новый топологический автотрассировщик // ChipNews — 2002, №2(65) — С. 60—64.
2.3.4. Язык uml
2.3.4.1. Введение
Язык Unified Modelling Language (UML) можно считать результатом довольно длинной и еще не завершившейся эволюции методологий моделирования и дизайна.
В 90-х годах наиболее популярными были три объектно-ориентированных подхода:
OMT (автор Джеймс Рамбо), сильной стороной которого является анализ, а слабой ‒ дизайн;
OODA (автор Гради Буч) ‒ сильная сторона этого языка ‒ дизайн, а слабая ‒ анализ;
OOSE (автор Айвар Якобсон) ‒ сильной стороной данного языка является анализ поведения (behavior analysis), однако в остальных областях он достаточно слаб.
В результате соперничества этих методов авторы вышеперечисленных методологий создали унифицированный язык моделирования UML (рис. 1), который унаследовал присутствовавшие в других языках элементы. Далее приведена оригинальная терминология заимствованных/унаследованных элементов языка этой методологии ‒ дело в том, что сейчас существует несколько вариантов переводов этих терминов на русский язык.
Рис. 1. UML и его предшественники
Данная унификация преследовала три основные цели:
моделирование системы, начиная с концепции и заканчивая исполняемым модулем, с применением объектно-ориентированных методик;
разрешение проблем масштабирования в сложных системах;
создание языка моделирования, используемого и человеком, и компьютером.
Официальной датой начала работ по UML считают октябрь 1994 года, когда Рамбо перешел в компанию Rational (ныне Rational ‒ одно из подразделений корпорации IBM). Последним стандартом этого языка является версия UML1.3, вышедшая в 1999 году.
UML ‒ прежде всего язык, и, как всякое языковое средство, он предоставляет словарь и правила комбинирования слов в этом словаре. В данном случае словарь и правила фокусируются на концептуальном и физическом представлениях системы. Язык диктует, как создать и прочитать модель, однако не содержит никаких рекомендаций о том, какую модель системы необходимо создать, ‒ это выходит за рамки UML и является прерогативой процесса разработки программного обеспечения. В связи с этим, видимо, UML довольно часто ассоциируют с RUP ‒ одним из возможных процессов, рекомендующих, какие модели, как и когда нужно создавать для успешной разработки продукта.
UML ‒ это язык визуализации. Написание моделей на UML преследует одну простую цель ‒ облегчение процесса передачи информации о системе. За каждым символом UML стоит строго определенная семантика, что позволяет избегать ошибок интерпретации (ответы на вопросы типа «а что имел в виду разработчик Х, когда он описал иерархию классов Y…» и т.п. будут достаточно прозрачны).
UML ‒ это язык спецификаций и точных определений. В этом смысле моделирование на UML означает построение моделей, которые точны, недвусмысленны и полны.
UML ‒ это язык конструирования. UML не является визуальным языком программирования, но модели в терминах UML могут быть отображены на определенный набор объектно-ориентированных языков программирования. UML предоставляет возможности прямого (существующая модель ® новый код) и обратного (существующий код ® новая модель) проектирования. Достаточно часто средства UML-моделирования реализуют отображения UML-моделей в коде на языках Java, C++, CORBA, VB, Smalltalk.
UML ‒ это язык документирования. Процесс разработки программного обеспечения предусматривает не только написание кода, но и создание таких артефактов, как список требований, описание архитектуры, дизайн, исходный код системы, планирование проекта, тесты, набор прототипов, релизы продукта. В зависимости от культуры разработки продукта в той или иной компании степень формализации данных документов существенно различается, варьируясь от строго определенных шаблонов и формата документов до разговоров на произвольную тему по e-mail или лично. Тем не менее все эти артефакты критичны для успешного процесса разработки продукта. UML предоставляет средства отображения требований к системе, построения документации, тестов, моделирования необходимых действий для планирования проекта и для управления поставленными конечному пользователю релизами.