Тема 12. Моделирование в Cradle — функциональное, объектно-ориентированное, системно-ориентированное

Итак, мы рассмотрели три класса представлений для анализа проектных данных и их связей: таблицы, матрицы, иерархии.

Под каждую задачу лучше подходит какое-то свое представление и понимание какое где лучше использовать обязательно придет с опытом ведения проектов в Cradle.

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

Для этого в Cradle есть поддержка различных нотаций моделирования:

  • Функциональное моделирование:  FAD (Functional, Architecture, Data). Включает SASD нотации (DFD, STD, ERD), а также другие нотации (IDEF0, eFFBD, PFD), архитектурные нотации (PAD, AID), нотации ADARTS (SAD и ASG) и STCs.
  • Объектно-ориентированное моделирование:  UML (Unified Modelling Language). Включает: Use Case Diagram, Sequence Diagram, Collaboration Diagram, Class Diagram, Statechart, Activity Diagram, Package Diagram, Component Diagram, Deployment Diagram.
  • Системно-ориентированное моделирование: SysML (System Modelling Language). Включает: Block Definition Diagram, Internal Block Definition Diagram, Activity Diagram, State Machine Diagram, Sequence Diagram, Use Case Diagram, Requirement Diagram, Parametric Diagram, Package Diagram.

Самое важное по моделированию в Cradle:
1) Cradle — это не «рисовалка». Каждый элемент модели имеет не только графическое отображение — символ, но и его спецификацию.

Например, эллипс с диаграммы Use Case имеет спецификацию с обычным набором полей, в которой вы можете описать детально все свойства этого варианта использования по модели атрибутов Алистера Коберна.

2) Поскольку диаграммы это не рисунки, а модели, разрабатываемые в соответствии с заданной формальной нотацией,  то можно использовать встроенные инструменты проверки согласованности моделей разных уровней — инструменты формальной верификации.

3) Элементы спецификаций можно использовать между диаграммами повторно. Это разрешено там, где применимо по семантике (разрешено нотацией или группой нотаций).

4) Спецификации элементов модели можно связывать с текстовыми элементами — требованиями, тестами и т.д.. Т.е. обеспечивается сквозная поэлементная трассируемость.

5) К спецификациям можно применять все стандартные функции Cradle по работе с текстовыми требованиями — запросы, представления, метрики и т.д. — все то, что мы разбирали в предыдущих темах.

Базовая статья, с которой надо начать, чтобы понять основы моделирования в Cradle
http://cradle.saturs.ru/models-and-domains/

Пошаговая инструкция создания модели на примере IDEF0http://cradle.saturs.ru/creating-idef0-diagram/

Самое важное, что нужно понимать, отстраивая свой технологический процесс проектирования: модели — это отличный способ верификации, но покрыть всю автоматизированную систему графическими моделями — удовольствие крайне дорогое. И здесь проявляется совершенно классное свойство Cradle — возможность бесшовного комбинирования обоих подходов к разработке требований и использования огромных возможностей по трассировке для верификации проекта.

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

Далее несколько иллюстраций:

Пример модели IDEF0, символов и спецификаций:

modelling-example

Пример Use Case модели из демо-проекта:

modelling-example4

Пример eFFBD-модели из демо-проекта:

modelling-example5

Пример UML Activity-диаграммы:

modelling-example3