А.2.1.3.2. Мини-спецификация
В проектах ИС содержимое модулей описывается посредством мини-спецификаций. К числу общеупотребительных методов относится описание управляющих структур (управляющих алгоритмическими процессами) и исполняющих инструкций при помощи псевдокода и структурограмм. В качестве управляющих структур могут служить последовательности, инструкции выбора и повторения. На рис. 41 приведена простая схема, иллюстрирующая использование структурограмм и псевдокода.
Рис. 41. Управляющие структуры
Инструкции состоят из вызовов процедур и модулей, а также арифметических операций. Последние выполняются на уровне элементов данных. В зависимости от сложности управляющие структуры в модулях могут вкладываться одна в другую. «Листья» модульной сети содержат наиболее детальное описание, в то время как на более высоких уровнях содержимое модулей обычно состоит из управляющих структур и вызывающих инструкций.
На рис. 42 приведена метамодель управляющей структуры, объединяющая классы ТИП УПРАВЛЯЮЩЕЙ СТРУКТУРЫ, УРОВЕНЬ ИЕРАРХИИ и МОДУЛЬ. При этом управляющая структура охватывает весь блок инструкций. Модуль включают несколько управляющих структур, связанных с различными ступенями иерархии. Инструкции, принадлежащие управляющей структуре, обозначены связью 1:*.
Рис. 42. Метамодель управляющей структуры
А.2.1.3.3. Представление выхода
Требования к вводу и выводу определяются при описании дизайна и списков экрана. Примеры приведены на рис. 43 и 44.
Рис. 43. Пример экрана
Рис. 44. Пример списка
Экраны можно использовать для цела ввода и вывода. Несколько модулей могут применять для ввода и вывода один тип экрана, поэтому на диаграмме классов, приведенной на рис. 45, функции ввода и вывода и вывода характеризуется мощностью (0..*). Если типы экранов хранятся на местных языках, их конкретные экземпляры можно создавать путем различных комбинаций МЕСТНОГО ЯЗЫКА и ТИПА ЭКРАНА. Функциональные возможности Windows позволяют отобразить определенный ЭКРАН в рамках существующего экрана.
Рис. 45. Экраны и списки
Экраны можно интерпретировать как представления модели данных. Подробнее мы раскроем эту тему, при обсуждении отношения между моделями данных и моделями функций. Говоря же о взаимоотношениях между функциональными и организационными моделями, мы рассмотрим экраны и списки с позиции тех, кто получает или вводит данные.
А.2.1.4. Реализация на уровне функциональной модели
На стадии описания реализации разрабатываются фактические программы, подлежащие выполнению. Для этой цели в соответствии со спецификациями модулей используется один или несколько языков программирования (например, Си, C++, Java, ABAP4, Кобол). Если изначальные спецификации достаточно детализированы, они могут быть реализованы генератором приложений. В этом случае связующим звеном между описанием модуля определения требований, языком программирования и утилитой служит МОДУЛЬ ИСХОДНОГО КОДА (см. рис. 46). Однако если программирование выполняется исключительно программистами, то упоминать генератор приложений излишне.
Рис. 46. Преобразование модулей в исходный код
Модули исходного кода могут храниться в библиотеке программ в рамках репозиториев. БИБЛИОТЕКИ ПРОГРАММ, где хранятся все существующие программы или модули, значительно повышают многократную применимость модулей. Библиотеки программ можно использовать для описания модулей и на уровне спецификации проекта. На рис. 46 представлена связь с описанием модулей на уровне спецификации проекта.
С помощью КОМПИЛЯТОРОВ или ИНТЕРПРЕТАТОРОВ модули исходного кода преобразуются в МОДУЛИ ОБЪЕКТНОГО КОДА. Для каждого ЯЗЫКА ПРОГРАММИРОВАНИЯ возможны несколько компиляторов или интерпретаторов, например, для каждой аппаратной платформы. Из одного модуля исходного кода можно получить разные модули объектного кода.
Вообще, для обработки целой задачи необходимо несколько модулей, скомпилированных в единую программу. Класс ПРОГРАММА на рис. 46, представляет собой структуру репозитория для хранения физических программ.