Системы автоматизации проектирования ИС

http://5fan.ru/wievjob.php?id=39024

Автоматизированное проектирование ИС (CASE-технология) Определение. CASE-технология (Computer Aided Software Engineering) представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддержанную комплексом взаимоувязанных средств автоматизации. Основные черты CASE-технологии: Назначение: автоматизация проектирования сложных информационных систем. Изначально CASE-средства были ориентированы на разработку ПО. Сейчас чаще всего под такими средствами подразумевают любые средства проектирования ИС и/или моделирования предметной области. CASE-средства охватывают все стадии ЖЦ ИС (анализ, проектирование, разработка, сопровождение). Не создают новых методологий, а повышают эффективность использования существующих – за счет автоматизации. Цели использования CASE-технологии в индустриальном проектировании ИС: Улучшение качества разрабатываемой ИС за счет автоматического контроля и генерации отдельных элементов; Возможность повторного использования компонентов разработки; Повышение уровня адаптивности и качества сопровождения ИС; Использование методологии прототипного проектирования; Ускорение работы за счет автоматизированной генерации кода и автоматизированного документирования проекта; Возможность коллективной разработки ИС в режиме реального времени. Содержание CASE-технологии: Методология – определяет шаги реализации проекта, а также правила используемых при его разработки методов. Метод – процедура или техника генерации описания компонентов ИС (например, метод проектирования потоков данных). Модель – совокупность символов (вербальных, математических, графических и т.п.), которая адекватно описывает некоторые свойства моделируемого объекта и отношения между ними. Нотация – Система условных обозначений, принятая в конкретной модели. Обычно для описания моделей используются графические символы (почему?), а также формальные и естественные языки. Инструментальные средства – CASE-средства. Определение. CASE-средство – это специальный программный продукт, который поддерживает одну или несколько методологий анализа и проектирования ИС. Общая архитектура системы CASE-средств включает в себя следующие элементы: Репозиторий (словарь данных) – специализированная база данных, являющаяся ядром системы. Обеспечивает хранение версий проекта и его отдельных компонентов и объектов, синхронизацию поступающей от проектировщиков информации, контроль метаданных на полноту и непротиворечивость. Репозиторий хранит описания следующих объектов: Проектировщиков и их прав доступа к различным компонентам системы; Организационных структур; Диаграмм, компонентов диаграмм и связей между диаграммами; Структур данных; Программных модулей, процедур, библиотек и т.п. … Графические средства анализа и проектирования (редакторы диаграмм). Используются для создания иерархически связанных диаграмм – моделей ИС – в заданной графической нотации. Верификатор диаграмм. Служит для контроля правильности построения диаграмм в заданной методологии проектирования. Основные функции: мониторинга, диагностика, информирование об ошибках. Неграфические средства проектирования и разработки приложений. Используются для построения моделей ИС на формальных и естественных языках, а также для автоматизированной разработки программ проекта. Документатор проекта. Позволяет получать информацию о проекте в виде различных отчетов. Средства администрирования проектом. Представляют собой набор инструментов и служебных программ, необходимых для выполнения таких административных функций, как: Инициализация проекта; Задание начальных параметров проекта; Назначение и управление правами доступа к отдельным элементам проекта; Мониторинг выполнения проекта. Служебные средства. Представляют собой набор служебных программ, которые необходимы для обслуживания БД репозитория: архивация, восстановление данных и т.п. Классификация CASE-средств По области действия в пределах ЖЦ ИС Upper CASE – средства, используемые на стадии анализа предметной области; Middle CASE – средства, используемые на стадии анализа и проектирования структуры ИС; Примечание. В настоящее время в зарубежной литературе имеет место тенденция объединять средства Upper и Middle CASE в одну группу (Upper CASE). Lower CASE – средства, используемые на стадиях разработки и внедрения (тестирования). I-CASE – интегрированная система CASE-средств, которая может использоваться как на ранних, так и на поздних стадиях ЖЦ ИС (т.е. объединяет возможности Upper- и Lower- CASE). По функциональному назначению: Средства анализа и проектирования ИС (автоматизация наиболее популярных методологий проектирования); Средства проектирования баз данных (моделирование данных и генерация схем БД); Средства разработки приложений (в том числе, средства генерации и рефакторинга программного кода, средства быстрой разработки приложений); Средства обратного инжиниринга (построение моделей действующей ИС для ее переноса в другую среду); Средства документирования проекта; Средства управления тестированием ПО; Средства планирования и управления проектом. По поддерживаемым методологиям проектирования: Функционально-ориентированные; Объектно-ориентированные; Комплексные (поддерживают различные методологии). По степени интеграции: Отдельные средства, которые могут быть использованы на той или иной стадии проектирования ИС. Частично интегрированные наборы средств, охватывающие несколько стадий разработки ИС; Полностью интегрированные системы средств, охватывающие несколько стадий разработки ИС и связанные между собой общим репозиторием. По реализованной архитектуре: Локальные; Корпоративные (с поддержкой взаимодействия по корпоративным информационным сетям и возможностью коллективной разработки проекта). Методологии проектирования ИС с использованием CASE-средств В настоящее время существует два основных подхода к проектированию, которые мы уже упоминали: Функционально-ориентированный (структурный); Объектно-ориентированный. В основе функционально-ориентированного подхода лежат две идеи: Декомпозиция; Графическое представление. В настоящее время в качестве основных средств структурного анализа и проектирования используют следующие виды диаграмм: Business Function Diagram (BFD) – диаграммы функциональных спецификаций. Позволяют представить общую структуру исследуемого объекта, отражающую взаимосвязь различных задач в процессе получения требуемых результатов. Основные элементы BFD – это функции (некоторые действия, необходимые для решения поставленных задач) и декомпозиции функций (разбиение функции на множество подфункций). На практике диаграмма функциональных спецификаций, используется, например, для верификации диаграмм сущность-связь при проектировании базы данных ИС. Диаграммы SADT (диаграммы работ и объектов). Диаграммы потоков данных (DFD). State Transition Diagram (STD) – диаграммы переходов состояний. Моделируют поведение системы во времени в зависимости от произошедших событий. Позволяют осуществить декомпозицию управляющих процессов, происходящих в системе и описать отношение между управляющими потоками. С формальной точки зрения, диаграммы переходов состояний описывают некоторый конечный автомат. К основным элементам диаграммы перехода состояний относятся: Состояние – устойчивое значение некоторого свойства в течение определенного времени. В каждый момент времени система находится строго в одном состоянии. Находясь в текущем состоянии, необходимо знать о предыдущих состояниях, чтобы определить условие перехода в следующее состояние. Начальное состояние – узел диаграммы, являющийся стартовой точкой для начального системного перехода. В диаграмме может быть множество конечных состояний, но только одно начальное. Переход – определяет перемещение моделируемой системы из одного состояния в другое. Имя перехода определяется событием, которое вызвало этот переход. Переход может быть вызван каким-либо действием. Триггер – логическое выражение, написанное на каком-либо макроязыке, которое показывает условие перехода в данное состояние. Применяется два способа построения ST-диаграммы. Первый способ заключа­ется в идентификации всех возможных состояний и дальнейшем исследо­вании всех не бессмысленных связей (переходов) между ними. По второ­му способу сначала строится начальное состояние, затем следующие за ним и т.д. В результате формируется предварительная диаграмма перехода состояний, для которой необходимо выполнить контроль состоятельности. Обычно он заключается в отве­те на следующие вопросы; все ли состояния определены и имеют уникальное имя? все ли состояния достижимы? все ли состояния имеют выход? реагирует ли система соответствующим об­разом на все возможные условия (особенно на ненормальные)? все ли входные (выходные) потоки управляющего процесса отражены в условиях диаграммы? Примеры диаграммы переходов состояний: См. рис. 1 Диаграммы состояний UML. Диаграммы инфологических моделей «сущность-связь». System Structure Diagram (SSD) – Диаграммы структуры программного приложения ИС. Представляют собой иерархическую взаимосвязь программных модулей, которые реализуют ИС. Диаграмма SSD служит «мостом» для перехода от системных требований, которые отображены в таких диаграммах, как BFD, DFD, ERD и STD, к реализации информационной системы. Основные черты Объектно-ориентированного проектирования Предметная область моделируется как совокупность взаимодействующих во времени объектов; Процесс обработки информации представляется как последовательность взаимодействий этих объектов; Данные и операции моделируются совместно (неразрывно друг от друга); За основу принимается спиральная модель проектирования. Модели предметной области накапливаются в репозитории и постепенно уточняются. На основе сформированных моделей может быть автоматически сгенерирована система классов для программного приложения ИС; Для моделирования широко используется унифицированный язык моделирования UML (Unified Modeling Language).

Источник: http://5fan.ru/wievjob.php?id=39024