Автоматизированное проектирование ис (case-технология)

Вид материала

Документы

Содержание Документатор проекта Основные черты Объектно-ориентированного проектирования

Подобный материал:

• Рабочая программа по дисциплине «Физика» для направления подготовки дипломированного, 282.66kb.
• Егорова Ю. Н., Егорова, 50.21kb.
• Integrated Computer Aided definition Method -методология интегрального описания, интегральной, 259.09kb.
• Современные case-технологии, 247.63kb.
• Методические указания к курсовой работе по дисциплинам: «Техническое обеспечение, 321.66kb.
• Основная образовательная программа высшего профессионального образования Направление, 787.83kb.
• Рабочая программа дисциплины «Организация, технология и проектирование предприятий», 333.31kb.
• Программа подготовки к экзамену по дисциплине «организация, технология и проектирование, 42.62kb.
• Ватин Николай Иванович. Цель и концепция программы программа, 151.89kb.
• Рабочая программа учебной дисциплины «автоматизированное проектирование электромеханических, 129.91kb.

Автоматизированное проектирование ИС (CASE-технология)


Определение. CASE-технология (Computer Aided Software Engineering) представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддержанную комплексом взаимоувязанных средств автоматизации.


Основные черты CASE-технологии:

• Назначение: автоматизация проектирования сложных информационных систем. Изначально CASE-средства были ориентированы на разработку ПО. Сейчас чаще всего под такими средствами подразумевают любые средства проектирования ИС и/или моделирования предметной области.
  
• CASE-средства охватывают все стадии ЖЦ ИС (анализ, проектирование, разработка, сопровождение).
  
• Не создают новых методологий, а повышают эффективность использования существующих – за счет автоматизации.
  

Цели использования CASE-технологии в индустриальном проектировании ИС:

• Улучшение качества разрабатываемой ИС за счет автоматического контроля и генерации отдельных элементов;
  
• Возможность повторного использования компонентов разработки;
  
• Повышение уровня адаптивности и качества сопровождения ИС;
  
• Использование методологии прототипного проектирования;
  
• Ускорение работы за счет автоматизированной генерации кода и автоматизированного документирования проекта;
  
• Возможность коллективной разработки ИС в режиме реального времени.
  

Содержание CASE-технологии:

• Методология – определяет шаги реализации проекта, а также правила используемых при его разработки методов.
  
• Метод – процедура или техника генерации описания компонентов ИС (например, метод проектирования потоков данных).
  
• Модель – совокупность символов (вербальных, математических, графических и т.п.), которая адекватно описывает некоторые свойства моделируемого объекта и отношения между ними.
  
• Нотация – Система условных обозначений, принятая в конкретной модели. Обычно для описания моделей используются графические символы (почему?), а также формальные и естественные языки.
  
• Инструментальные средства – CASE-средства.
  

Определение. CASE-средство – это специальный программный продукт, который поддерживает одну или несколько методологий анализа и проектирования ИС.


Общая архитектура системы CASE-средств включает в себя следующие элементы:

• Репозиторий (словарь данных) – специализированная база данных, являющаяся ядром системы. Обеспечивает хранение версий проекта и его отдельных компонентов и объектов, синхронизацию поступающей от проектировщиков информации, контроль метаданных на полноту и непротиворечивость. Репозиторий хранит описания следующих объектов:
  
  • Проектировщиков и их прав доступа к различным компонентам системы;
    
  • Организационных структур;
    
  • Диаграмм, компонентов диаграмм и связей между диаграммами;
    
  • Структур данных;
    
  • Программных модулей, процедур, библиотек и т.п.
    
  • …
    
• Графические средства анализа и проектирования (редакторы диаграмм). Используются для создания иерархически связанных диаграмм – моделей ИС – в заданной графической нотации.
  
• Верификатор диаграмм. Служит для контроля правильности построения диаграмм в заданной методологии проектирования. Основные функции: мониторинга, диагностика, информирование об ошибках.
  
• Неграфические средства проектирования и разработки приложений. Используются для построения моделей ИС на формальных и естественных языках, а также для автоматизированной разработки программ проекта.
  
• ^ Документатор проекта. Позволяет получать информацию о проекте в виде различных отчетов.
  
• Средства администрирования проектом. Представляют собой набор инструментов и служебных программ, необходимых для выполнения таких административных функций, как:
  
  • Инициализация проекта;
    
  • Задание начальных параметров проекта;
    
  • Назначение и управление правами доступа к отдельным элементам проекта;
    
  • Мониторинг выполнения проекта.
    
• Служебные средства. Представляют собой набор служебных программ, которые необходимы для обслуживания БД репозитория: архивация, восстановление данных и т.п.
  

Классификация CASE-средств

1. По области действия в пределах ЖЦ ИС
   

• Upper CASE – средства, используемые на стадии анализа предметной области;
  
• Middle CASE – средства, используемые на стадии анализа и проектирования структуры ИС;
  

Примечание. В настоящее время в зарубежной литературе имеет место тенденция объединять средства Upper и Middle CASE в одну группу (Upper CASE).

• Lower CASE – средства, используемые на стадиях разработки и внедрения (тестирования).
  
• I-CASE – интегрированная система CASE-средств, которая может использоваться как на ранних, так и на поздних стадиях ЖЦ ИС (т.е. объединяет возможности Upper- и Lower- CASE).
  

2. По функциональному назначению:
   

• Средства анализа и проектирования ИС (автоматизация наиболее популярных методологий проектирования);
  
• Средства проектирования баз данных (моделирование данных и генерация схем БД);
  
• Средства разработки приложений (в том числе, средства генерации и рефакторинга программного кода, средства быстрой разработки приложений);
  
• Средства обратного инжиниринга (построение моделей действующей ИС для ее переноса в другую среду);
  
• Средства документирования проекта;
  
• Средства управления тестированием ПО;
  
• Средства планирования и управления проектом.
  

3. По поддерживаемым методологиям проектирования:
   

• Функционально-ориентированные;
  
• Объектно-ориентированные;
  
• Комплексные (поддерживают различные методологии).
  

4. По степени интеграции:
   

• Отдельные средства, которые могут быть использованы на той или иной стадии проектирования ИС.
  
• Частично интегрированные наборы средств, охватывающие несколько стадий разработки ИС;
  
• Полностью интегрированные системы средств, охватывающие несколько стадий разработки ИС и связанные между собой общим репозиторием.
  

5. По реализованной архитектуре:
   

• Локальные;
  
• Корпоративные (с поддержкой взаимодействия по корпоративным информационным сетям и возможностью коллективной разработки проекта).
  

Методологии проектирования ИС с использованием CASE-средств


В настоящее время существует два основных подхода к проектированию, которые мы уже упоминали:

• Функционально-ориентированный (структурный);
  
• Объектно-ориентированный.
  

В основе функционально-ориентированного подхода лежат две идеи:

• Декомпозиция;
  
• Графическое представление.
  

В настоящее время в качестве основных средств структурного анализа и проектирования используют следующие виды диаграмм:

• Business Function Diagram (BFD) – диаграммы функциональных спецификаций. Позволяют представить общую структуру исследуемого объекта, отражающую взаимосвязь различных задач в процессе получения требуемых результатов. Основные элементы BFD – это функции (некоторые действия, необходимые для решения поставленных задач) и декомпозиции функций (разбиение функции на множество подфункций). На практике диаграмма функциональных спецификаций, используется, например, для верификации диаграмм сущность-связь при проектировании базы данных ИС.
  
• Диаграммы SADT (диаграммы работ и объектов).
  
• Диаграммы потоков данных (DFD).
  
• State Transition Diagram (STD) – диаграммы переходов состояний. Моделируют поведение системы во времени в зависимости от произошедших событий. Позволяют осуществить декомпозицию управляющих процессов, происходящих в системе и описать отношение между управляющими потоками. С формальной точки зрения, диаграммы переходов состояний описывают некоторый конечный автомат. К основным элементам диаграммы перехода состояний относятся:
  
  • Состояние – устойчивое значение некоторого свойства в течение определенного времени. В каждый момент времени система находится строго в одном состоянии. Находясь в текущем состоянии, необходимо знать о предыдущих состояниях, чтобы определить условие перехода в следующее состояние.
    
  • Начальное состояние – узел диаграммы, являющийся стартовой точкой для начального системного перехода. В диаграмме может быть множество конечных состояний, но только одно начальное.
    
  • Переход – определяет перемещение моделируемой системы из одного состояния в другое. Имя перехода определяется событием, которое вызвало этот переход. Переход может быть вызван каким-либо действием.
    
  • Триггер – логическое выражение, написанное на каком-либо макроязыке, которое показывает условие перехода в данное состояние.
    

Применяется два способа построения ST-диаграммы. Первый способ заключа­ется в идентификации всех возможных состояний и дальнейшем исследо­вании всех не бессмысленных связей (переходов) между ними. По второ­му способу сначала строится начальное состояние, затем следующие за ним и т.д. В результате формируется предварительная диаграмма перехода состояний, для которой необходимо выполнить контроль состоятельности. Обычно он заключается в отве­те на следующие вопросы;

• все ли состояния определены и имеют уникальное имя?
  
• все ли состояния достижимы?
  
• все ли состояния имеют выход?
  
• реагирует ли система соответствующим об­разом на все возможные условия (особенно на ненормальные)?
  
• все ли входные (выходные) потоки управляющего процесса отражены в условиях диаграммы?
  

Примеры диаграммы переходов состояний:

1. См. рис. 1
   
2. Диаграммы состояний UML.
   

• Диаграммы инфологических моделей «сущность-связь».
  
• System Structure Diagram (SSD) – Диаграммы структуры программного приложения ИС. Представляют собой иерархическую взаимосвязь программных модулей, которые реализуют ИС. Диаграмма SSD служит «мостом» для перехода от системных требований, которые отображены в таких диаграммах, как BFD, DFD, ERD и STD, к реализации информационной системы.
  

^ Основные черты Объектно-ориентированного проектирования

• Предметная область моделируется как совокупность взаимодействующих во времени объектов;
  
• Процесс обработки информации представляется как последовательность взаимодействий этих объектов;
  
• Данные и операции моделируются совместно (неразрывно друг от друга);
  
• За основу принимается спиральная модель проектирования. Модели предметной области накапливаются в репозитории и постепенно уточняются.
  
• На основе сформированных моделей может быть автоматически сгенерирована система классов для программного приложения ИС;
  
• Для моделирования широко используется унифицированный язык моделирования UML (Unified Modeling Language).
  

Самостоятельно:

• Изучить, какие основные диаграммы включает в себя система объектно-ориентированных моделей в соответствии с нотациями UML;
  
• Изучить общую характеристику и назначение каждой диаграммы;
  
• Обратить внимание на диаграмму прецедентов, диаграмму состояний, диаграмму деятельности, диаграмму компонентов и диаграмму размещения.
  
• Рассмотреть общую схему проектирования экономических ИС в рамках объектно-ориентированного подхода.
  

Рис.1. Пример диаграммы перехода состояний.