Структурний підхід до проектування
Разработка автоматизированных систем (АС) выполнялась и выполняется на основе положений, представленных в стандарте ГОСТ 34.601-90. Он состоит из стадий и этапов разработки АС, которые, в зависимости от особенностей автоматизируемой системы, можно объединять друг с другом или вообще не включать в процесс разработки. Основанием для разработки АС является договор между разработчиком системы и ее заказчиком. Этапами стандарта, ориентированным на разработку архитектуры АС, являются: формирование требований к АС, разработка концепции АС и проектирование технического проекта, в котором на основе сформулированных требований и концепций их реализации задаются конкретные задачи системы и пути их решения. Эти этапы заканчивается созданием и утверждением отчета о научно-исследовательской работе, в которой дается оценка необходимых для реализации АС ресурсов, вариантов разработки АС и порядка проведения оценки качества системы. На этапе разработки эскизного проекта используются проектные решения ко всей системе или ее части и определяется перечень задач системы, концепция информационной базы, функции и параметры основных программных компонентов системы, а также основные алгоритмы обработки информации. Этап разработки технического проекта предусматривает разработку проектных решений относительно системы и ее частей, разработку документации на АС и комплектацию АС, а также определение технических требований на систему и проектирование задач для смежных частей проекта. Проектные решения определяют организационную структуру, функции персонала АС, структуру технических средств, языка программирования, СУБД, общие характеристики ПО, систему классификации и кодирования, а также варианты ведения информационной базы системы. Таким образом, данный стандарт обеспечивает: - концептуальное проектирование, которое состоит в уточнении и согласовании деталей требований; - архитектурное проектирование, которое состоит в определении главных структурных особенностей создаваемой системы; - техническое проектирование, которое состоит в отображении требований на среду функционирования системы и определении задач и принципов их реализации; - детальное проектирование, которое состоит в определении алгоритмов задач, построения БД и программного обеспечения системы. При концептуальном проектировании определяются: - источники поступления данных от заказчика, который несет ответственность за их достоверность; - объекты системы и их атрибуты; - способы материализации связей между объектами и виды организации данных. - интерфейсы с потенциальными пользователями системы на ранних стадиях ЖЦ цикла разработки системы для оказания им помощи при формулировки целей и функций системы; - правила взаимодействия пользователя и системы с точки зрения понимания, эффективности и скорости реакции системы. Организация интерфейсов базируется на определенных ключевых элементах, определение которых предшествует проектированию конкретных экранов и форматов обмена данными, в частности: 1) значащие термины, образы и понятия, которые являются для пользователя понятными и распространенные в домене; 2) ментальная модель организации и представления данных, функций и ролей; 3) правила навигации (просмотра) данных, функций и ролей; 4) визуальные приемы демонстрации пользователю элементов системы; 5) методы взаимодействия, которые отвечают требованиям пользователей будущей системы. При архитектурном проектировании системы принимаются во внимание конкретные интерфейсы, учитывающие такие аспекты, как традиции, обычаи, особенности домена и присущие ему действующие лица. В частности, пользователю определенный психологический комфорт предоставляют языковых форматы в меню и иконах интерфейсов, а также метрические показатели систем измерений и др. Правила навигации должны учитывать традиции чтения слева - направо или наоборот. Таким образом, общей рекомендацией концепций проектирования является построение полностью всех экранных форм системы и "проигрывание" с пользователем для выбора разных вариантов, отвечающих его вкусам. Такой выбор часто входит в в противоречие с заданными характеристиками интерфейса (например, удобство доступа и обеспечение конфиденциальности, быстродействие и сложность обработки и др.). Для построения интерфейсов существует широкий выбор методов и средств. Большинство из них базируется на фиксации определенных классов объектов интерфейса (выбор из меню, заполнение экранных форм и др.) и средствах монтирования их в программную систему в виде интегрированных блоков или автономных подсистем интерфейса с пользователем. При техническом проектировании системы на основе модели представления требований и понятий объектно-ориентированного подхода проводится уточнение состава и содержания функций, присущих им операций (методов), а также схем взаимодействия объектов. Содержание операций, которые способны выполнять объекты, может быть раскрыто с помощью диаграмм потоков данных. Взаимодействие объектов организовывается путем обмена сообщений, в ответ на которые они выполняют соответствующие операции и изменяют свое состояние, или посылают сообщения другим объектам. Для уточнения поведения объектов можно использовать ряд диаграмм, отображающих различные аспекты взаимодействия объектов. Такие диаграммы входят в состав метода UML. Определяются нефункциональные требования, задающие определенные ограничения структурой организации системы или среды использования. К отдельным разновидностям нефункциональных требований относятся требования секретности, безопасности, отказоустойчивости, корпоративной работы над общими ресурсами и др. При построении моделей требований для автоматизированных систем учитывается их роль и место в прикладных приложениях системы. Для них разработано немало национальных, корпоративных и ведомственных стандартов, которые фиксируют правила обеспечения защиты данных, безопасности системы и др. Результатом формирования нефункциональных требований может быть расширение модели требований дополнительными сведениями или соответствующими объектами, выполняющими требования взаимодействия, безопасности, защиты данных и др. Сущность структурного подхода разработки ПС заключается в декомпозиции (разбиении) системы на автоматизируемые функции, которые в свою очередь делятся на подфункции, на задачи и так далее. Процесс декомпозиции продолжается вплоть до определения конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимосвязаны. В основу структурного подхода положены такие общие принципы: - разбивка системы на множество независимых задач, легких для понимания и решения; - иерархическое упорядочивание, т.е. организация составных частей проблемы в древовидные структуры с добавлением новых деталей на каждом уровне. В основе этих принципов лежат операции: - абстрагирования, т.е. выделения существенных аспектов системы и отвлечения от несущественных; - формализации, т.е строгое методологическое решение проблемы; - непротиворечивости, состоящей в обосновании и согласовании элементов системы; - структуризации данных (т.е. данные должны быть структурированы и иерархически организованы). При структурном анализе применяются в основном три вида наиболее распространённых моделей проектирования ПС: SADT (Structured Analysis and Design Technique) модель и соответствующие функциональные диаграммы; SSADM (Structured Systems Analysis and Design Method) - метод структурного анализа и проектирования; IDEF0 (Integrated Definition Functions) метод создания функциональной модели, IDEF1 - информационной модели, IDEF2 - динамической модели и др. На стадии проектирования эти модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм. Метод функционального моделирования SADT. На основе метода SADT, предложенного Д. Россом, разработана методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США. Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т. е. производимые им функции и действия, а также связи между ними. Основные элементы этого метода основываются на следующих концепциях: - графическое представление блочного моделирования. Графическая диаграмма отображает функцию в виде блока, а интерфейсы (вход/выход) представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются; - строгость и точность. Правила SADT строги и имеют ограничения на количество блоков на каждом уровне декомпозиции (от 3 до 6 блоков) и связность диаграмм через номера блоков; - уникальность меток и наименований; - разделение входов и управлений (определение роли данных). - отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель. Метод SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет требованиям и реализует эти функции. Для действующих систем SADT может быть использоваться при анализе функций, выполняемых системой, а также для определения механизмов, посредством которых они осуществляются. Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), осуществляющий операцию, представляется дугой, входящей в блок снизу (рис.5.1).
Метод SSADM базируется на таких структурных диаграммах: последовательность, выбор и итерация. Моделируемый объект задается их сгруппированной последовательностью, следующих друг за другом, операторами выбора элемента из группы и циклическим выполнением отдельных элементов. Базовая диаграмма является иерархической и включает в себя следующие: список всех компонентов описываемого объекта; идентифицированные группы выбранных и повторяемых компонентов, а также последовательных компонентов. Модель процесса проектирования включает в себя: - определение функций; - моделирование взаимосвязей событий и сущностей; - логическое проектирование данных; - проектирование диалога; - логическое проектирование БД; - физическое проектирования. В основе стратегического проектирования лежит анализ и определение требований. Определяется область действия приложения, существующие информационные потоки, формирование общего представления о затратах на разработку и подтверждение возможности дальнейшего использования приложения. Результатом является спецификация требований, которая применяется для логической спецификации системы. Логическое проектирование включает в себя в себя проектирование диалога и процесса обновления БД. Проектирование состоит в создании логической модели и спецификации, в которой отображены входные и выходные данные, процессы выполнения запросов и процессов обновления на основе логической БД. Одной из целей логического проектирования является минимизация дублирования трудозатрат при физическом проектировании, обеспечение целостности на основе установления взаимосвязей между событиями и сущностями. Физическое проектирование состоит в определении типа СУБД, необходимого для представления сущностей и связей между ними при соблюдении спецификации логической модели данных и учета ограничений на память и время обработки. Предусматривается реструктуризация проекта в целях изменения механизмов доступа, повышения производительности, объема логической структуры, добавление связей и документирования. Физическая спецификация включает в себя: - спецификацию функций и схемы реализации компонентов функций, - описание процедурных и непроцедурных компонентов и интерфейсов, - определение логических и физических групп данных с учетом ограничений оборудования и стандартов на разработку, - определение групп событий, которые обрабатываются как единое целое с выдачей сообщений о завершении обработки и др. Проект системы представляется структурной моделью, задающей работы и взаимосвязи между этими работами в виде потоков проектных документов, отображенных в сетевом графике, а также модули, стадии и шаги проектирования, которые соответствуют ЖЦ.
|
