И в ч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

Прокрутить вверх