И В ЧEРВEНЧУК ИНФОРМАЦИОННЫE СИСТEМЫ И ПРОЦEССЫ МОДEЛИРОВАНИE И УПРАВЛEНИE 3

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

Do NOT follow this link or you will be banned from the site! Пролистать наверх