20441

Эволюция CASE-средств

Доклад

Информатика, кибернетика и программирование

Таким образом CASEтехнологии не могут считаться самостоятельными методологиями они только делают более эффективными пути их применения. CASE ≈ не революция в программо технике: современные CASEсредства являются естественным продолжением эволюции всей отрасли средств разработки ПО. Традиционно выделяют шесть периодов качественно отличающихся применяемой техникой и методами разработки ПО которые характеризуются использованием в качестве инструментальных следующих средств: ассемблеров дампов памяти анализаторов компиляторов...

Русский

2013-07-25

99.5 KB

18 чел.

12 13

Эволюция CASE-средств

    С самого начала CASE-технологии развивались за счет автоматизации и интеграции поддерживающих средств. Таким образом CASE-технологии не могут считаться самостоятельными методологиями, они только делают более эффективными пути их применения. CASE ≈ не революция в программо технике: современные CASE-средства являются естественным продолжением эволюции всей отрасли средств разработки ПО. Традиционно выделяют шесть периодов, качественно отличающихся применяемой техникой и методами разработки ПО, которые характеризуются использованием в качестве инструментальных следующих средств:

  1.  ассемблеров, дампов памяти, анализаторов
  2.  компиляторов, интерпретаторов, трассировщиков
  3.  символических отладчиков, пакетов программ
  4.  систем анализа и управления исходными текстами
  5.  CASE-средств анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (первая генерация CASE-I)
  6.  CASE-средств генерации исходных текстов и реализации интегрированного окружения поддержки полного жизненного цикла (ЖЦ) разработки ПО (вторая генерация CASE-II)

    CASE-I является первой технологией, адресованной непосредственно системным аналитикам и проектировщикам, и включающей средства для поддержки графических моделей, проектирования спецификаций, экранных редакторов и словарей данных. Она не предназначена для поддержки полного ЖЦ и концентрирует внимание на функциональных спецификациях и начальных шагах проекта ≈ системном анализе, определении требований, системном проектировании, логическом проектировании БД.
    CASE-II отличается значительно более развитыми возможностями, улучшенными характеристиками и исчерпывающим подходом к полному ЖЦ. В ней в первую очередь используются средства поддержки автоматической кодогенерации, а также обеспечивается полная функциональная поддержка порождения графических системных требований и спецификаций проектирования; контроля, анализа и связывания системной информации, а также информации по управлению проектированием; построения прототипов и моделей системы; тестирования, верификации и анализа сгенерированных программ; генерации документов по проекту; контроля на соответствие стандартам по всем этапам ЖЦ. CASE-11 может включать свыше 100 функциональных компонентов, поддерживающих все этапы ЖЦ, при этом пользователям предоставляется возможность выбора необходимых средств и их интеграции в нужном составе.
 

CASE-модель жизненного цикла ПО

    CASE-технологии предлагают новый, основанный на автоматизации подход к концепции ЖЦ ПО. При использовании CASE изменяются все фазы ЖЦ, при этом наибольшие изменения касаются фаз анализа и проектирования. На рис. 11.1 приводится простейшая модель ЖЦ (рис. 1 1. la) и соответствующая CASE-модель (рис.II.16), в которой фаза прототипирования заменяет традиционную фазу системного анализа. Необходимо отметить, что наиболее автоматизируемыми фазамиявляются фазы контроля проекта и кодогенерации (хотя все остальные фазы также поддерживаются CASE-средствами).

    В таблице 11.1 приведены оценки трудозатрат по фазам ЖЦ . Первая строка таблицы соответствует традиционной разработке, вторая ≈ разработке с использованием структурных методологий проектирования, третья ≈ разработке с использованием CASE-технологии. В таблицу 11.2 сведены основные изменения в ЖЦ при использовании CASE-технологии по сравнению с традиционной разработкой.

Состав, структура и функциональные особенности CASE-средств

    CASE-средства служат инструментарием для поддержки и усиления методов структурного анализа и проектирования. Эти инструменты поддерживают работу пользователей при создании и редактировании графического проекта в интерактивном режиме, они способствуют организации проекта в виде иерархии уровней абстракции, выполняют проверки соответствия компонентов. Фактически CASE-средства представляют собой новый тип графически-ориентированных инструментов, восходящих к системе поддержки ЖЦ ПО. Обычно к ним относят любое программное средство, обеспечивающее автоматическую помощь при разработке ПО, его сопровождении или деятельности по управлению проектом, и проявляющее следующие дополнительные черты:

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

Помимо перечисленных основополагающих принципов графической ориентации, интеграции и локализации всей проектной информации в репозитарии в основе концептуального построения CASE-средств лежат следующие положения:

  1.  Человеческий фактор, определяющий разработку ПО как легкий, удобный и экономичный процесс.
  2.  Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний, языки четвертого поколения и др).
  3.  Автоматизированная или автоматическая кодогене-рация, выполняющая несколько видов генерации кодов: преобразования для получения документации, формирования БД, ввода/модификации данных, получения выполняемых машинных кодов из спецификаций ПО, автоматической сборки модулей из словарей и моделей данных и повторно используемых программ, автоматической конверсии ранее используемых файлов в форматы новых требований.
  4.  Ограничение сложности, позволяющее получать компоненты, поддающиеся управлению, обозримые и доступные для понимания, а также обладающие простой и ясной структурой.
  5.  Доступность для разных категорий пользователей.
  6.  Рентабельность.
  7.  Сопровождаемость, обеспечивающая способность адаптации при изменении требований и целей проекта.

    Интегрированный CASE-пакет содержит четыре основные компонента:

  1.  Средства централизованного хранения всей информации о проектируемом ПО в течении всего ЖЦ(репозитарий) являются основой CASE-пакета. Соответствущая БД должна иметь возможность поддерживать большую систему описаний и характеристик и предусматривать надежные меры по защите от ошибок и потерь информации. Репозитарий должен обеспечивать:
  2.  инкрементный режим при вводе описаний объектов
  3.  распространение действия нового или скорректированного описания на информационное пространство всего проекта
  4.  синхронизацию поступления информации от различных пользователей
  5.  хранение версий проекта и его отдельных компонентов
  6.  сборку любой запрошенной версии
  7.  контроль информации на корректность, полноту и состоятельность
  8.  Средства ввода предназначены для ввода данных в репозитарий, а также для организации взаимодействия с CASE-пакетом. Эти средства должны поддерживать различные методологии и использоваться на всем ЖЦ разными категориями разработчиков: аналитиками, проектировщиками, инженерами, администраторами и т.д.
  9.  Средства анализа, проектирования и разработки предназначены для того, чтобы обеспечить планирование и анализ различных описаний, а также их преобразования в процессе разработки.
  10.  Средства вывода служат для документирования, управления проектом и кодовой генерации.

Все перечисленные компоненты в совокупности должны:

  1.  поддерживать графические модели
  2.  контролировать ошибки
  3.  организовывать и поддерживать репозитарий
  4.  поддерживать процесс проектирования и разработки

CASE (англ. Computer-Aided Software Engineering) — набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов.[1]

Также под CASE понимают совокупность методов и средств проектирования информационных систем с интегрированными автоматизированными инструментами, которые могут быть использованы в процессе разработки программного обеспечения.[2]

Классификация

В функции CASE входят средства анализа, проектирования и программирования. С помощью CASE автоматизируются процессы проектирования интерфейсов, документирования и производства структурированного кода на желаемом языке программирования.[3]

Выделяют две основные концепции компьютерного программного обеспечения системы CASE:

  •  простые и «прозрачные» методы упрощения разработки программного обеспечения и/или его технического обслуживания;
  •  Инженерный подход к разработке программного обеспечения и/или его технического обслуживания.

Типичными CASE инструментами являются:

  •  инструменты управления конфигурацией;
  •  инструменты моделирования данных;
  •  инструменты анализа и проектирования;
  •  инструменты преобразования моделей;
  •  инструменты редактирования программного кода;
  •  инструменты рефакторинга кода;
  •  генераторы кода;
  •  инструменты для построения UML-диаграмм.

16 Введение в UML

Принципы моделирования

Использование языка UML основывается на следующих общих принципах моделирования:

  •  абстрагирование - в модель следует включать только те элементы проектируемой системы, которые имеют непосредственное отношение к выполнению ей своих функций или своего целевого предназначения. Другие элементы опускаются, чтобы не усложнять процесс анализа и исследования модели; 
  •  многомодельность - никакая единственная модель не может с достаточной степенью точности описать различные аспекты системы. Допускается описывать систему некоторым числом взаимосвязанных представлений, каждое из которых отражает определенный аспект её поведения или структуры; 
  •  иерархическое построение – при описании системы  используются различные уровни абстрагирования и детализации в рамках фиксированных представлений. При этом первое представление системы  описывает её в наиболее общих чертах и является представлением концептуального уровня, а последующие уровни раскрывают различные аспекты системы с возрастающей степенью детализации вплоть до физического уровня. Модель физического уровня в языке UML отражает компонентный состав проектируемой системы с точки зрения ее реализации на аппаратурной и программной платформах конкретных производителей. 

Сущности в UML 

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

Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют статические части модели, соответствующие концептуальным или физическим элементам системы. Примерами структурных сущностей являются «класс», «интерфейс», «кооперация», «прецедент», «компонент», «узел», «актер».

 Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы, которые описывают поведение модели во времени и в пространстве. Существует два основных типа поведенческих сущностей:

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

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Такая первичная сущность имеется в единственном экземпляре - это пакет.

Пакеты представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить структурные, поведенческие и другие группирующие сущности. В отличие от компонентов, которые реально существуют во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только в процессе разработки.

Аннотационные сущности – это пояснительные части модели UML: комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов - примечание. Примечание используют, чтобы снабдить диаграммы комментариями или ограничениями, выраженными в виде неформального или формального текста.

Отношения в UML 

В языке UML определены следующие типы отношений: зависимость, ассоциация, обобщение и реализация. Эти отношения являются основными связующими конструкциями UML и также как сущности применяются для построения моделей.

Зависимость (dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой.

Ассоциация (association) - структурное отношение, описывающее совокупность смысловых или логических связей между объектами.

Обобщение (generalization) - это отношение, при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (предка). При этом, в соответствии с принципами объектно-ориентированного программирования, потомок (child) наследует структуру и поведение своего предка (parent).

Реализация (realization) является семантическим отношением между классификаторами, при котором один классификатор определяет обязательство, а другой гарантирует его выполнение. Отношение реализации встречаются в двух случаях:

  •  между интерфейсами и реализующими их классами или компонентами;
  •  между прецедентами и реализующими их кооперациями. 

 Общие механизмы UML 

Для точного описания системы в UML используются, так называемые, общие механизмы:

  •  спецификации (specifications);
  •  дополнения (adornments);
  •  деления (common divisions);
  •  расширения (extensibility mechanisms).

 UML является не только графическим языком. За каждым графическим элементом его нотации стоит спецификация, содержащая текстовое представление соответствующей конструкции языка. Например, пиктограмме класса соответствует спецификация, которая описывает его атрибуты, операции и поведение, хотя визуально, на диаграмме, пиктограмма часто отражает только малую часть этой информации. Более того, в модели может присутствовать другое представление этого класса, отражающее совершенно иные его аспекты, но, тем не менее, соответствующее спецификации. Таким образом, графическая нотация UML используются для визуализации системы, а с помощью спецификаций описывают ее детали.

Практически каждый элемент UML имеет уникальное графическое изображение, которое дает визуальное представление самых важных его характеристик. Нотация сущности «класс» содержит его имя, атрибуты и операции. Спецификация класса может содержать и другие детали, например, видимость атрибутов и операций, комментарии или указание на то, что класс является абстрактным. Многие из этих деталей можно визуализировать в виде графических или текстовых дополнений к стандартному прямоугольнику, который изображает класс.

При моделировании объектно-ориентированных систем существует определенное деление представляемых сущностей.

Во-первых, существует деление на классы и объекты. Класс - это абстракция, а объект - конкретное воплощение этой абстракции. В связи с этим, практически все конструкции языка характеризуются двойственностью «класс/объект». Так, имеются прецеденты и экземпляры прецедентов, компоненты и экземпляры компонентов, узлы и экземпляры узлов. В графическом представлении для объекта принято использовать тот же символ, что и для класса, а название подчеркивать.

Во-вторых, существует деление на интерфейс и его реализацию. Интерфейс декларирует обязательства, а реализация представляет конкретное воплощение этих обязательств и обеспечивает точное следование объявленной семантике. В связи с этим, почти все конструкции UML характеризуются двойственностью «интерфейс/реализация». Например, прецеденты реализуются кооперациями, а операции - методами.

UML является открытым языком, то есть допускает контролируемые расширения, чтобы отразить особенности моделей предметных областей. Механизмы расширения UML включают:

  •  стереотипы (stereotype) - расширяют словарь UML, позволяя на основе существующих элементов языка создавать новые, ориентированные для решения конкретной проблемы;
  •  помеченные значения (tagged value) - расширяют свойства основных конструкций UML, позволяя включать дополнительную информацию в спецификацию элемента; 
  •  ограничения (constraints) - расширяют семантику конструкций UML, позволяя создавать новые и отменять существующие правила. 

Совместно эти три механизма расширения языка позволяют модифицировать его в соответствии с потребностями проекта или особенностями технологии разработки.

Виды диаграмм  UML 

Графические изображения моделей системы в UML называются диаграммами. В терминах языка UML определены следующие их  виды:

  •  диаграмма вариантов использования или прецедентов (use case diagram) 
  •  диаграмма классов (class diagram) 
  •  диаграммы поведения (behavior diagrams) 
  •  диаграмма состояний (statechart diagram) 
  •  диаграмма деятельности (activity diagram) 
  •  диаграммы взаимодействия (interaction diagrams)  
  •  диаграмма последовательности (sequence diagram)  
  •  диаграмма кооперации (collaboration diagram) 
  •  диаграммы реализации (implementation diagrams)
  •  диаграмма компонентов (component diagram)
  •  даграмма развертывания (deployment diagram)

Каждая из этих диаграмм конкретизирует различные представления о модели системы. При этом, диаграмма вариантов использования представляет концептуальную модель системы, которая является исходной для построения всех остальных диаграмм. Диаграмма классов является логической моделью, отражающей статические аспекты структурного построения  системы, а диаграммы поведения, также являющиеся разновидностями логической модели, отражают динамические аспекты её функционирования. Диаграммы реализации служат для представления компонентов системы и относятся к ее физической модели.

Из перечисленных выше диаграмм некоторые служат для обозначения двух и более подвидов. В качестве же самостоятельных представлений используются следующие диаграммы: вариантов использования, классов, состояний, деятельности, последовательности, кооперации, компонентов и развертывания.

Для диаграмм языка UML существуют три типа визуальных обозначений, которые важны с точки зрения заключенной в них информации:

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

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

  •  каждая диаграмма должна быть законченным представлением некоторого фрагмента моделируемой предметной области; 
  •  представленные на диаграмме сущности модели должны быть одного концептуального уровня; 
  •  вся информация о сущностях должна быть явно представлена на диаграмме; 
  •  диаграммы не должны содержать противоречивой информации; 
  •  диаграммы не следует перегружать текстовой информацией; 
  •  каждая диаграмма должна быть самодостаточной для правильной интерпретации всех ее элементов; 
  •  количество типов диаграмм, необходимых для описания конкретной системы, не является строго фиксированным и определяется разработчиком; 
  •  модели системы должны содержать только те элементы, которые определен


 

А также другие работы, которые могут Вас заинтересовать

7093. Маркетинговое обслуживание потребителей 49.99 KB
  Введение В условиях рыночной экономики многие проблемы товаропроизводителей не могут быть в полной мере решены с помощью традиционных методов управления. Требуется создавать систему менеджмента, обеспечивающую эффективность хозяйственной единицы в н...
7094. Магнитометры на СКВИДах 108.5 KB
  Магнитометры на СКВИДах. Сверхпроводимость. Основные параметры сверхпроводников. Явление сверхпроводимости состоит в том, что при некоторой температуре, близкой к абсолютному нулю, электро сопротивление в некоторых материалах исчезает. Эта темпера...
7095. Социолингвистика. Лекции. Социальная стратификация языка 190 KB
  Лекции по курсу Социолингвистика. Лекция 1. Предмет социолингвистики и методы социолингвистического анализа. Предметом изучения социолингвистики является проблема человек и общество. Непосредственным объектом социолингвистики является ...
7096. Технология эмульгированных мясопродуктов 65.69 KB
  Лекция 4. Технология эмульгированных мясопродуктов План АССОРТИМЕНТ КОЛБАСНЫХ ИЗДЕЛИЙ, СЫРЬЕ И МАТЕРИАЛЫ ДЛЯ ИХ ПРОИЗВОДСТВА Ассортимент колбасных изделий Характеристика сырья Колбасные оболочки Упаковочные и перевязочны...
7097. Основы программирования на языке Паскаль 81.53 KB
  Краткий курс лекций. Основы программирования на языке Паскаль Введение. Прежде всего, следует напомнить, что изучение языка программирования представляет собой знакомство с формальными правилами записи алгоритмов для их последующего выполнения компьют...
7098. Психосоматика. Курс лекций 279 KB
  Конспект лекций Психосоматика Психосоматика: определение понятия. Конверсионные симптомы. Функциональные синдромы. Психосоматозы Патогенез психосоматических расстройств Психосоматические теории и модели. Характерологически ориентированные направле...
7099. Основы аудита. Проблемно-тематический курс 267.5 KB
  Основы аудита Проблемно-тематический курс. Понятие, цели и организация аудиторской деятельности Тема 2. Виды аудиторских услуг Тема 3. Источники информации о финансово-хозяйственной деятельности экономического субъекта при осуществ...
7100. Проектирование многомодульной программы 177.5 KB
  Проектирование многомодульной программы Методические указания содержат основные теоретические сведения, рекомендации и примеры, необходимые для выполнения лабораторной работы и семестрового задания по курсу Алгоритмические языки и прог...
7101. Жилищное право. Понятие жилищного права. Источники жилищного права 342.5 KB
  Понятие жилищного права. Источники жилищного права. Жилищное право - это совокупность норм права, регулирующих жилищные отношения. Понятие жилищное право употребляется в юридической литературе в двух смыслах, узком и широком. В узком смысле жилищн...