1. Определение проекта и проектирования. Основные особенности и проблемы современных программных проектов

Вопросы

1. Определение проекта и проектирования. Основные особенности и проблемы современных программных проектов

2. Жизненный цикл программного обеспечения. Стандарты, регламентирующие жизненный цикл

3. Общие принципы проектирования систем. Модели программного обеспечения и их место в процессе проектирования

4. Объектная модель

5. Определение и история создания языка UML. Состав диаграмм UML

6. Назначение диаграммы вариантов использования. Основные обозначения. Отношения на диаграмме вариантов использования

7. Диаграмма классов. Разновидности классов. Атрибут класса. Операции класса. Отношения на диаграмме классов

8. Назначение диаграммы последовательности. Объекты, их графическое представление. Линия жизни и фокус управления. Особенности изображения моментов создания и уничтожения объектов

9. Проектирование классов. Проектирование баз данных

10. Технология создания программного обеспечения. Rational Unified Process (RUP)

1 Определение проекта и проектирования. Основные особенности и проблемы современных программных проектов

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

Программное обеспечение (ПО) – это система, включающая в себя: компьютерные программы; документацию; данные, необходимые для корректной работы программ.

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

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

1) недостаточно адекватное управление требованиями;

2) несогласованность требований, проектных решений и реализации;

3) жесткая архитектура ПО;

4) нарастающая сложность ПО;

5) неточная и противоречивая коммуникация;

6) недостаточное тестирование;

7) субъективное отношение к приоритетам отдельных артефактов[1] проекта;

8) игнорирование рисков и отсутствие процедур управления рисками;

9) бесконтрольное внесение изменений в артефакты проекта;

10) недостаточное использование CASE-средств и средств поддержки отдельных этапов проекта.

К причинам создания неудачных проектов относится и отсутствие моделей при разработке ПО:

1) не позволяет справиться с растущей сложностью разрабатываемых программных систем;

2) не позволяет эффективно управлять разработкой в условиях изменяющихся требований;

3) создает барьеры непонимания: аналитик не понимает руководителя проекта, разработчик – аналитика, тестировщик – разработчика и пр.;

4) не позволяет обеспечить контроль изменений в процессе выполнения работ;

5) не позволяет избежать субъективности в оценке качества разрабатываемых продуктов.

Модель (model) — абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме.

В ходе создания программных систем возникает необходимость разработки визуальных моделей.

Лучшие практики разработки ПО:

1) использование визуальных моделей при разработке ПО;

2) итеративная[2] разработка ПО;

3) управление требованиями;

4) управление изменениями и конфигурацией артефактов ПО;

5) использование компонентных архитектур;

6) непрерывное тестирование и верификация[3] качества ПО;

7) использование паттернов[4] проектирования;

8) использование CASE-средств и RAD-средств[5];

9) управление рисками:

¾ технологическими рисками;

¾ связанными с требованиями;

¾ связанными с квалификацией персонала проекта;

¾ политическими рисками.

Визуальное моделирование есть моделирование с использованием некоторой графической нотации.

На входе моделей неструктурированная информация. Информация может быть описана в любом виде (текстовом документе, интервьирование[6] сотрудников).

На выходе – модели ПО и бизнес-процессов. Модели должны адекватно отражать характер соответствующей предметной области. Необходима фиксация определенной нотации.

2 Жизненный цикл программного обеспечения. Стандарты, регламентирующие жизненный цикл

Одно из базовых понятий инженерии ПО – жизненный цикл ПО. Жизненный цикл ПО (ЖЦ ПО) – период времени от момента принятия решения о создании ПО до момента полного вывода ПО из эксплуатации. ЖЦ ПО регламентируется международными и национальными стандартами: ISO/IEC 12207: 1995, ГОСТ Р ИСО/МЭК 12207–99. В рамках технологий создания ПО понятие ЖЦ уточняется, но указанные стандарты не нарушаются.

Два взгляда на ЖЦ ПО: статический и динамический. Первый рассматривает ЖЦ как совокупность процессов ЖЦ. Процесс ЖЦ – набор взаимосвязанных действий, преобразующих некоторые входные данные и ресурсы в выходные. Каждый процесс характеризуется задачами, методами их решения, действующими лицами. Процессы ЖЦ протекают параллельно. Состав процессов ЖЦ ПО:

1) основные (приобретение, поставка, разработка, эксплуатация, сопровождение);

2) вспомогательные (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, совместная оценка, аудит, разрешение проблем);

3) организационные (управление, создание инфраструктуры, усовершенствование, обучение).

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

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

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

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

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

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

Процесс управления конфигурацией в себя следующие действия: подготовительную работу; создание базы знаний о ПО (конфигурации); контроль за конфигурацией; учет состояния конфигурации; оценку конфигурации; управление выпуском и поставку ПО. Конфигурация ПО – это совокупность сведений о его функциональных и физических характеристиках на всех стадиях ЖЦ ПО. Основная задача управления конфигурацией: организация, систематический учет и контроль внесения изменений в ПО.

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

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

Процесс аттестации состоит в определении полноты соответствия разработанного ПО требованиям заказчика. Основная задача аттестации – оценка достоверности тестирования ПО. Как правило, для аттестации привлекают независимых экспертов.

Процесс совместной оценки включает в себя следующие действия: подготовительную работу; оценку управления проектом; техническую оценку. Основная задача совместной оценки – контроль планирования и управления ресурсами, персоналом, инфраструктурой проекта.

Процесс аудита состоит в определении полноты соответствия проекта условиям договора.

Процесс разрешения проблем предусматривает анализ и разрешение проблем, возникающих в течение ЖЦ ПО.

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

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

Процесс усовершенствования предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО. Основная задача усовершенствования – повышение производительности труда.

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

Процессы ЖЦ ПО взаимосвязаны.

Динамический взгляд на ЖЦ ПО отражается в модели ЖЦ во времени. Модель ЖЦ ПО – это структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. В любой модели ЖЦ рассматривается как совокупность стадий ЖЦ. Стадия ЖЦ – это часть ЖЦ ограниченная временными рамками, по завершении которой достигается определенный важный результат в соответствии с требованиями для данной стадии ЖЦ.

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

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

1) получение в конце каждой стадии законченного набора проектной документации, отвечающего требованиям полноты и согласованности;

2) простота планирования процесса разработки.

Именно такую схему и используют обычно при блочно-иерархическом подходе к разработке сложных технических объектов, обеспечивая очень высокие параметры эффективности разработки. Однако данная схема оказалась применимой только к созданию систем, для которых в самом начале разработки удавалось точно и полно сформулировать все требования

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

Рисунок 1 - Каскадная схема разработки программного обеспечения

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

1) неточные спецификации, уточнение которых в процессе разработки может привести к необходимости пересмотра уже принятых решений;

2) изменение требований заказчика непосредственно в процессе разработки;

3) быстрое моральное устаревание используемых технических и программных средств;

4) отсутствие удовлетворительных средств описания разработки на стадиях постановки задачи, анализа и проектирования.

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

Модель с промежуточным контролем. Схема, поддерживающая итерационный характер процесса разработки, была названа схемой с промежуточным контролем (рис. 2). Контроль, который выполняется по данной схеме после завершения каждого этапа, позволяет при необходимости вернуться на любой уровень и внести необходимые изменения.

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

Рисунок 2 – Схема разработки программного обеспечения с промежуточным контролем

Спиральная модель. Для преодоления перечисленных проблем в середине 80-х годов XX в, была предложена спиральная схема (рис. 3). В соответствии с данной схемой программное обеспечение создается не сразу, а итерационно с использованием метода прототипирования, базирующегося на создании прототипов. Именно появление прототипирования привело к тому, что процесс модификации программного обеспечения перестал восприниматься, как «необходимое зло», а стал восприниматься как отдельный важный процесс.

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

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

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

1) сократить время до появления первых версий программного продукта;

2) заинтересовать большое количество пользователей, обеспечивая быстрое продвижение следующих версий продукта на рынке;

Рисунок 3 – Спиральная или итерационная схема разработки программного обеспечения

3) ускорить формирование и уточнение спецификаций за счет появления практики использования продукта;

4) уменьшить вероятность морального устаревания системы за время разработки.

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

3 Общие принципы проектирования систем. Модели программного обеспечения и их место в процессе проектирования

Одна из основных проблем при создании больших и сложных систем, в том числе ПО, – это проблема сложности. Подход к решению этой проблемы основан на принципе «разделяй и властвуй» (divide et impera). Сложная программная система должна быть разделена на небольшие подсистемы, каждую из которых можно разрабатывать независимо (в какой-то степени) от других. Декомпозиция является главным способом преодоления сложности разработки ПО. Принципы декомпозиции:

1) слабая связанность – low coupling (количество связей между отдельными подсистемами должно быть минимальным);

2) сильное сцепление – high cohesion (связность отдельных частей внутри каждой подсистемы должна быть максимальной).

Структура ПО должна удовлетворять следующим требованиям:

1) каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);

2) каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.

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

В рамках обоих подходов используются наглядные графические модели (схемы и диаграммы) для описания архитектуры ПО с различных точек зрения. Примеры: блок-схемы, диаграммы «сущность – связь», диаграммы классов. Модель ПО – это формализованное описание системы ПО на определенном уровне абстракции. Каждая модель описывает конкретный аспект системы, использует набор диаграмм или формальных описаний и документов заданного формата, а также отражает точку зрения и является объектом деятельности различных людей с конкретными интересами, ролями или задачами. Модели служат полезным инструментом анализа проблем, обмена информацией между всеми заинтересованными сторонами, проектирования ПО. Моделирование способствует более полному усвоению требований, улучшению качества системы и повышению степени ее управляемости.

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

Моделирование не является целью разработки ПО. Диаграммы – это лишь наглядные изображения. Причины, побуждающие прибегать к их использованию:

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

2) графические модели образуют внешнее представление системы и объясняют, что эта система будет делать, тем самым облегчают общение с заказчиком.

3) графические модели облегчают изучение методов проектирования, в частности объектно-ориентированных методов.

В процессе создания ПО используются следующие виды моделей:

1) модели деятельности организации (или модели бизнес-процессов):

а) модели "AS-IS" ("как есть"), отражающие существующее положение;

б) модели "AS-TO-BE" ("как должно быть"), отражающие представление о новых процессах и технологиях работы организации;

2) модели проектируемого ПО, которые строятся на основе модели "AS-TO-BE", уточняются и детализируются до необходимого уровня.

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

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

4 Объектная модель

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

Объектная модель является естественным способом представления реального мира. Она является концептуальной основой ООП. Основными принципами ее построения являются:

1) абстрагирование;

2) инкапсуляция;

3) модульность;

4) иерархия.

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

Инкапсуляция – локализация свойств и поведения в рамках единственной абстракции (рассматриваемой как «черный ящик»), скрывающей реализацию за общедоступным интерфейсом. Инкапсуляция – это отделение внутреннего устройства объекта от его внешнего поведения. Объектный подход предполагает, что внутренние ресурсы объекта, скрыты от внешней среды. Абстрагирование и инкапсуляция являются взаимодополняющими принципами.

Модульность – это декомпозиция системы в виде набора внутренне сильно сцепленных, но слабо связанных между собой подсистем (модулей). Модульность снижает сложность системы, позволяя выполнять независимую разработку отдельных модулей.

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

К основным понятиям объектно-ориентированного подхода (элементам объектной модели) относятся: объект; класс; атрибут; операция; полиморфизм; наследование; компонент; связь.

Объект – это сущность предметной области или программной системы, имеющий четко определяемое поведение. Любой объект обладает состоянием, поведением и индивидуальностью. Состояние объекта определяется значениями его свойств (атрибутов) и связями с другими объектами, оно может меняться со временем. Поведение определяет действия объекта и его реакцию на запросы от других объектов. Поведение представляется с помощью набора сообщений, воспринимаемых объектом (операций, которые может выполнять объект). Индивидуальность – это свойства объекта, отличающие его от всех других объектов.

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

Атрибут – поименованное свойство класса, определяющее диапазон допустимых значений, которые могут принимать экземпляры данного свойства. Атрибуты могут быть скрыты от других классов, это определяет видимость атрибута: рublic (общий, открытый); private (закрытый, секретный); protected (защищенный).

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

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

Наследование – это построение новых классов на основе существующих с возможностью добавления или переопределения свойств (атрибутов) и поведения (операций).

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

Между элементами объектной модели существуют различные виды связей:

1) ассоциация – это семантическая связь между классами;

2) агрегация – более сильный тип связи между целым и его частями;

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

4) обобщение – связь «тип – подтип».

Связи характеризуются: направлением; именем и ролевыми именами участников связи; мощностью.

5 Определение и история создания языка UML. Состав диаграмм UML

Unified Modeling Language (UML) — унифицированный язык моделирования для описания, визуализации и документирования объектно-ориентированных систем в процессе их анализа и проектирования.

Исторические корни языка UML относятся к раннему этапу развития объектно-ориентированного программирования и появлению новой парадигмы[7] – это объектно-ориентированного анализа и проектирования. В конце 80-ых годов эксперты отмечают «войну» методов, т.е. появление новых графических нотаций для представления визуальных моделей. Эти нотации пересекались между собой по определенным графическим системам обозначения, по принципам связанным с представлением классов, объектов предметной области и соответствующих методов. Основой послужили три нотации, разработанные тремя основными разработчиками языка UML. Основные разработчики языка UML (Three amigos): Grady Booch - Гради Буч (Booch method); Dr. James Rumbaugh - Джеймс Рамбо (Джим Румбах) (OMT); Dr. Ivar Jacobson - Айвар Джекобсон (Ивар Якобсон) (OOSE).

Появление языка связывают с 1996 годом, когда впервые аббревиатура UML появилась на свет. Версия языка была зафиксирована как 09. Этот язык послужил основой для включения в отдельные case инструменты, прежде всего в линейку продуктов компании Rational Software среди которых был инструмент Rational Rose. После появления версии 1.4, которая была реализована в case средстве IBM Rational Rose 2003, возникла ситуация, когда объявили версию языка UML2, но появился стандарт на версию 1.5. Окончательная версия стандарта языка UML2 появилась в 2005 году. В 2007 - 2008 годах эта версия дополнялась.

Основные разработчики языка UML2: Don Baisley; Morgan Bjorkander; Conrad Bock; Steve Cook; Philippe Desfray; Nathan Dykman; Anders Ek; David Frankel; Eran Gery; Oystein Haugen; Sridhar Iyengar; Cris Kobryn; Birger Moller-Pedersen; James Odell; Gunnar Overgaard; Karin Palmkvist; Guus Ramackers; Jim Rumbaugh; Bran Selic; Thomas Weigert; Larry Williams.

Из трех основных разработчиков языка в разработке версии UML2 остался только Jim Rumbaugh. Его появление предопределило некоторые тенденции, которые нашли свое выражение в рамках стандарта.

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

Язык UML не является методологией.

Язык UML не является процессом.

Язык UML не является языком программирования.

Язык UML не является формальным языком.

UML = нотация + семантика!

Назначение языка UML:

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

2) снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области;

3) графическое представление моделей в нотации UML не должно зависеть от конкретных языков программирования и инструментальных средств проектирования;

4) описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП;

5) способствовать распространению объектных технологий и поощрять развитие рынка программных инструментальных средств;

6) интегрировать в себя новейшие и наилучшие достижения практики ООАП.

Особенности изображения диаграмм в нотации UML.

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

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

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

Строки текста. Служат для представления различных видов информации в некоторой грамматической форме.

Общие рекомендации по изображению диаграмм в нотации языка UML:

1) каждая диаграмма должна служить законченным представлением соответствующего фрагмента моделируемой предметной области;

2) все сущности на диаграмме модели должны быть одного концептуального уровня;

3) вся информация о сущностях должна быть явно представлена на диаграммах;

4) диаграммы не должны содержать противоречивой информации;

5) диаграммы не следует перегружать текстовой информацией;

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

Противоречивость и адекватность моделей в нотации UML:

1) модель, соответствующая правилам нотации или семантики языка UML называется непротиворечивой (well-formed model);

2) модель, нарушающая правила нотации или семантики языка UML называется противоречивой (ill-formed model);

3) здесь могут быть использованы формальные критерии – соответствие спецификации языка UML!

4) модель, достаточно полно и правильно отражающая предметную область или решаемую проблему называется адекватной

5) модель, не достаточно полно или неправильно отражающая предметную область или решаемую проблему называется не адекватной

6) здесь могут быть использованы только неформальные критерии – субъективное мнение экспертов!

7) моя модель – это не ваша модель, а ваша модель – не моя…

Классификаторы – основные элементы языка UML.

Прямоугольник – основной символ для графического изображения классификатора

Классификация моделей в языке UML:

1) структурные модели (structured models) – модели, предназначенные для описания статической структуры сущностей или элементов некоторой системы, включая их классы, интерфейсы, атрибуты и отношения:

а) диаграммы классов, моделирующие статическую структуру классов системы и связи между классами;

б) диаграммы компонентов, моделирующие иерархии компонентов ПО;

в) диаграммы размещения, моделирующие физическую архитектуру системы;

2) модели поведения (behavioral models) – модели, предназначенные для описания процесса функционирования элементов системы, включая их методы и взаимодействие между ними, а также процесс изменения состояний отдельных элементов и системы в целом:

а) диаграммы вариантов использования, моделирующие бизнес-процессы и требования к ПО;

б) диаграммы взаимодействия (диаграммы последовательности и коммуникационные диаграммы), моделирующие обмен сообщениями между объектами;

в) диаграммы состояний, моделирующие поведение объектов;

г) диаграммы деятельности, моделирующие поведение системы в целом и потоки управления.

В UML 2.0 введены новые типы диаграмм, которых ранее не было: диаграммы обзора взаимодействия, временные диаграммы и диаграммы составных структур.

6 Назначение диаграммы вариантов использования. Основные обозначения. Отношения на диаграмме вариантов использования

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

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

Диаграмма вариантов использования (use case diagram) - диаграмма, на которой изображаются варианты использования проектируемой системы, заключенные в границу системы, и внешние актеры, а также определенные отношения между актерами и вариантами использования.

Назначение диаграммы вариантов использования:

1) определить общие границы функциональности проектируемой системы в контексте моделируемой предметной области;

2) специфицировать требования к функциональному поведению проектируемой системы в форме вариантов использования;

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

4) подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.

Основные обозначения на диаграмме вариантов использования

Вариант использования (use case):

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

2) отвечает на вопрос «Что должна выполнять система?», не отвечая на вопрос «Как она должна выполнять это?».

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

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

Отношения на диаграмме вариантов использования:

1) отношение ассоциации. Применительно к диаграммам вариантов использования отношение ассоциации может служить только для обозначения взаимодействия актера с вариантом использования.

2) отношение включения. Отношение зависимости (dependency) определяется как форма взаимосвязи между двумя элементами модели, предназначенная для спецификации того обстоятельства, что изменение одного элемента модели приводит к изменению некоторого другого элемента.

В отношении зависимости присутствуют два элемента: клиент зависимости, расположенный на противоположной от стрелки конце и источник зависимости или независимый элемент.

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

При оформлении заказа в Интернет-магазине всегда выполняется регистрация покупателя. Если в контексте соответствующего сценария используется слово всегда, то это служит определенным признаком для указания отношения включения.

3) отношение расширения (extend) определяет взаимосвязь одного варианта использования с некоторым другим вариантом использования, функциональность или поведение которого задействуется первым не всегда, а только при выполнении некоторых дополнительных условий.

При отношении расширения клиентом зависимости становится расширяющий use-case, а источником зависимости является базовый use-case. Оформление заказа в Интернет-магазине – базовый use-case, а предоставлении бонусной скидки постоянному покупателю – расширяющий use-case. Расширяющий вариант использования вызывается тогда и только когда эти условия принимают значение истина, в противном случае этот вариант использования игнорируется.

Изображение отношения расширения с условием выполнения

Изображение условий может быть различно, например, можно изобразить в виде специального текста, записанного в форме примечания. Причем примечание относится к специальному объекту, который имеет виртуальный характер (графического символа нет) и называется этот объект extension point (точка расширения). Точка расширения концентрирует внимание разработчика на условие, которое является определяющим при вызове расширяющего варианта использования, т.е. в данном случае, предоставление бонусной скидки постоянному покупателю. В качестве условия соответствующая функциональность будет вызываться только тогда, когда клиент имеет бонусную карточку, о чем конкретно указано в форме примечания, а текст, заключенный в фигурные скобки по формату соответствует записи ограничений или условий. Условие должно быть выполнено для того, что бы расширяющий вариант использования был вызван и реализован системой.

4) отношение обобщения (generalization relationship) предназначено для спецификации того факта, что один элемент модели является специальным или частным случаем другого элемента модели. Применяется в контексте однотипных элементов.

Треугольник указывает на более общий элемент (более абстрактный), а на противоположном конце от стрелки указывается специализация этого элемента или дочерний элемент. Вариант А – общий use-case. Вариант В – частный use-case.

Пример диаграммы вариантов использования для системы продажи товаров в Интернет-магазине.

Основное достоинство диаграммы использования – это визуальный характер представляемых элементов и соответствующая простота анализа. Диаграммы вариантов использования не исчерпывают модели use-case. В дополнении к каждому use-case(у) необходимо на практике описать те действия, которые выполняет система при реализации соответствующего use-case(а). Эта информация фиксируется в форме специального текста, который получил название сценарий. Сценарий позволяет дополнить графическое представление описанием тех действий, которые нужно выполнить в контексте реализации соответствующей функциональности. Форма написания сценария может быть произвольной.

Сценарий (scenario) – специально написанный текст, который описывает поведение моделируемой системы в форме последовательности выполняемых действий актеров и самой системы.

На диаграмме use-case каждой цели будет соответствовать базовый use-case. Типичный ход событий, приводящий к успеху, будет описывать сценарий для базового use-case(а). Каждое из исключений будет соответствовать, в общем случае, отдельному (вторичному) use-case(у), который связан с базовым отношением расширения. Визуализация вторичных use-case(ов) при соответствии на отдельном исключении фиксируется только в том случае, если нет необходимости изменять дополнительный ход событий, т.е. если исключение изменяет типичный ход событий, то это изображается графически при помощи вторичного use-case(а) с отношением расширения. Если он не изменяет типичного хода события, а только лишь сокращает выполнение некоторых действий, то графически нет необходимости изображать в форме отдельного use-case(а).

Последовательность разработки вариантов использования:

1) определить главных (первичных) актеров и определить их цели по отношению к системе;

2) специфицировать все базовые (основные) варианты использования;

3) выделить цели базовых ВИ, интересы актеров в контексте этих ВИ, предусловия и постусловия ВИ;

4) написать успешный сценарий выполнения базовых ВИ;

5) определить исключения (неуспех) в сценариях ВИ и написать сценарии для всех исключений

6) выделить ВИ исключений и изобразить их со стереотипом «extend»;

7) выделить общие фрагменты функциональности ВИ и изобразить их отдельными ВИ со стереотипом «include».

7 Диаграмма классов. Разновидности классов. Атрибут класса. Операции класса. Отношения на диаграмме классов

Диаграмма классов (class diagram) — диаграмма, предназначенная для представления модели статической структуры программной системы в терминологии классов объектно-ориентированного программирования.

Диаграмма классов представляет собой граф, вершинами или узлами которого являются элементы типа “классификатор”, которые связаны различными типами структурных отношений.

Классификатор (classifier) – специальное понятие, предназначенное для классификации экземпляров, которые имеют общие характеристики.

Характеристика (feature) – понятие, предназначенное для спецификации особенностей структуры и поведения экземпляров классификаторов:

1) структурная характеристика (structural feature) является типизированной характеристикой классификатора, которая специфицирует структуру его экземпляров;

2) характеристика поведения (behavioral feature) является характеристикой классификатора, которая специфицирует некоторый аспект поведения его экземпляров.

Класс (class) – элемент модели, который описывает множество объектов, имеющих одинаковые спецификации характеристик, ограничений и семантики.

Основные обозначения на диаграмме

Варианты графического изображения класса на диаграмме классов

Разновидности классов:

1) абстрактный (abstract) класс не имеет экземпляров или объектов, для обозначения его имени используется наклонный шрифт (курсив);

2) активный класс (active class) – класс, каждый экземпляр которого имеет свою собственную нить управления;

3) пассивный класс (passive class) – класс, каждый экземпляр которого выполняется в контексте некоторого другого объекта.

Квалифицированное имя (qualified name) используется для того, чтобы явно указать, к какому пакету относится тот или иной класс. Для этого применяется специальный символ в качестве разделителя имени – двойное двоеточие “::”.

Имя класса без символа разделителя называется простым именем класса.

Атрибут (attribute) класса – служит для представления отдельной структурной характеристики или свойства, которое является общим для всех объектов данного класса:

<атрибут>::= [<видимость>] [‘/’] <имя> [‘:’ <тип атрибута>] [‘[‘<кратность>‘]’] [‘=’ <значение по умолчанию>] [‘{‘<модификатор атрибута> [‘,’ <модификатор атрибута>]* ’}’]

Примеры записи атрибутов:

+ имяСотрудника: String {readOnly}

~ датаРождения: Data {readOnly}

# /возрастСотрудника: Integer

+ номерТелефона: Integer [1..*] {unique}

– заработнаяПлата: Currency = 500.00

Операция (operation) класса служит для представления отдельной характеристики поведения, которая является общей для всех объектов данного класса

Общий формат записи отдельной операции класса следующий:

<операция>::=[<видимость>] <имя операции> ‘(‘ [<список параметров>] ‘)’ [‘:’ [<тип возвращаемого результата>] ‘{‘ <свойство операции> [‘,’ <свойство операции>]* ‘}’]

Примеры записи операций

добавить(in номерТелефона: Integer [*] {unique})

–изменить(in заработнаяПлата: Currency)

+создать(): Boolean

toString(return: String)

toString(): String

Отношения на диаграмме классов

Ассоциация (association) – произвольное отношение или взаимосвязь между классами

Имя конца ассоциации специфицирует роль (role), которую играет класс, расположенный на соответствующем конце рассматриваемой ассоциации

Видимость конца ассоциации специфицирует возможность доступа к соответствующему концу ассоциации с других ее концов.

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

Символ наличия навигации (navigable) изображается с помощью простой стрелки в форме буквы «V» на конце ассоциации.

Символ отсутствия навигации (non navigable) изображается с помощью буквы «X» на линии у конца ассоциации.

Ассоциация с навигацией и эквивалентное ему представление класса с атрибутом

Варианты изображения навигации и кратности у концов ассоциации

Исключающая ассоциация между тремя классами

Пример тернарной ассоциации

Пример 4-арной ассоциации

Ассоциация класс (association class) – элемент модели, который имеет свойства, как ассоциации, так и класса, и предназначенный для спецификации дополнительных свойств ассоциации в форме атрибутов и, возможно, операций класса.

Обобщение (generalization) – таксономическое отношение между более общим классификатором (родителем или предком) и более специальным классификатором (дочерним или потомком)

Примеры отношения обобщения

Множественное наследование – в языке UML разрешено

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

Пример отношения агрегации

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

Пример отношения композиции

8 Назначение диаграммы последовательности. Объекты, их графическое представление. Линия жизни и фокус управления. Особенности изображения моментов создания и уничтожения объектов

Диаграмма последовательности (sequence diagram) - диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления.

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

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

Каждый объект графически изображается в форме прямоугольника и располагается в верхней части своей линии жизни (рис.1). Внутри прямоугольника записываются собственное имя объекта со строчной буквы и имя класса, разделенные двоеточием. При этом вся запись подчеркивается, что является признаком объекта, который, представляет собой экземпляр класса.

Если на диаграмме последовательности отсутствует собственное имя объекта, то при этом должно быть указано имя класса. Такой объект считается анонимным. Может отсутствовать и имя класса, но при этом должно быть указано собственное имя объекта. Такой объект считается сиротой. Роль классов в именах объектов на диаграммах последовательности, как правило, не указывается.

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

Рис.1 - Графические элементы диаграммы последовательности

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

Линия жизни объекта (object lifeline) - вертикальная линия на диаграмме последовательности, которая представляет существование объекта в течение определенного периода времени.

Линия жизни объекта изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей рабочей области диаграммы последовательности от самой верхней ее части до самой нижней (объект 1 и анонимный объект Класса 2 на рис. 1).

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

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

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

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

Фокус управления изображается в форме вытянутого узкого прямоугольника (объект а на рис.1), верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона - окончание фокуса управления (окончание активности). Этот прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни (объект a на рис. 8.2), если на всем ее протяжении он активен.

Периоды активности объекта могут чередоваться с периодами его пассивности или ожидания. В этом случае у такого объекта фокусы управления изменяют свое изображение на линию жизни и наоборот (объект сирота ob2 на рис.2). Важно понимать, что получить фокус управления может только объект, у которого в этот момент имеется линия жизни. Если же объект был уничтожен, то вновь возникнуть в системе он уже не может. Вместо него может быть создан лишь экземпляр этого же класса, который, строго говоря, будет другим объектом.

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

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

Если в результате рефлексивного сообщения создается новый подпроцесс или нить управления, то говорят о рекурсивном или вложенном фокусе управления. На диаграмме последовательности рекурсия обозначается небольшим прямоугольником, присоединенным к правой стороне фокуса управления того объекта, для которого изображается данное рекурсивное взаимодействие (анонимный объект Класса 2 на рис. 3).

Рис. 3 - Графическое изображение актера, рефлексивного сообщения и рекурсии на

диаграмме последовательности

На диаграмме последовательности все сообщения упорядочены по времени своей передачи в моделируемой системе, хотя номера у них могут не указываться.

На диаграммах последовательности могут присутствовать три разновидности сообщений, каждое из которых имеет свое графическое изображение (рис.4).

Рис.4 - Графическое изображение различных видов сообщений между объектами на

диаграмме последовательности

Первая разновидность сообщения (рис.4, а) наиболее распространена и используется для вызова процедур, выполнения операций или обозначения отдельных вложенных потоков управления. Начало этой стрелки, как правило, соприкасается с фокусом управления того объекта-клиента, который инициирует это сообщение. Конец стрелки соприкасается с линией жизни того объекта, который принимает это сообщение и выполняет в ответ определенные действия. При этом принимающий объект может получить фокус управления, становясь в этом случае активным. Передающий объект может потерять фокус управления или остаться активным.

Вторая разновидность сообщения (рис.4, б) используется для обозначения простого асинхронного сообщения, которое передается в произвольный момент времени. Передача такого сообщения обычно не сопровождается получением фокуса управления объектом-получателем.

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

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

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

9 Проектирование классов. Проектирование баз данных

Проектирование элементов системы выполняется проектировщиками и включает:

1) уточнение описания вариантов использования;

2) проектирование классов;

3) проектирование баз данных.

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

Проектирование классов включает следующие действия:

1) детализация проектных классов;

2) уточнение операций и атрибутов;

3) моделирование состояний для классов;

4) уточнение связей между классами.

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

Классы-сущности с учетом соображений производительности и защиты данных могут разбиваться на ряд классов. Основанием для разбиения является наличие

Дата добавления: 2015-09-30