Справа на форме отображаются сведения об альбоме, такие как, “Исполнитель”, “Название альбома”, “Стиль”, “Год выпуска”, “Описание”.
Поиск осуществляется с помощью компонента 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