CASE средства поддержки жизненного цикла

11.41M

Category:

software

CASE средства и UML_1 блок_10-11-22

1.

Информационные технологии поддержки жизненного цикла
лекция
CASE СРЕДСТВА ПОДДЕРЖКИ ЖИЗНЕННОГО ЦИКЛА
ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ
ПОДХОД К МОДЕЛИРОВАНИЮ СИСТЕМ
UML - язык графического описания
для объектного моделирования в области
разработки программного обеспечения

2. CASE средства поддержки жизненного цикла

CASE СРЕДСТВА ПОДДЕРЖКИ ЖИЗНЕННОГО ЦИКЛА
CASE – Computer Aided Software Engineering –
Компьютерно-Помогающая Инженерия Программирования
Современные CASE-средства охватывают обширную область
поддержки многочисленных технологий проектирования ИС: от простых
средств анализа и документирования до полномасштабных средств
автоматизации, покрывающих весь жизненный цикл ПО.

3.

4.

5.

Методологии моделирования

6.

ОТЛИЧИЯ СТРУКТУРНОГО И ОБЪЕКТНО-ОРИЕНТИРОВАННОГО
ПОДХОДА К МОДЕЛИРОВАНИЮ СИСТЕМ
Структурный подход
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции
(разбиении) на автоматизируемые функции: система разбивается на
функциональные подсистемы, которые в свою очередь делятся на подфункции,
подразделяемые на задачи и так далее.
Объектно-ориентированный подход
Другой принцип описания системы, использует объектную декомпозицию, при этом
статическая структура системы описывается в терминах объектов и связей между
ними, а поведение системы описывается в терминах обмена сообщений между
объектами
• От структурного подхода отличает способ декомпозиции системы
• Система описывается в терминах объектов и классов
• Соблюдается принцип наследования в иерархии классов

7.

ОТЛИЧИЯ СТРУКТУРНОГО И ОБЪЕКТНО-ОРИЕНТИРОВАННОГО
ПОДХОДА К МОДЕЛИРОВАНИЮ СИСТЕМ

8.

9.

10.

11.

ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ
ПОДХОД К МОДЕЛИРОВАНИЮ СИСТЕМ

12.

13.

Принципы
объектно-ориентированного подхода

14.

15.

16.

17.

18.

19.

20.

21.

22.

23.

24.

UML – не является языком программирования
UML – это язык графический

25.

Разберем семантику слов стоящих за UML
Language - Язык - система знаков, служащая:
•средством человеческого общения и мыслительной деятельности;
•способом выражения самосознания личности;
•средством хранения и передачи информации.
Язык включает в себя набор знаков (словарь) и правила их употребления и интерпретации (грамматику).
К этому достаточно исчерпывающему определению нужно добавить, что языки бывают естественные и
искусственные, формальные и неформальные.
UML - язык формальный и искусственный, хотя, как мы увидим далее, этот ярлык к нему не
совсем подходит.
Искусственный он потому, что у него имеются авторы, о которых мы упомянем в дальнейшем (в то же
время, развитие UML непрерывно продолжается, что ставит его в один ряд с естественными языками).
Формальным его можно назвать, поскольку имеются правила его употребления
Еще один нюанс: UML - язык графический, что также немного путает ситуацию!
При описании формального искусственного языка, что мы уже видели на примерах описания языков
программирования, как правило, описываются такие его элементы, как:
1.синтаксис, то есть определение правил построения конструкций языка;
2.семантика, то есть определение правил, в соответствии с которыми конструкции языка приобретают
смысловое значение;
3.прагматика, то есть определение правил использования конструкций языка для достижения нужных
нам целей.
Естественно, UML включает все эти элементы, хотя, как мы опять-таки увидим далее, в их описании тоже
наблюдаются отличия от правил, принятых в языках программирования.

26.

Разберем семантику слов стоящих за UML
Второе
слово
в
фразе,
которой
расшифровывается
аббревиатура UML - слово " моделирование ".
Да, UML - это язык моделирования.
Причем объектно-ориентированного моделирования.
В английском языке есть целых два слова - modeling и simulation, которые
оба переводятся как "моделирование", хотя означают разные понятия.
• Modeling подразумевает создание модели, лишь описывающей объект,
• а simulation предполагает получение с помощью созданной модели
некоторой дополнительной информации об объекте.
UML в первую очередь - язык моделирования именно в первом смысле, то есть
средство построения описательных моделей.
Как средство симулирования его тоже можно использовать, хотя для этой роли
он подходит не так хорошо.

27.

Разберем семантику слов стоящих за UML
Третье слово в названии UML - слово " унифицированный ".
Его можно понимать тоже неоднозначно.
В литературе можно встретить описание эры "до UML" как "войны
методов" моделирования, ни один из которых "не дотягивал" до уровня
индустриального стандарта.
UML как раз и стал таким единым универсальным стандартом
для объектно-ориентированного моделирования, которое во времена
его создания как раз "вошло в моду".
"Единым" языком моделирования UML можно назвать еще и потому, что в
его создании, как мы увидим далее, объединились усилия авторов трех
наиболее популярных методов моделирования (и не только их).
Подводя итоги, кратко можно сказать, что
UML - искусственный язык, который имеет некоторые черты
естественного языка, и формальный язык, который имеет черты
неформального.

28.

UML, как спецификация
Заглянем снова в глоссарий и обнаружим, что
Спецификация - подробное описание системы, которое
функциональные возможности. Различают:
•словесные спецификации на естественном языке;
•модельные спецификации;
•формальные спецификации.
полностью
определяет
ее
цель
и
Не следует также забывать, что заказчик и разработчик имеют, как правило, абсолютно разное понимание
смысла этого артефакта. А ведь кроме этого есть еще аналитики, менеджеры, бизнес-консультанты...
Каждый
из
них
называет
спецификации
по-своему:
постановка
задачи,
требования
пользователя, техническое задание, функциональная спецификация, архитектура системы...
Причем все эти люди, являясь специалистами в абсолютно разных предметных областях, говорят каждый
на своем языке и зачастую просто не понимают друг друга. Вот потому-то и возникает проблема,
представленная на рисунке, проблема, которую может решить только наличие единого,
унифицированного средства создания спецификаций, достаточно простого и понятного для всех
заинтересованных лиц.
Как уже говорилось выше, различают спецификации трех видов. Словесные спецификации на
естественном языке как раз и вызывают массу проблем, поскольку создаются разными специалистами
на "их языке". Другим видом спецификаций являются формальные спецификации.
Действительно, описание спецификации с помощью строгого математического языка было бы чудесным
решением всех проблем, т. к. сам способ записи исключал бы малейшие неоднозначности. Да, в
математике есть, например, алгебра высказываний, с помощью которой можно пытаться создавать
технические задания на разработку некоторых приложений. Проблема кроется в слове "некоторых".
Понятно, что формальная спецификация является, по сути, математической моделью задачи и потому
для вычислительных задач все выглядит достаточно просто. Формализация же задач из других областей
знаний может оказаться более сложной и трудоемкой проблемой, чем разработка самого приложения
ввиду отсутствия четкой математической модели. Один из принципов прикладной "мерфологии" гласит,
что лучшей спецификацией программы является ее текст. Так же, как и большинство остальных законов
Мерфи, это утверждение просто поражает своей правдивостью...

29.

UML - это средство визуализации
Все мы знаем, как иногда трудно заставить себя "вникнуть" в суть материала,
излагаемого в очередном учебнике или мануале.
Изучение чего-то нового идет гораздо проще, если документ содержит не
только текст, а еще и иллюстрации к нему.
А если руководство или учебник выглядят как картинки с подписями
(вспомните майкрософтовские учебники и трейнер-киты или руководства
пользователя мобильных телефонов!), то усвоение нового материала
происходит еще проще и эффективнее.
Недаром до сих пор так популярны комиксы, которые также представляют
собой картинки с текстом!
Так вот, такие картинки с подписями наглядны и интуитивно понятны, причем
почти однозначно понимаются любыми заинтересованными лицами, так что
могут использоваться в качестве средства общения между людьми.
UML позволяет создавать такие простые и понятные картинки (модели),
описывающие систему с разных сторон, которые можно показать заказчику и
обсудить с ним, т. е. служит средством коммуникации в команде.

30.

типичный процесс создания продукта, или "решения« без языка моделирования

31.

UML, как инструмент проектирования позволяет строить модели программных систем (вообще
говоря - ЛЮБЫХ систем).
По этим моделям потом может производиться генерация каркасного кода проектируемых приложений.
Более того, возможен процесс, который часто называют "реверс-инжинирингом", - т. е. создание UMLмодели из существующего кода приложения. Не будем сейчас обсуждать качество получающегося кода
или моделей при реверс-инжиниринге. Пока оно весьма далеко от идеала, но ведь технологии и
инструменты постоянно совершенствуются, так что можно надеяться, что когда-нибудь мы сможем
создавать приложения визуально, не прибегая к языку программирования, а пользуясь лишь UML...
UML, как инструмент " документирования ".
По большому счету, UML-модели сами по себе уже являются документами (и весьма понятными, даже
для неспециалиста, как мы уже могли убедиться, посмотрев на предыдущий рисунок; кроме этого, как
мы еще упомянем далее, модели UML являются XML-документами).
Причем любой элемент на любой диаграмме может быть снабжен ноутсом - текстовым комментарием.
Т. е. построение набора диаграмм уже является процессом документирования будущей системы.
Более того, большинство инструментов UML-проектирования умеют извлекать текстовую информацию
из моделей и генерировать относительно удобочитаемые тексты.
Итак, подводя итоги, скажем, что UML можно использовать для рисования картинок, которые можно
использовать для коммуникаций внутри команды и в ходе взаимодействия с заказчиком, т. е. он может
служить средством обмена информацией. Кроме этого, как мы уже говорили, UML является отличным
средством спецификации систем, причем спецификации в процессе разработки.
Разработанные архитектурные решения, задокументированные с помощью UML, могут быть
использованы повторно (что сейчас также очень "модно"). Как уже упоминалось выше, о таких вещах,
как генерация кода, симуляция и верификация моделей, пока серьезно говорить не приходится, но в
будущем, надеемся, будет и это...

32.

Теперь о том, для чего UML использовать нельзя,
вернее, чем он не является.
Во-первых, UML не является языком программирования, хотя существуют
средства выполнения UML-моделей как интерпретируемого кода (Unimod,
FLORA и др.) и возможна, кодогенерация.
Несмотря на это, UML - средство не программирования, а моделирования,
т. е. создания не программ, а моделей любого уровня абстракции для систем
из любой предметной области.
Во-вторых, UML не является и спецификацией какого бы то ни было
инструмента моделирования, хотя такие инструменты (и в больших
количествах)
имеются.
Например,
TAU
G2,
Borland
Together,
Poseidon, Enterprise Architect, IBM Rational Rose, Dia, Visio и др.
Каким образом то или иное CASE-средство реализует UML-моделирование,
никак не регламентируется и определяется самими разработчиками этих
инструментов.
И, наконец, в-третьих, UML не является и моделью какого-либо процесса
разработки, даже Rational Unified Process (RUP), который был описан именно
с помощью UML (а точнее, с помощью SPEM - профайла UML).
UML можно использовать независимо от того, какую методологию
разработки ПО вы используете, и даже если вы вообще не пользуетесь
никакой методологией!

33.

34.

35.

Метод Booch был предложен Гради Бучем в 1992 году, когда он работал в
Rational Software, которая позже была приобретена IBM. В 1994 году Буч
переработал свою модель.
Некоторые элементы метода Booch:
Моделирование объектов. Выявление и моделирование ключевых
сущностей и объектов внутри системы, а также их атрибутов, поведения и
отношений.
Диаграммы классов. Создание диаграмм классов для визуального
представления статической структуры системы, включая классы, их
атрибуты, методы и ассоциации.
Динамическое моделирование. Анализ и моделирование динамического
поведения системы, включая взаимодействия между объектами, переходы
состояний и диаграммы последовательностей.
Архитектурный дизайн. Проектирование общей архитектуры системы,
включая организацию классов, модулей и компонентов, а также
определение интерфейсов и зависимостей.

36.

OMT (Object Modeling Technique) — метод объектно-ориентированного
моделирования для разработки программного обеспечения. Разработан в
1991 году Джеймсом Рамбо, Блахой, Премерлани, Эдди и Лоренсэном.
OMT описывает объектную модель или статическую структуру системы.
Согласно Рамбо, цели моделирования включают тестирование физических
объектов перед их созданием, общение с клиентами, визуализацию и
снижение сложности.
В рамках OMT предложены три основных типа моделей:
Объектная модель. Представляет статичные и наиболее стабильные
явления в моделируемом пространстве. Основные концепции — классы и
ассоциации с атрибутами и операциями.
Динамическая модель. Представляет представление о состоянии и
переходах в модели. Основные концепции — состояния, переходы между
состояниями и события, вызывающие переходы.
Функциональная модель. Рассматривает модель с точки зрения
процессов, примерно соответствует диаграммам потоков данных. Основные
концепции — процесс, хранилище данных, поток данных и

37.

OOSE (англ. object-oriented software engineering) — процесс разработки
программного обеспечения, который описал Ивар Ялмар
Якобсон (родился 2 сентября 1939 года).
Около 1992 года Якобсон представил свою разработку, которая стала
упрощённой версией коммерческого программного процесса Objectory
(сокращение от Object Factory).
OOSE предназначен для создания рациональной архитектуры, обеспечивает
долгосрочную поддержку, документацию и повторное использование, а также
делает особый акцент на управлении

38.

Некоторые основные принципы OOSE:
Абстракция. Позволяет разработчикам отделить функциональность
компонента от его физической реализации.
Инкапсуляция. Определяет границы объектов и их интерфейс с другими
элементами системы. Функции инкапсулируются внутри объекта и не
становятся видимыми для других компонентов.
Наследование. Позволяет одному компоненту наследовать всю
функциональность и интерфейсы другого компонента.
Повторное использование объектов. Улучшает эффективность процесса
и сокращает время на завершение проекта.
Понимание того, как фактически используется система. OOSE
организует модели анализа и проектирования на основе последовательных
взаимодействий пользователя и системы.
Деление разработки на процессы или действия, которые, в отличие от
традиционных фаз разработки, могут повторяться и перекрываться.
Учёт влияния аппаратной конфигурации на архитектуру. OOSE
заставляет проектные группы учитывать это влияние сразу же, как только
оно становится очевидным.

39.

40.

41.

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

42.

ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ
ПОДХОД К МОДЕЛИРОВАНИЮ СИСТЕМ
• От структурного подхода отличает способ декомпозиции системы
• Система описывается в терминах объектов и классов
• Соблюдается принцип наследования в иерархии классов
Объект – некоторая сущность, обладающая определённым
состоянием или поведением
Класс – некая сущность, которая задает общее поведение для
объектов

43.

ПРИНЦИПЫ НАСЛЕДОВАНИЯ
ВАЗ 2110
VIN XTA210930Y2696785

44.

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

45.

Недостатки UML
Избыточность языка. UML включает много избыточных или практически
неиспользуемых диаграмм и конструкций.
Неточная семантика. Неточность описания самого UML одинаково отражается на
пользователях и поставщиках инструментов, приводя к несовместимости
инструментов из-за уникального трактования спецификаций.
Проблемы при изучении и внедрении. - UML требует предварительных навыков.
Только код отражает код - Ещё одно мнение — что важны рабочие системы, а
не красивые модели. Существует потребность в лучшем способе написания ПО, т.к.
UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет
ограничен тем, что может разглядеть или предположить интерпретирующий UML
инструмент.
Рассогласование нагрузки — термин из теории системного анализа для
обозначения неспособности входа одной системы воспринять выход другой. Как в
любой системе обозначений UML может представить одни системы более кратко и
эффективно, чем другие. Таким образом, разработчик склоняется к решениям,
которые более комфортно подходят к переплетению сильных сторон UML и языков
программирования.
Пытается быть всем для всех. UML — это язык моделирования общего
назначения. Поэтому в контексте конкретного проекта, должны быть выбраны
применимые возможности UML.

46.

Инструментальная поддержка
Можно выделить
три основных
варианта
использования
UML

47.

UML 2.4.1 принят в качестве международного стандарта ISO/IEC
Формальная спецификация версии UML 2.0 опубликована в августе 2005 года.
Семантика языка была значительно уточнена и расширена для поддержки
методологии Model Driven Development — MDD.
Последняя версия UML 2.5 опубликована в июне 2015 года.
Структура стандарта UML

48.

Терминология и нотация
При разработке UML были предложены четыре
основных графических элемента:
• фигуры;
• линии;
• значки;
• тексты.

49.

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

50.

Сущности
СТРУКТУРНЫЕ СУЩНОСТИ
ПОВЕДЕНЧЕСКИЕ СУЩНОСТИ
ГРУППИРУЮЩАЯ СУЩНОСТЬ
АНАТАЦИОННАЯ СУЩНОСТЬ

51.

СУЩНОСТИ

52.

9 канонических типов диаграмм
• Диаграмма использования
• Диаграмма классов
• Диаграмма объектов
• Диаграмма состояний
• Диаграмма деятельности
• Диаграмма последовательности
• Диаграмма кооперации
• Диаграмма компонентов
• Диаграмма размещения

53.

ОСНОВНЫЕ ТИПЫ ДИАГРАММ

54.

55.

1. Диаграмма классов

56.

1. Диаграмма классов

57.

2. Диаграмма состояний

58.

3. Диаграмма вариантов использования (прецедентов)

59.

3. Диаграмма вариантов использования (прецедентов)

60.

3. Диаграмма вариантов использования (прецедентов)

61.

4. Диаграмма последовательностей

62.

МОДЕЛИРОВАНИЕ С ПОМОЩЬЮ StarUML
StarUML StarUML ™ - программный инструмент моделирования ,
позволяет разрабатывать одиннадцать различных типов диаграмм,
принятых в нотации UML 2.0.

63.

StarUML – доступные типы диаграмм

64.

StarUML – доступные типы диаграмм

65.

1 БЛОК
ЗНАКОМСТВО С ИНТЕРФЕЙСОМ.
2 БЛОК
МОДЕЛИРОВАНИЕ С ПОМОЩЬЮ StarUML
Создание проекта
Анализ исходных данных.
Проектирование диаграммы прецедентов
Моделирование потоков событий
4 БЛОК
3 БЛОК
Построение диаграммы деятельности
Построение диаграммы классов
Группировка классов по пакетам, диаграммы пакетов
Построение диаграммы взаимодействия
Создание атрибутов и операций классов
Определение спецификаций атрибутов класса
Определение спецификаций операций класса
Создание отношений между классами