ТСПП - Лекция 2
.pdfЛекция 1. Технологии, модели и процессы создания программного обеспечения
Используемые условные сокращения
ИПО - инженерия программного обеспечения. ПО - программное обеспечение.
ЖЦ - жизненный цикл.
ЖЦ ПО - жизненный цикл программного обеспечения. ПС – программные средства.
ООП – объектно-ориентированное проектирование. ULM – универсальный язык моделирования
CASE_средства (computer_aided software engineering) – средства автоматизированной разработки программного обеспечения..
1.1. Терминология
Программная инженерия (Software Engineering) является отраслью Computer science, изучает вопросы построения компьютерных программ, отражает закономерности ее развития, обобщает опыт программирования в виде комплекса общих знаний и правил регламентации инженерной деятельности разработчиков ПО..
Суть методологии программной инженерии состоит в применении систематизированного, научного и предсказуемого процесса проектирования, разработки и сопровождения программных средств.
Программная инженерия, как инженерная дисциплина, делает главный акцент на повышение качества и производительности ПО за счет применения новых и усовершенствованных: методов проектирования ПО; готовых компонентов и методов их генерации; методов эволюции ПО; методов верификации и тестирования ПО; инструментальных средств поддержки; методов управления проектами, методов оценки качества, производительности, стоимости и т.п.; стандартизации процессов разработки ПО (ISO/IEC 12207, ISO/IEC 15504, ISO 9126 и др.), регламентирующих этапы ЖЦ; подходов к оценке продуктов и процессов
Инструменты поддержки разработки ПО совершили гигантский скачок в своем развитии и теперь обычной практикой стало создание ПС с использованием современных визуальных и диаграммных средств
UML.
Цель данных методических указаний - помочь студенту освоить базовые концепции и понятия универсального языка моделирования UML как инструмента, используемого для решения задач курса «Инженерии программного обеспечения».
Программное обеспечение (ПО) – компьютерные программы и соответствующая документация, которые разрабатываются по частному заказу или для продажи на рынке ПО.
Инженерия ПО – инженерная дисциплина, охватывающая все аспекты разработки ПО.
Системотехника (технология создания вычислительных систем) – дисциплина, охватывающая все аспекты создания и модернизации сложных вычислительных систем, где программное обеспечение играет ведущую роль. Сюда можно отнести технологии создания аппаратных средств, создание вычислительных процессов, развертывание всей системы, а также технологию создания непосредственно ПО.
Процесс создания ПО – совокупность процессов, приводящих к созданию программного продукта.
Базовые процессы создания ПО:
−разработка спецификации;
−проектирование и реализация;
−аттестация:
−эволюция.
Модель процесса создания ПО – последовательность этапов, необходимых для разработки создаваемого ПО.
Модели являются связующим звеном между процессом анализа исходной задачи и процессом проектирования системы.
Модели могут представить систему в различных аспектах. Модель является абстракцией системы и легче поддается анализу, чем любое другое представление этой системы.
Методы создания ПО представляют собой структурный подход к созданию ПО, который способствует производству ПО эффективным, с экономической точки зрения, способом.
Жизненный цикл ПО – совокупность процессов, протекающих от момента принятия решения о создании ПО до его полного вывода из эксплуатации.
Методы проектирования – множество формализованных нотаций и нормативных документов для проектирования ПО.
Методы создания ПО представляют собой структурный подход к созданию ПО, который способствует производству ПО эффективным, с экономической точки зрения, способом.
Все методы, основаны на использовании моделей системы, основываются на одной из следующих концепциях: функционально-ориентированного или объектно-ориентированного программирования систем.
Функционально-ориентированное проектирование основано на определении основных функциональных компонент системы.
Объектно-ориентированное проектирование представляет собой стратегию, в рамках которой программная система состоит из взаимодействующих объектов, имеющих собственное локальное состояние и способных выполнять определенный набор операций, определяемый состоянием объекта. Оно основано на использовании унифицированного языка моделирования UML.
UML (Unified Modeling Language) - унифицированный язык моделирования – это язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.
1.2. Назначение языка UML
UML - унифицированный язык моделирования.
Язык включает в себя набор знаков (словарь) и правила их употребления и интерпретации (грамматику) [ 1 ].
UML – объектно-ориентированный язык моделирования.
UML - это графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых в ходе разработки.
UML в первую очередь - это спецификации
Спецификация - подробное описание системы, которое полностью определяет ее цель и функциональные возможности.
Различают:
словесные спецификации на естественном языке;
формальные спецификации;
модельные спецификации.
Словесные спецификации на естественном языке как раз и вызывают массу проблем, поскольку создаются разными специалистами на "их языке".
Формальные спецификации. Формальная спецификация является, по сути, математической моделью задачи и потому для вычислительных задач все выглядит достаточно просто. Формализация же задач из других областей знаний может оказаться более сложной и трудоемкой проблемой, чем разработка самого приложения ввиду отсутствия четкой математической модели
Когда говорят о том, что UML - это средство визуализации, подразумевают модельные спецификации, которые представляют собой картинки с текстом.
Проектирование.
UML позволяет строить модели программных систем. По этим моделям потом может производиться генерация каркасного кода проектируемых приложений. Более того, возможен процесс, который часто называют "реверс-инжинирингом", - т. е. создание UML-модели из существующего кода приложения.
Документирование .
UML-модели сами по себе уже являются документами (и весьма понятными, даже для неспециалиста, модели UML являются XML-документами). Причем любой элемент на любой диаграмме может быть снабжен ноутсом - текстовым комментарием. Т. е. построение набора диаграмм уже является процессом документирования будущей системы. Более того, большинство инструментов UML-
проектирования умеют извлекать текстовую информацию из моделей и генерировать относительно удобочитаемые тексты.
1.3. Структура языка ULM
"Нотация" - это синтаксис языка.
Само слово "нотация" подчеркивает, что UML - язык графический и модели (а точнее диаграммы) не "записывают", а рисуют. Одна из задач UML - служить средством коммуникации внутри команды и при общении с заказчиком. Поэтому при выборе элементов нотации основным принципом был отбор значков, которые хорошо смотрелись бы и были бы правильно интерпретированы в любом случае - будь они нарисованы карандашом на салфетке или созданы на компьютере и распечатаны на лазерном принтере.
ВUML используется четыре вида элементов нотации:
1.фигуры,
2.линии,
3.значки,
4.надписи.
Фигуры используются "плоские" - прямоугольники, эллипсы, ромбы и т. д. Но есть одно исключение - на диаграмме развертывания для обозначения узлов инфраструктуры применяется "трехмерное" изображение параллелепипеда. Это единственное исключение из правил. Внутри любой фигуры могут помещаться другие элементы нотации.
Лини своими концами должны соединяться с фигурами. На UML диаграммах не используются линии, нарисованных "сами по себе" и не соединяющих фигуры. Применяется два типа линий - сплошная и пунктирная. Линии могут пересекаться, хотя таких случаев следует по возможности избегать.
Для использования вычислительной техники при работе с UML разработан ряд CASE-средств для UML-проектирования. К таким пакетам можно отнести:
IBM Rational Rose;
Borland Together;
Gentleware Poseidon;
Microsoft Visio;
Telelogic TAU G2;
StarUML.
В данном учебном пособии мы будем использовать терминологию и стандарты, определенные в StarUML. В настоящее время StarUML является свободно распространяемым пакетом, который можно скачать с Internet или сайта кафедры.
1.4. Модель и ее элементы
Модель UML (UML model)— это совокупность конечного множества конструкций языка, главные из которых — это сущности и отношения между ними.
Сами сущности и отношения модели являются экземплярами метаклассов метамодели.
Сущности
Для удобства обзора сущности в UML можно подразделить на четыре группы:
-структурные;
-поведенческие;
-группирующие;
-аннотационные.
Структурные сущности предназначены для описания структуры. К структурным сущностям относят:
Объект (object) — сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение.
Класс (class) — описание множества объектов с общими атрибутами, определяющими состояние, и операциями, определяющими поведение.
Интерфейс (interface) — именованное множество операций, определяющее набор услуг, которые могут быть запрошены потребителем и предоставлены поставщиком услуг.
Кооперация (collaboration) — совокупность объектов, которые взаимодействуют для достижения некоторой цели.
Действующее лицо (actor) — сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.
Компонент (component) — модульная часть системы с четко определенным набором требуемых и предоставляемых интерфейсов.
Артефакт (artifact) — элемент информации, который используется или порождается в процессе разработки программного обеспечения. Другими словами, артефакт — это физическая единица реализации, получаемая из элемента модели (например, класса или компонента).
Узел (node) — вычислительный ресурс, на котором размещаются и при необходимости выполняются артефакты.
Поведенческие сущности предназначены для описания поведения. Основных поведенческих сущностей всего две: состояние и действие.
Состояние (state) — период в жизненном цикле объекта, находясь в котором объект удовлетворяет некоторому условию и осуществляет собственную деятельность или ожидает наступления некоторого события.
Деятельность (activity) - частный случай состояния, который характеризуется продолжительными (по времени) не атомарными вычислениями.
Действие (action) — примитивное атомарное вычисление.
Кроме того, при моделировании поведения используется еще ряд вспомогательных сущностей, которые здесь не перечислены, потому что сосуществуют только вместе с указанными основными.
Несколько особняком стоит сущность — вариант использования, которому присущи как структурные, так и поведенческие аспекты.
Вариант использования (use case) — множество сценариев, объединенных по некоторому критерию и описывающих последовательности производимых системой действий, доставляющих значимый для некоторого действующего лица результат.
Приведенная классификация не является исчерпывающей. У каждой из этих сущностей есть различные частные случаи и вариации, рассматриваемые в последующих разделах.
Группирующая сущность в UML одна — пакет — зато универсальная. Пакет (package) — группа элементов модели (в том числе пакетов).
Аннотационная сущность тоже одна — примечание (comment) — в нее можно поместить все что угодно, так как содержание примечания UML не ограничивает.
Отношения
ВUML используются четыре основных типа отношений:
-зависимость (dependency);
-ассоциация (association);
-обобщение (generalization);
-реализация (realization).
Зависимость — это наиболее общий тип отношения между двумя сущностями.
Отношение зависимости указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность.
Графически отношение зависимости изображается в виде пунктирной линии со стрелкой (1), направленной от зависимой сущности (2) к независимой (3) (рис.1.1). Как правило, семантика конкретной зависимости уточняется в модели с помощью дополнительной информации.
Рис..1.1. Отношение зависимости
Ассоциация — это наиболее часто используемый тип отношения между сущностями.
Отношение ассоциации имеет место, если одна сущность непосредственно связана с другой (или с другими — ассоциация может быть не только бинарной).
Графически ассоциация изображается в виде сплошной линии (1) с различными дополнениями, соединяющей связанные сущности (рис.1.2). На программном уровне непосредственная связь может быть реализована различным образом, главное, что ассоциированные сущности знают друг о друге. Например, отношение часть–целое является частным случаем ассоциации и называется отношением агрегации.
Рис. 1.2. Отношение ассоциации
Обобщение — это отношение между двумя сущностями, одна их которых является частным (специализированным) случаем другой.
Графически обобщение изображается в виде линии с треугольной незакрашенной стрелкой на конце (1), направленной от частного (2) (подкласса) к общему (3) (суперклассу) (рис.1.3).
Рис. 1.3. Отношение обобщения
Отношение реализации указывает, что одна сущность является реализацией другой.
Графически реализация изображается в виде пунктирной линии с треугольной незакрашенной стрелкой на конце (1), направленной от реализующей сущности (2) к реализуемой (3) (рис.1.4.).
Рис. 1.4. Отношение реализации
Перечисленные типы отношений являются основными, различные их вариации и дополнительные отношения детально рассматриваются в последующих разделах.
1.5. Диаграммы
Диаграммы UML есть та основная накладываемая на модель структура, которая облегчает создание и использование модели.
Диаграмм (diagram) — это графическое представление некоторой части графа модели.
В диаграмму можно включить любые (допустимые) комбинации сущностей и отношений. Авторы UML определили набор рекомендуемых к использованию типов диаграмм, которые получили название канонических типов диаграмм.
Классификация диаграмм
В UML 1 всего определено 9 канонических типов диаграмм. Ниже перечислены их названия, принятые в данном учебном пособии (в других источниках есть отличия).
-Диаграмма использования (Use Case diagram).
-Диаграмма классов (Class diagram).
-Диаграмма объектов (Object diagram).
-Диаграмма состояний (State chart diagram).
-Диаграмма деятельности (Activity diagram).
-Диаграмма последовательности (Sequence diagram).
-Диаграмма кооперации (Collaboration diagram).
-Диаграмма компонентов (Component diagram).
-Диаграмма размещения (Deployment diagram).
Классификация диаграмм приведена на рис. 1.5.
Рис. 1.5.. Диаграммы UML 1.
Диаграмма использования (use case diagram)
Модель описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.
Разработка диаграммы использования преследует цели:
1.Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
2.Сформулировать общие требования к функциональному поведению проектируемой системы.
3.Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
4.Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Диаграмма классов (class diagram)
Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.
Диаграмма состояний (statechart diagram)
Диаграмма состояний описывает процесс изменения состояний только одного класса, а точнее – одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне. Именно для описания реакции объекта на подобные внешние воздействия и используются диаграммы состояний.
Диаграмма деятельности (activity diagram)
Диаграммы деятельности служат для моделирования процесса выполнения операций в языке UML. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой, операции в предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами – переходы от одного состояния действия к другому.
Хотя диаграмма деятельности предназначена для моделирования поведения систем, время в явном виде отсутствует на этой диаграмме. Ситуация здесь во многом аналогична диаграмме состояний.
Диаграмма последовательности (sequence diagram)
Особенности взаимодействия элементов моделируемой системы могут быть представлены на диаграммах последовательности и кооперации. Взаимодействия объектов рассматривается во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности.
Для диаграммы последовательности ключевым моментом является динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно – слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни.
Диаграмма кооперации (collaboration diagram)
Диаграмма кооперации предназначена для спецификации структурных аспектов взаимодействия. Главная особенность диаграммы кооперации заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии.
В отличие от диаграммы последовательности, на диаграмме кооперации изображаются только отношения между объектами, играющими определенные роли во взаимодействии. С другой стороны, на этой диаграмме не указывается время в виде отдельного измерения. Поэтому последовательность взаимодействий и параллельных потоков может быть определена с помощью порядковых номеров
Диаграмма компонентов (component diagram)
В языке UML для физического представления моделей систем используются так называемые диаграммы реализации (implementation diagrams), которые включают в себя две отдельные канонические диаграммы: диаграмму компонентов и диаграмму развертывания.
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код.
Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Диаграмма компонентов разрабатывается для следующих целей:
Визуализации общей структуры исходного кода программной системы.
Спецификации исполнимого варианта программной системы.
Обеспечения многократного использования отдельных фрагментов программного кода.
Представления концептуальной и физической схем баз данных.