<< Пред. стр. 3 (из 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
<< Пред. стр. 3 (из 3) След. >>
Список литературы по разделу