А.2.1.3. Определение требований на уровне функциональной модели
Определение требований к функциям можно проектировать на различных уровнях вертикальной иерархии, построенной по принципу «сверху вниз». По-другому это называется проектированием программного обеспечения, поскольку функции впоследствии реализуются в структуре подпрограммы. В этом значении широко применяется термин «крупномасштабное программирование», тогда как последующая реализация на языке программирования называется «мелкомасштабным программированием» ( Balzert . Lehrbuch der Software-Technik. 1996, с. 632, 927).
Ключевыми этапами проектирования являются построение структуры модуля, детальное проектирование содержимого модуля и выдача отчета.
Функции, преобразующие входные данные в выходные, особенно тесно связаны с моделью данных. При определении требований учитываются также существующие ограничения ИС. Эти связи ослабевают, если придерживаться принципа абстрагирования, что позволяет создавать концепцию функции, не располагая знаниями о модели данных или о конкретной архитектуре оборудования. Иными словами, следует рассматривать только общие свойства смежных архитектурных моделей, а не их конкретные экземпляры. Это достигается абстрагированием данных, при котором описывается только тип данных, но не их физическая реализация. Скажем, для описания интерфейсов функции можно обозначить элемент данных «номер клиента» целым числом, не конкретизируя устройство, отвечающее за этот элемент, например, тип сущности КЛИЕНТ, имя отношения, тип записи или даже адрес записи и обозначение поля. То же самое справедливо для аппаратных компонентов, где при описании функций экранов можно задать виртуальный терминал с базовыми свойствами, но указывать конкретную модель терминала необязательно.
|
|
|
А.2.1.3.1. Проектирование модулей
Одним из центральных элементов проектирования программного обеспечения является модуль, четко описывающий автономный функциональный конструктивный блок для входящих и выходящих данных. Модули соответственно включают следующие компоненты: описание данных, управляющую логику и инструкции. Создание модулей согласуется с принципом локальности и многократного использования, поскольку модули можно использовать для разных прикладных функций. При описании входящих и исходящих данных, предоставляемых в распоряжение пользователя, соблюдается также принцип «сокрытия информации», т.е. описывается, что делает модуль, а не как он это делает.
Модули следует проектировать таким образом, чтобы максимизировать их «внутреннее действие» и минимизировать взаимодействие между ними. При проектировании модулей можно пользоваться методом «сверху вниз» или «снизу вверх». При методе «сверху вниз» проектирование начинается с самого верхнего уровня и постепенно детализируется по мере продвижения вниз. Конечным результатом являются базовые модули, которые можно реализовать с помощью существующих объектов базового программного обеспечения.
|
|
|
При методе «снизу вверх» модули сначала проектируются на самом нижнем уровне, а затем объединяются в модули следующего лежащего выше уровня. Методы «снизу вверх» особенно удобны для работы с уже заполненными архивами модулей, из которых извлекаются базовые модули, компонуемые затем в более крупные блоки (Blazer. Lerhbuch der Software-Technik. 1996, с. 853).
Применительно к модулям иногда используется термин «процедура»; модули верхнего уровня называют также программами. Возможен широкий ряд различных определений. На рис. 37 приведен пример очень детальной иерархии описания.
| · Класс прикладной системы · Тип прикладной системы · Прикладная система · Класс модуля · Тип модуля · Модуль | например, текстовый процессор Word и т.д. например, MS Word for Windows 6.0 и т.д. например, MS Word for Windows 6.0 на ПК № 3417 и т.д. например, программа проверки правописания и т.д. например, программа проверки правописания для MS Word for Windows 7.0 и т.д. например, программа проверки правописания для MS Word for Windows 6.0 на ПК № 3417 и т.д. |
Рис . 37. Иерархия описания модулей
|
|
|
На уровне определения требований можно задать направление процесса проектирования, поскольку он допускает как восходящие, так и нисходящие методы. Выходные данные модуля проектируются в рамках этой иерархии функций. На рис. 38 мы выбрали для выходных данных класс ОБЩАЯ ФУНКЦИЯ. Здесь «общая функция» означает описание функции безотносительно к контексту конкретного бизнес-процесса. Это подчеркивает «принцип многократной применимости», который должен быть воплощен в модуле.
Поскольку модули создаются только для функций, поддерживающих информационные технологии, требуется уточнение, позволяющее получить связь с классом ОБЩАЯ СИСТЕМНАЯ ФУНКЦИЯ, Связь *;* с минимальной мощностью 1 означает, что благодаря многократной применимости один модуль можно использовать в разных системных функциях и одна j системная функция может поддерживаться различными модулями. Связь *:* между системными функциями и модулями показывает также, что проектирование бизнеса и проектирование ИТ до определенной степени не зависят друг от друга.
|
|
|
Рис . 38. Связь между модулями и функциями
Модули могут быть дифференцированы на подтипы и посредством отношений вызова соединены друг с другом в сети. На рис.39 показана структурная диаграмма, где модули представлены прямоугольниками. Существующие модули, к которым имеется доступ, обозначены по краям двойными линиями.
Представление с помощью структурных диаграмм приобрело широкую популярность благодаря работе Константине и Йордона, посвященной сложному (структурированному) проектированию (Constantine, Yourdon. Structured Design. 1979; о структурированном проектирование см. Page-Jones. Practical Guide to Structured System Design. 1980; Balzert. Lehrbuch der Software-Technik. 1996, c. 801-862; Sommerville. Software Engineering. 1987, c . 75-103). Представление упрощается с помощью операторов (в данном случае - для оперативной обработки). Взаимодействие между модулями обозначено стрелками с указанием передаваемых данных, причем стрелки соответствуют простым связям данных. Можно также использовать управляющие связи и динамичные параметры (т.е. параметры, требующиеся для ввода или вывода). При чрезмерно сложных взаимоотношениях данные можно пронумеровать и поместить в таблицы.
Рис . 39. Представление модулей с помощью структурных диаграмм
Представленные на рис. 39 операторы А, В и С связаны с операциями доступа и абстрагируют данные, т.е. обозначают данные вместе с операциями, для которых они предназначены. Ромб в модуле продаж обозначает управляющую структуру выбора.
Иерархические отношения между модулями вытекают из направления вызова (обращений). Модули на верхних уровнях вызывают модули следующего лежащего ниже уровня. Стрелка, связывающая модули, указывает направление процесса вызова.
Иерархии модулей создаются в соответствии с единообразными параметрами типа «отношение вызывает» или «имеет компонент, именуемый».
В рамках иерархий вызовов модули выполняют часть своих задач с помощью собственного программного кода; остальная часть реализуется путем вызова функций других модулей ( Lockemann , Dittrich . Architektur van Datenbanksystemen. 1987, с. 102).
В иерархии компонентов только «листья» иерархии модулей описаны инструкциями. Таким образом, зависимости вызовов (обращений) в иерархии компонентов не всегда очевидны. Обзор различных этапов разбиения модулей дан в работе Lockemann , Dittrich . Architektur von Datenbanksystemen. 1987, с. 103.
На рис. 40 представлена классификация модулей при помощи связи 1:* между классами МОДУЛЬ и ТИП МОДУЛЯ с разбивкой на модули манипулирования данными, модули обработки данных и оперативные модули.
Рис . 40. Классификация модулей
Отношения между модулями характеризуются связью КОММУНИКАЦИЯ.
Класс ТИП КОММУНИКАЦИИ характеризует тип связи (например, простые связи данных или управляющие связи). Обмениваемые данные идентифицируются по атрибуту «имя данных». Хотя каждый коммуникационный набор может передавать только дату, этим наборам можно присваивать номера элементов. Для этой цели ассоциативный класс связывается с классом ЭЛЕМЕНТ.
Структурные диаграммы являются лишь одним из нескольких методов проектирования систем, однако разрабатываемые на их основе структуры классов носят настолько общий характер, что позволяют моделировать другие методы на базе той же логики (дополнительные языки спецификации приведены в работе: Sommerville . Software Engineering. 1987, с . 77, 106).
Помимо термина «модуль», мы можем также использовать понятие «программа». Вообще говоря, программы — это полные наборы инструкций, содержащие все необходимые требования для решения задач (Stetter. Softwaretechnologie . 1987, с. 12-16). Когда программы состоят из подпрограмм, взаимодействующих друг с другом, они образуют классы программ или прикладных систем. Подпрограммы, которые отвечают требованиям, предъявляемым к модулям, называются «модульными».
Степень детализации в проектах модулей зависит от типа обработки. Транзакции, предполагающие последовательные этапы обработки пользователем, предназначены для оперативной обработки. В зависимости от степени детализации проекта транзакции могут соответствовать нижней ступени иерархии в классификации бизнес-процесса (элементарная функция).
Количество классификаций в спецификации проекта зависит также от конкретных реализуемых информационных систем. Некоторые мониторы транзакций лучше справляются с обработкой множества мелких транзакций, другие — с обработкой более крупных транзакций, но в меньшем количестве (Olle et al. Information Systems Methodologies. 1991, с. 256).
Однако при разработке спецификаций проекта влияние конкретных особенностей ИТ следует учитывать лишь до определенной степени.
А.2.1.3.2. Мини-спецификация
В проектах ИС содержимое модулей описывается посредством мини-спецификаций. К числу общеупотребительных методов относится описание управляющих структур (управляющих алгоритмическими процессами) и исполняющих инструкций при помощи псевдокода и структурограмм. В качестве управляющих структур могут служить последовательности, инструкции выбора и повторения. На рис. 41 приведена простая схема, иллюстрирующая использование структурограмм и псевдокода.
Рис . 41. Управляющие структуры
Инструкции состоят из вызовов процедур и модулей, а также арифметических операций. Последние выполняются на уровне элементов данных. В зависимости от сложности управляющие структуры в модулях могут вкладываться одна в другую. «Листья» модульной сети содержат наиболее детальное описание, в то время как на более высоких уровнях содержимое модулей обычно состоит из управляющих структур и вызывающих инструкций.
На рис. 42 приведена метамодель управляющей структуры, объединяющая классы ТИП УПРАВЛЯЮЩЕЙ СТРУКТУРЫ, УРОВЕНЬ ИЕРАРХИИ и МОДУЛЬ. При этом управляющая структура охватывает весь блок инструкций. Модуль включают несколько управляющих структур, связанных с различными ступенями иерархии. Инструкции, принадлежащие управляющей структуре, обозначены связью 1:*.
Рис . 42. Метамодель управляющей структуры
Дата добавления: 2019-02-26; просмотров: 167; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!