Справа на форме отображаются сведения об альбоме, такие как, «Исполнитель», «Название альбома», «Стиль», «Год выпуска», «Описание».
Поиск осуществляется с помощью компонента Query, в котором формируется SQL-запрос на выборку. Полученный результат отправляется в компонент DataSource и после этого отображается в компоненте DBGrid. Ниже представлен вариант поиска исполнителя по названию. Рис. 3.7. Поиск по критериям Итак, проанализировав предметную область и поставленную задачу, с помощью программы Rational Rose была разработана концептуальная модель информационно — справочной системы музыки на CD. Затем эта модель была реализована в Borland Delphi 7. В результате получилась удобная и наглядная система, с помощью которой пользователь всегда будет знать о том, какие альбомы и каких исполнителей имеются в его фонотеке, добавлять данные при приобретении нового диска или удалять при утере. В [7] приводится пример подробной разработки модели медицинского учреждения средствами UML.
Выводы Проектирование информационной системы начинается с определения основных задач, решаемых системой. На этом этапе с успехом можно использовать диаграммы прецедентов UML, при этом необходимо выделить внешние по отношение к системе элементы — актеры, ввести прецеденты, описывающие внешнее поведение системы и определить связи между ними. Cструктура программной системы задается структурой классов. Диаграммы классов UML предоставляют мощные средства специфицирования классов. Грамотное использование наследования и полиморфизма, применение интерфейсов составляют основу построения эффективной модели статического вида с точки зрения разработки. Для описания поведенческих (динамических) аспектов данного вида модели системы используются взаимодействия. Большинство современных информационных систем в своем информационном ядре имеют базу данных. UML имеет возможности моделирования реляционного профиля базы данных, разработка которого базируется на объектно-ориентированной модели, построенной на предыдущих этапах. Разработанная структура базы данных должна удовлетворять условиям нормализации и не содержать аномалий. Развитые CASE-средства, построенные на основе UML (прежде всего Rational Rose) поддерживают связь с средствами программирования, что позволяет осуществлять переход от модели к исходному коду программы (прямое проектирование) и обратно (обратное проектирование), что создает основу для эффективной поддержки программных приложений и их модернизации.
Контрольные вопросы 1. Объясните понятия «прецедент» и «актер».
2.
На каком этапе проектирования используется диаграмма прецедентов, какие элементы она содержит?
3. Какие средства UML имеются для моделирования статического вида системы с точки зрения проектирования. 4. Какова роль интерфейсов при моделировании вида системы с точки зрения проектирования. 5. Что показывают диаграммы взаимодействия?
Какие виды диаграмм взаимодействия вы знаете? 6. Как от объектно-ориентированной модели перейти к модели профиля базы данных?
7. Дайте определения первых трех нормальных форм реляционных баз данных, приведите примеры. 8. Какие инструментальные средства имеет Rational Rose для связи с средствами программирования? 9.
Охарактеризуйте основные этапы процесса моделирования информационной системы средствами UML. Какие диаграммы применяются на каждом этапе? Упражнения Построить модель информационной системы ВУЗа. 1) На диаграмме классов. Создать классы: Вуз; Факультет; Кафедра; Курс (в смысле дисциплина) ; Группа; Преподаватель; Студент. Ввести атрибуты name (имя) для всех классов; IDz (номер зачетки) — для студента; Address (дом. адрес) для преподавателя , студента, вуза. Должность, ученая степень, ученое звание, стаж работы для преподавателя. Ввести дополнительные атрибуты на Ваше усмотрение, задать типы атрибутов. Подумайте, как с помощью обобщения можно упростить описание объектов студент и преподаватель (например, можно выделить суперкласс Person (Персона) с атрибутами Ф.И.О., дом. адрес, дом. телефон.) Ввести операции для объекта Вуз: определяющие поступление, окончание, отчисление студента; прием на работу и увольнение преподавателя; Группа, Факультет: перевод студента из и в группу/факультет. Ввести еще операции на Ваше усмотрение, задать типы параметров и возвращаемых значений. Изобразить отношения, при этом использовать Отношения агрегации: обучается-в , состоит-из; Ассоциации: читает (курс), посещают (курс), работает-на, является-деканом, зав-кафедрой. Укажите типы множественности на концах ассоциаций. Можете привести еще несколько ассоциаций и/или зависимостей. Будем предполагать, что электронная система учёта содержит электронные копии зачетных книжек, ведомостей, журналов групп и некоторую базу данных. Введите объекты студ-билет, зач-книжка, ведомость, журнал-группы, сделайте их атрибутами соответствующих объектов или связей.
Для объекта студ-билет можно ввести атрибут номер и написать требования в текстовой форме. Для объекта зач-книжка введите следующие атрибуты: Номер-зачетки; Листы. Листы, в свою очередь, имеют атрибуты: курс, тип-листа (практический курс, теореоретический курс, практика и т.д.) ; записи массив типа запись[] (каждая запись соответствует записи в зачетной книжке, укажите атрибуты для типа запись). При описании типов перечислений (курс, тип-листа и т.д. ) для атрибутов воспользуйтесь сигнатурой класса со стереотипом «enumeration». Аналогично записям зачетной книжки введите записи ведомости. На общей диаграмме классов учетную базу данных можно не отображать.
2) Постройте диаграмму прецедентов. Актеры: студент, преподаватель, система учета. Прецеденты: связанные со студентом: поступление, окончание, отчисление; связанные с преподавателем: поступление на работу, увольнение. Предполагается, что все действия фиксируются системой учета.
Для прецедента поступление можно выделить составляющую часть прецедент регистрация, который предполагает действия: зачисление в группу, выдача зачетной книжки, билета, пополнение базы данных соответствующей информацией.
Раскройте прецедент регистрация соответствующей дочерней диаграммой прецедентов с использованием стереотипных зависимостей «include». Раскройте прецедент, о пополнение базы данных соответствующей информацией диаграммой последовательностей. При этом будем предполагать, что пополнение базы данных происходит в интерактивном режиме с помощью прикладной интерфейсной программы, ввод осуществляется посредством форм ввода. Диаграмма последовательностей должна содержать объекты: Форма -студенты, содержит списки студентов и основные атрибуты студентов. Форма -подробная информация, содержит подробную информацию о студентах. Далее можно выделить как объекты диаграммы последовательности: менеджер записей о студентах (как элемент программы учета), собственно запись о студенте, и менеджер транзакций. Пользуясь аналогиями лабораторной работы по взаимодействиям (№ 2) определите сообщения. Преобразуйте данную диаграмму последовательностей в диаграмму коопераций, придайте ей наглядный вид. ЗАКЛЮЧЕНИЕ Язык графических нотаций UML разработан для описания, документирования и формализации процесса разработки объектно-ориентированных программных систем. Основным выразительным средством языка являются диаграммы, раскрывающие модель системы с определенной точки зрения в определенном контексте. Можно выделить основные этапы разработки системы с использованием средств UML: 1) описание задания в общих чертах на естественном языке; 2) выделение прецедентов и актеров бедующей системы; 3) определение объектов и взаимодействий между ними; 4) детализация функциональности с помощью диаграмм последовательности (переходов) для каждого прецедента; 5) группировка объектов, переход от объектов и сущностей к компонентам; 6) ревизия результатов предыдущих этапов; 7) детальная проработка реализации компонентов, разделение компонентов по участникам коллектива разработчиков; 8) Построение профиля баз данных с учетом способа хранения данных в выбранной СУБД; 9) размещение компонентов системы; 10) кодирование. Каждый этап поддерживается соответствующими UML-диаграммами. При этом следует иметь ввиду, что процесс разработки программной системы является интерактивным, предполагает периодические возвращения на предыдущие этапы и повторный пересмотр некоторых элементов модели.
Использование средств обратного проектирования позволяет заметно повысить эффективность и сократить время разработки. Язык UML является открытым языком.
Механизмы расширения позволяют построить развернутую модель с учетом специфических особенностей конкретной предметной области, оттенить некоторые нюансы структуры и поведения вводимых элементов. Язык постоянно развивается, новые версии языка содержат расширенный набор стереотипов для моделирования бизнес-отношений, хранилищ данных, WEB-приложений.
На базе новых стереотипных классов строятся новые диаграммы, например диаграмма бизнес-прецедентов (используется на начальном этапе проектирования при проведении так называемого бизнес-моделирования), содержащая не так давно введенные бизнес-актеры и бизнес-прецеденты. Интерес профессионалов к языку UML постоянно растет, ведущие фирмы производители средств разработки программного обеспечения встраивают в инструментарий своих продуктов возможности построения диаграмм UML; разрабатываются всевозможные прогаммы-мосты между средствами программирования и средствами моделирования на основе UML. Использование рационального унифицированного процесса разработки и детально проработанной средствами UML модели позволяют избежать ряда ошибок концептуального и частного плана, создает хорошую методологическую основу для поддержки и развития разрабатываемых программных средств. БИБЛИОГРАФИЧЕСКИЙ СПИСОК 1.
Буч Г. Рамбо Дж., Джекобсон А. UML Руководство пользователя: Пер.
с англ.- М.: ДМК Пресс, 2001. — 423 с.: ил. 2. Фаулер М., Скотт К.
UML в кратком изложении. Применение стандартного языка объектного моделирования.
Пер. с англ.- М. Мир, 1999. — 192 с.: ил. 3. Боггс У., Боггс.
М.
UML Rational Rose. — М.: Издательство «Лори», 2002.
— 510 с. 4.
Липаев В.В. Проектирование программных средств: Учебное пособие для вузов.- М.Высшая школа, 1990.-303 с., ил.
5.
Лучко О. Н. и др. Базы данных: Учебное пособие. Лучко О. Н. Морарь Е.
В. Червенчук И.
В. Омск: Изд-во ОГИС, 2003.
— 168 с.
6.
Мюллер Р. Дж. Базы данных и UML. Проектирование. Пер.
с англ.- Изд-во ЛОРИ, 2000. — 420с.: ил. 7.
Нейбург Э. Дж., Максимчук Р. А. Проектирование баз данных с помощью UML — Вильямс, 2002. — 228 с. «Проектирование на Rose Delphi Link» (http://www.interface.ru/fset.asp?Url=/rational/rational.htm) Электронная версия учебника по UML (http://www.isuct.ru/~ivt/books/CASE/case6.html ) Словарь терминов и определений UML (Unified Modeling Language) — Унифицированный язык моделирования, предназначенный для визуализации, специфицирования, конструирования и документирования артефактов программных систем. Абстрактный класс — класс, для которого нельзя непосредственно создать экземпляры объектов. Абстракция — важная характеристика сущности, отличающая ее от всех иных сущностей. Абстракция проводит границу между сущностями лишь с какой-то определенной точки зрения. Автомат — поведение, которое специфицирует последовательность состояний, через которые проходит объект на протяжении своего жизненного цикла, реагируя на события, включая описание реакций на эти события. Агрегат — класс, представляющий «целое» в отношении агрегирования. Агрегирование — специальный вид ассоциации, описывающий отношение между агрегатом (целым) и компонентом (частью). Актер — множество логически связанных ролей, исполняемых при взаимодействии с прецедентами. Активный класс — класс, экземплярами которого являются активные объекты. Активный объект — объект, который владеет процессом или нитью и может инициировать управляющее воздействие. Аргумент — фактическое значение, соответствующее формальному параметру. Артефакт — элемент информации, используемый или порождаемый в процессе разработки программного обеспечения. Архитектура — совокупность существенных решений об организации программной системы; набор структурных элементов и интерфейсов, из которых она состоит, вкупе с поведением, описываемым в терминах коопераций этих элементов; составление из данных структурных и поведенческих элементов все более крупных систем; архитектурный стиль, которому подчинена организация элементов, интерфейсов, коопераций и их композиции. Ассоциация — структурное отношение, описывающее набор связей, в котором каждая из них представляет собой соединение между объектами; семантическое отношение между двумя или более классификаторами, в котором участвуют соединения между их экземплярами. Версия — относительно полный и самосогласованный набор артефактов, предназначенный для внутреннего или внешнего использования. Взаимодействие — поведение, описываемое набором сообщений, которыми об-‘ мениваются между собой объекты в некотором контексте для достижения определенной цели. Вид (представление) — проекция модели, рассматриваемой с определенной точки зрения, в которой высвечены детали, важные в данном аспекте, и опущены несущественные. Вид (представление) системы с точки зрения прецедентов — вид системной архитектуры, охватывающий прецеденты, с помощью которых описывается поведение системы с точки зрения конечных пользователей, аналитиков и тех, кто тестирует программы. Вид (представление) с точки зрения проектирования — вид системной архитектуры, охватывающий классы, интерфейсы и кооперации, которые образуют словарь задачи и ее решения. Этот вид обращен к функциональным требованиям, предъявляемым к системе. Вид (представление) с точки зрения процессов — вид системной архитектуры, охватывающий процессы и нити, которые формируют механизмы параллельности и синхронизации.
Этот вид фокусирует внимание на производительности, масштабируемости и пропускной способности системы. Вид (представление) с точки зрения развертывания — вид системной архитектуры, охватывающий узлы, образующие топологию аппаратных средств, на которых система исполняется. Этот вид отражает распределенность, поставку и установку частей, из которых составлена система. Вид (представление) с точки зрения реализации — вид системной архитектуры, охватывающий компоненты, используемые при сборке и выпуске физической системы. Этот вид важен для управления конфигурированием версий системы, составленной из независимых (до определенной степени) компонентов, которые могут быть по-разному собраны для получения работающего комплекса. Видимость — указывает, при каких обстоятельствах то или иное имя видимо и может быть использовано.
Внедрение — четвертая фаза цикла разработки программного обеспечения, в течение которой оно передается пользователям. Выражение — строка, которая может быть использована для получения значения определенного типа.
Делегирование — способность объекта посылать сообщение другому объекту в ответ на получение сообщения. Деятельность — протяженное во времени неатомарное вычисление внутри автомата. Диаграмма — графическое представление множества элементов. Обычно изображается в виде графа с вершинами (сущностями) и ребрами (отношениями). Диаграмма взаимодействия — диаграмма, на которой представлено взаимодействие, состоящее из множества объектов и отношений между ними, включая и сообщения, которыми они обмениваются. Диаграммы взаимодействия относятся к динамическому виду системы. Этот обобщенный термин применяется к нескольким видам диаграмм, в которых делается акцент на взаимодействии объектов, в том числе к диаграммам кооперации, последовательности и деятельности. Диаграмма деятельности — диаграмма, на которой представлены переходы потока управления от одной деятельности к другой. Диаграммы деятельности относятся к динамическому аспекту поведения системы. Это разновидность диаграмм состояний, где все или большая часть состояний являются состояниями деятельности, а все или большая часть переходов срабатывают при завершении деятельности в исходном состоянии. Диаграмма классов — диаграмма, на которой представлено множество классов, интерфейсов, коопераций и отношений между ними; диаграммы классов относятся к статическому виду системы. Иными словами, это диаграмма, на которой показано множество декларативных (статических) элементов. Диаграмма компонентов — диаграмма, на которой изображена организация некоторого множества компонентов и зависимости между ними; относится к статическому виду системы. Диаграмма кооперации — диаграмма взаимодействий, в которой основной акцент сделан на структурной организации объектов, посылающих и получающих сообщения. На этой диаграмме изображено, как организованы взаимодействия между экземплярами и какие между ними существуют связи. Диаграмма объектов — диаграмма, на которой представлено множество объектов и отношений между ними в некоторый момент времени. Диаграммы объектов относятся к статическому виду системы с точки зрения проектирования или процессов. Диаграмма последовательностей — диаграмма взаимодействия, в которой основной акцент сделан на временном упорядочении сообщений. Диаграмма прецедентов — диаграмма, на которой представлено множество прецедентов и актеров, а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы. Диаграмма развертывания — диаграмма, на которой представлена конфигурация обрабатывающих узлов и размещенные на них компоненты; относится к статическому виду системы. Диаграмма состояний — диаграмма, на которой изображен автомат; диаграммы состояний относятся к динамическому виду системы.
Динамическая классификация — семантическая разновидность обобщения, при которой объект может изменять тип или роль.
Динамический вид — аспект системы, в котором основное внимание уделено ее поведению. Дополнение — деталь элемента спецификации, добавляемая к его базовому графическому символу. Дорожка — разбиение диаграммы взаимодействия для распределения ответственности за действия. Зависимость — семантическое отношение между двумя сущностями, при которой изменение одной (независимой) сущности может повлиять на семантику другой (зависимой). Задача — путь выполнения программы, динамической модели или иного представления потока управления; процесс или нить. Запрос — спецификация стимула, посылаемого объекту. Значение — элемент области определения типа.и. Имя — название сущности, отношения или диаграммы; строка, идентифицирующая элемент. Инкрементный подход: в контексте цикла разработки программного обеспечения — процесс непрерывного развития архитектуры системы, когда каждая новая версия содержит улучшения по сравнению с предыдущей. Интерфейс — множество операций, составляющее спецификацию услуг, которые предоставляет класс или компонент.
Исполнение — прогон динамической модели.
Использование — зависимость, при которой один элемент (клиент) для правильного функционирования требует наличия другого элемента (поставщика). Исследование — вторая фаза цикла разработки программного обеспечения, в ходе которой определяется общее видение продукта и его архитектура. Итеративный подход: в контексте цикла разработки программного обеспечения — процесс управления потоком исполняемых версий. Итерация — четко очерченный перечень работ, Для которых определены конечная цель и критерий оценки. В результате нескольких итераций должна быть выпущена версия для внутреннего или внешнего использования. Квалификатор — атрибут ассоциации, значения которого разбивают множество объектов, связанных с некоторым объектом посредством данной ассоциации, на непересекающиеся подмножества. Класс — описание множества объектов, обладающих общими атрибутами, операциями, отношениями и семантикой.
Класс-ассоциация — элемент модели, обладающий свойствами как класса, так и ассоциации. Класс-ассоциацию можно рассматривать либо как ассоциацию, обладающую свойствами класса, либо как класс, обладающий свойствами ассоциации. Классификатор — механизм, с помощью которого описываются структурные и поведенческие особенности. К числу классификаторов относятся классы, интерфейсы, типы данных, сигналы, компоненты, узлы, прецеденты и подсистемы. Клиент — классификатор, запрашивающий услугу у другого классификатора.
Комментарий — аннотация, присоединенная к элементу или множеству элементов. Композит — класс, который связывается с одним или несколькими классами посредством отношения композиции. Композиция — форма агрегирования, в которой целое владеет своими частями, имеющими одинаковое время жизни. Части с нефиксированной кратностью могут быть созданы после создания самого композита, но, будучи созданными, живут и умирают вместе с ним; такие части могут быть и явно удалены до момента уничтожения композита. Компонент — физическая заменяемая часть системы, реализующая спецификацию интерфейсов.
Контекст — множество взаимосвязанных элементов, предназначенное для определенной цели, например для специфицирования операции.
Концевая точка ассоциации — точка, в которой ассоциация соединяется с классификатором. Концевая точка связи — экземпляр концевой точки ассоциации. Кооперация — множество ролей и других элементов, совместно работающих для обеспечения кооперативного поведения, которое оказывается более значимо, чем сумма его составляющих; спецификация того, как элемент наподобие прецедента или операции реализуется посредством набора классификаторов и ассоциаций, играющих конкретные роли и используемых конкретным способом. Кратность — спецификация диапазона возможных значений мощности множества. Метакласс — класс, экземплярами которого являются классы.
Метод — реализация операции. Механизм — образец (паттерн) проектирования, применимый к сообществу классов. Механизм расширения — один из трех механизмов (стереотипы, помеченные значения и ограничения), с помощью которых можно контролируемым способом расширять язык UML. Множественная классификация — семантическая разновидность обобщения, в которой объект может непосредственно принадлежать более чем одному классу. Множественное наследование — семантическая разновидность обобщения, в которой потомок может иметь более чем одного родителя. Модель — упрощение реальности, создаваемое для лучшего понимания разрабатываемой системы; семантически замкнутая абстракция системы. Мощность множества — число элементов в множестве.
Наследование — механизм, с помощью которого более специализированные элементы заимствуют структуру и поведение более общих элементов.. Начальная фаза — первая фаза цикла разработки программного обеспечения, в которой исходная идея становится достаточно обоснованной, чтобы можно было принять решение о переходе к фазе исследования. Область действия — контекст, в котором употребление некоего имени является осмысленным. Обобщение — отношение специализации/обобщения, в котором объекты специализированного элемента (потомка) могут быть подставлены вместо объектов обобщенного элемента (родителя, или предка). Образец (паттерн) — типичное решение типичной проблемы в данном контексте.
Обратное проектирование — процесс преобразования кода на конкретном языке программирования в модель. Объект — конкретная материализация абстракции; сущность с хорошо определенными границами, в которой инкапсулированы состояние и поведение; экземпляр класса.
Обязанность — контракт или обязательство, принимаемое на себя типом или классом. Ограничение — расширение семантики элемента UML, позволяющее добавлять новые или модифицировать существующие правила. Одиночное наследование — семантическая разновидность обобщения, когда потомок может иметь только одного родителя. Операция — реализация услуги, которая может быть запрошена у любого объекта класса. Особенность — свойство, например операция или атрибут, которое инкапсулировано внутри другой сущности, такой как интерфейс, класс или тип данных. Отношение — семантическая связь между элементами. Отправитель — объект, передающий экземпляр сообщения объекту-получателю.
Отправка — передача экземпляра сообщения от объекта-отправителя объекту-получателю. Пакет — универсальный механизм организации элементов в группы.
Параллельное подсостояние — подсостояние, в котором система может находиться одновременно с нахождением в других подсостояниях внутри одного и того же составного состояния. Параметр — спецификация переменной, которая может быть изменена, передана или возвращена. Переход — отношение между двумя состояниями, показывающее, что объект, находящийся в первом состоянии, должен выполнить некоторые действия и перейти во второе состояние, как только наступит некоторое событие и при этом будут выполнены определенные условия. Перечислимый тип — список поименованных величин, образующих область значений некоторого атрибута. Поведение — наблюдаемый эффект события, в том числе его результаты. Поведенческое свойство — динамическое свойство элемента, такое как операция или метод. Подкласс: в отношении обобщения — специализация другого класса, родителя. Подсистема — группирование элементов, часть из которых составляет спецификацию поведения, предлагаемого другими содержащимися в нем элементами. Помеченное значение — расширение свойств элемента UML, которое позволяет включать новую информацию в его спецификацию. Поставщик — тип, класс или компонент, предоставляющий услуги, которые могут быть востребованы другими элементами. Построение — третья фаза цикла разработки программного обеспечения, в ходе которой исполняемый архитектурный прототип доводится до состояния, когда он может быть передан пользователям.
Постусловие — ограничение, которое должно быть выполнено по завершении операции. Потомок — подкласс. Предметная область — область знаний или деятельности, характеризуемая концепциями и терминами, понятными тем, кто работает в данной области. Предусловие — ограничение, которое должно быть выполнено, когда вызывается операция. Прецедент — описание множества последовательных событий (включая варианты), выполняемых системой, которые приводят к наблюдаемому актером результату.
Примечание — графический символ для изображения ограничений или комментариев, присоединяемый к элементу или множеству элементов. Примитивный тип — базовый тип, например «целое» или «строка». Продукт — артефакт процесса разработки, такой как модель, код, документация и рабочий план. Проекция — отображение множества на его подмножество. Производный элемент — элемент модели, который можно вычислить по другим элементам, но который тем не менее включен в нее для ясности или для удоб-, ства проектирования, несмотря на то что он не привносит новой семантики. Пространство имен — область действия, в которой могут быть определены и использованы имена; внутри пространства имен каждое имя идентифицирует уникальный элемент. Процесс — ресурсоемкий поток управления, который может выполняться параллельно с другими процессами. Прямое проектирование — процесс преобразования модели в код путем отображения на конкретный язык программирования. Реализация (Implementation) — конкретное воплощение контракта, объявленного интерфейсом; определение того, как что-либо конструируется или вычисляется. Реализация (Realization) — семантическое отношение между классификаторами, в котором одна сторона формулирует условия контракта, а другая обязуется его выполнить.
Родитель — суперкласс, или «надкласс». Роль — поведение сущности, участвующей в конкретном контексте.
Свертывание -моделирование элемента, некоторые части которого скрыты для упрощения восприятия. Свойство — поименованное значение, обозначающее некоторую характеристику элемента. Связывание — создание элемента по шаблону путем подстановки фактических аргументов вместо формальных параметров шаблона. Связь — семантическое соединение между объектами; экземпляр ассоциации. Сигнал — спецификация асинхронного стимула, передаваемого от одного экземпляра другому. Сигнатура — совокупность имени и параметров операции. Синхронное действие — запрос, послав который, объект-отправитель ожидает результат. Система — множество элементов, организованных для достижения конкретной цели, иногда разложенное на несколько подсистем и описываемое набором моделей, возможно с различных точек зрения. Событие — спецификация существенного факта, имеющего положение в пространстве и во времени. В контексте автоматов событие — это возникновение стимула, который может активизировать переход из одного состояния в другое. Сообщение — спецификация передачи информации между объектами в расчете на то, что за этим последует некоторая деятельность; прием сообщения обычно трактуется как возникновение события. Состояние — ситуация в жизненном цикле объекта, во время которой он удовлетворяет некоторому условию, выполняет определенную деятельность или ожидает какого-то события. Спецификация — текстовое объявление синтаксиса и семантики некоторого строительного блока; декларативное описание того, чем является или что делает некая сущность. Статическая классификация — семантическая разновидность обобщения, в которой объект не может изменять свой тип или роль. Статический вид — аспект системы, в котором основное внимание уделяется ее структуре.
Стереотип — расширение словаря UML, позволяющее создавать новые виды строительных блоков, производные от существующих, но специфичные для конкретной задачи. Сторожевое условие — условие, которое должно быть выполнено для того, чтобы сработал переход, с которым оно ассоциировано. Суперкласс: в отношении обобщения — обобщение другого класса, потомка. Тип — стереотип класса, используемый для специфицирования семейства объектов, а также операций (но не методов), применимых к этим объектам.
Тип данных — тип, значения которого никак не идентифицированы. К типам данных относятся примитивные встроенные типы (например, числа и строки), а также перечиблимые типы (например, булевский).
Требование — желаемая функциональность, свойство или поведение системы. Узел — физический элемент, существующий во время выполнения системы и представляющий вычислительный ресурс, который обладает по меньшей мере памятью, а зачастую также и процессором.
Уточнение — отношение, которое представляет более полную спецификацию того, что ранее уже было специфицировано на определенном уровне детализации. Фаза — промежуток времени между двумя опорными точками в процессе разработки, в течение которого должны быть достигнуты заранее поставленные хорошо определенные цели, артефакты доведены до готовности и принято решение о том, следует ли переходить к следующей фазе. Фактический параметр — аргумент функции или процедуры.
Формальный параметр — см. Параметр. Целостность — правильность и согласованность взаимодействия различных сущностей.
Экземпляр — конкретная материализация абстракции. К этой сущности могут быть применены операции; она обладает состоянием, в котором запоминаются результаты операций. Элемент — атомарная составляющая модели.
?? ?? ?? ?? 2