АрхитектураИС_Семестр3_МетодПособие8-9

51

Мощность и гибкостьDelphi при работе с базами данных, возможность связи с Rational Rose и отсутствие специальных требований к ресурсам компьютера, позволяют эффективно использовать Delphi для разработки приложения справочно-информационной системы музыки на CD.Приложение состоит из одной формы, на которой находятся следующие основные компоненты: DBGrid, DBEdit, DBNavigator, Table, DataSource и Query.

Рис. 3.6. Внешний вид диалогового окна

Слева на форме отображаются характеристики исполнителя, такие как, «Исполнитель», «Дата рождения», «Страна проживания», «Награды», «Фото».

Справа на форме отображаются сведения об альбоме, такие как, «Исполнитель», «Название альбома», «Стиль», «Год выпуска», «Описание».

Поиск осуществляется с помощью компонентаQuery, в котором формируется SQL-запрос на выборку. Полученный результат отправ-

52

ляется в компонент DataSource и после этого отображается в компоненте DBGrid.

Ниже представлен вариант поиска исполнителя по названию.

Рис. 3.7. Поиск по критериям

Итак, проанализировав предметную область и поставленную задачу, с помощью программы Rational Rose была разработана концептуальная модель информационно– справочной системы музыки на CD. Затем эта модель была реализована вBorland Delphi 7. В результате получилась удобная и наглядная система, помощью которой пользователь всегда будет знать о том, какие альбомы и каких исполнителей имеются в его фонотеке, добавлять данные при приобретении нового диска или удалять при утере.

В [7] приводится пример подробной разработки модели медицинского учреждения средствами UML.

Выводы

Проектирование информационной системы начинается с определения основных задач, решаемых системой. На этом этапе с успехом можно использовать диаграммы прецедентов UML, при этом необходимо выделить внешние по отношение к системе элементы– актеры,

53

ввести прецеденты, описывающие внешнее поведение системы и определить связи между ними.

Cструктура программной системы задается структурой классов. Диаграммы классов UML предоставляют мощные средства специфицирования классов. Грамотное использование наследования и полиморфизма, применение интерфейсов составляют основу построения эффективной модели статического вида с точки зрения разработки. Для описания поведенческих (динамических) аспектов данного вида модели системы используются взаимодействия.

Большинство современных информационных систем в своем информационном ядре имеют базу данных. UML имеет возможности моделирования реляционного профиля базы данных, разработка которого базируется на объектно-ориентированной модели, построенной на предыдущих этапах. Разработанная структура базы данных должна удовлетворять условиям нормализации и не содержать аномалий.

Развитые CASE-средства, построенные на основеUML (прежде всего Rational Rose) поддерживают связь с средствами программирования, что позволяет осуществлять переход от модели к исходному коду программы (прямое проектирование) и обратно (обратное проектирование), что создает основу для эффективной поддержки - про граммных приложений и их модернизации.

Контрольные вопросы

1.Объясните понятия «прецедент» и «актер».

2.На каком этапе проектирования используется диаграмма прецедентов, какие элементы она содержит?

3.Какие средства UML имеются для моделирования статического вида системы с точки зрения проектирования.

4.Какова роль интерфейсов при моделировании вида системы с точки зрения проектирования.

5.Что показывают диаграммы взаимодействия? Какие виды диаграмм взаимодействия вы знаете?

6.Как от объектно-ориентированной модели перейти к модели профиля базы данных?

7.Дайте определения первых трех нормальных форм реляционных баз данных, приведите примеры.

8.Какие инструментальные средства имеет Rational Rose для связи с средствами программирования?

9.Охарактеризуйте основные этапы процесса моделирования информационной системы средствамиUML. Какие диаграммы применяются на каждом этапе?

54

Упражнения

Построить модель информационной системы ВУЗа. 1) На диаграмме классов. Создать классы:

Вуз; Факультет; Кафедра;

Курс (в смысле дисциплина) ;

Группа; Преподаватель;

Студент.

Ввести атрибуты name (имя) для всех классов; IDz (номер зачетки) – для студента;

Address (дом. адрес) для преподавателя , студента, вуза. Должность, ученая степень, ученое звание, стаж работы для пре-

подавателя.

Ввести дополнительные атрибуты на Ваше усмотрение, задать типы атрибутов.

Подумайте, как с помощью обобщения можно упростить описание объектов студент и преподаватель (например, можно выделить суперкласс Person (Пер-

сона) с атрибутами Ф.И.О., дом. адрес, дом. телефон.)

Ввести операции для объекта Вуз: определяющие поступление, окончание, отчисление студента;

прием на работу и увольнение преподавателя; Группа, Факультет: перевод студента из и в группу/факультет.

Ввести еще операции на Ваше усмотрение, задать типы параметров и возвращаемых значений.

Изобразить отношения, при этом использовать Отношения агрегации: обучается_в , состоит_из;

Ассоциации: читает (курс), посещают (курс), работает_на, является_деканом, зав_кафедрой.

Укажите типы множественности на концах ассоциаций.

Можете привести еще несколько ассоциаций и/или зависимостей.

Будем предполагать, что электронная система учёта содержит электронные копии зачетных книжек, ведомостей, журналов групп и некоторую базу данных.

Введите объекты студ_билет, зач_книжка, ведомость, журнал_группы, сде-

лайте их атрибутами соответствующих объектов или связей.

Для объекта студ_билет можно ввести атрибут номер и написать требования в текстовой форме.

Для объекта зач_книжка введите следующие атрибуты:

Номер_зачетки; Листы.

Листы, в свою очередь, имеют атрибуты: курс, тип_листа (практический курс, теореоретический курс, практика и т.д.) ; записи массив типазапись[]

55

(каждая запись соответствует записи в зачетной книжке, укажите атрибуты для типа запись).

При описании типов перечислений (курс, тип_листа и т.д. ) для атрибутов воспользуйтесь сигнатурой класса со стереотипом «enumeration».

Аналогично записям зачетной книжки введите записи ведомости. На общей диаграмме классов учетную базу данных можно не отображать.

2) Постройте диаграмму прецедентов. Актеры: студент, преподаватель, система учета.

Прецеденты:

связанные со студентом: поступление, окончание, отчисление; связанные с преподавателем: поступление на работу, увольнение.

Предполагается, что все действия фиксируются системой учета.

Для прецедента поступление можно выделить составляющую часть прецедент регистрация, который предполагает действия: зачисление в группу, выдача зачетной книжки, билета, пополнение базы данных соответствующей информацией. Раскройте прецедент регистрация соответствующей дочерней диаграммой прецедентов с использованием стереотипных зависимостей «include».

Раскройте прецедент, о пополнение базы данных соответствующей информацией диаграммой последовательностей. При этом будем предполагать, что пополнение базы данных происходит в интерактивном режиме с помощью прикладной интерфейсной программы, ввод осуществляется посредством форм ввода.

Диаграмма последовательностей должна содержать объекты:

Форма _студенты, содержит списки студентов и основные атрибуты студентов.

Форма _подробная информация, содержит подробную информацию о студентах.

Далее можно выделить как объекты диаграммы последовательности: менеджер записей о студентах (как элемент программы учета), собственно запись о студенте, и менеджер транзакций.

Пользуясь аналогиями лабораторной работы по взаимодействиям (№ 2) определите сообщения.

Преобразуйте данную диаграмму последовательностей вдиаграмму коопераций, придайте ей наглядный вид.

56

ЗАКЛЮЧЕНИЕ

Язык графических нотаций UML разработан для описания, документирования и формализации процесса разработки объектноориентированных программных систем. Основным выразительным средством языка являются диаграммы, раскрывающие модель системы с определенной точки зрения в определенном контексте.

Можно выделить основные этапы разработки системы с использованием средств UML:

1)описание задания в общих чертах на естественном языке;

2)выделение прецедентов и актеров бедующей системы;

3)определение объектов и взаимодействий между ними;

4)детализация функциональности с помощью диаграмм последовательности (переходов) для каждого прецедента;

5)группировка объектов, переход от объектов и сущностей к компонентам;

6)ревизия результатов предыдущих этапов;

7)детальная проработка реализации компонентов, разделение компонентов по участникам коллектива разработчиков;

8)Построение профиля баз данных с учетом способа хранения данных в выбранной СУБД;

9)размещение компонентов системы;

10)кодирование.

Каждый этап поддерживается соответствующимиUMLдиаграммами.

При этом следует иметь ввиду, что процесс разработки программной системы является интерактивным, предполагает периодические возвращения на предыдущие этапы и повторный пересмотр некоторых элементов модели. Использование средств обратного проектирования позволяет заметно повысить эффективность и сократить время разработки.

Язык UML является открытым языком. Механизмы расширения позволяют построить развернутую модель с учетом специфических особенностей конкретной предметной области, оттенить некоторые нюансы структуры и поведения вводимых элементов. Язык постоянно развивается, новые версии языка содержат расширенный набор стереотипов для моделирования бизнес-отношений, хранилищ данных, WEB-приложений. На базе новых стереотипных классов строятся новые диаграммы, например диаграмма бизнес-прецедентов (используется на начальном этапе проектирования при проведении так назы-

57

ваемого бизнес-моделирования), содержащая не так давно введенные бизнес-актеры и бизнес-прецеденты.

Интерес профессионалов к языку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 )

58

Словарь терминов и определений

UML (Unified Modeling Language) - Унифицированный язык моделирования, предназначенный для визуализации, специфицирования, конструирования и документирования артефактов программных систем.

Абстрактный класс - класс, для которого нельзя непосредственно создать экземпляры объектов.

Абстракция - важная характеристика сущности, отличающая ее от всех иных сущностей. Абстракция проводит границу между сущностями лишь с ка- кой-то определенной точки зрения.

Автомат - поведение, которое специфицирует последовательность -со стояний, через которые проходит объект на протяжении своего жизненного цикла, реагируя на события, включая описание реакций на эти события.

Агрегат - класс, представляющий «целое» в отношении агрегирования. Агрегирование - специальный вид ассоциации, описывающий отношение

между агрегатом (целым) и компонентом (частью).

Актер - множество логически связанных ролей, исполняемых при взаимодействии с прецедентами.

Активный класс - класс, экземплярами которого являются активные объекты.

Активный объект - объект, который владеет процессом или нитью и может инициировать управляющее воздействие.

Аргумент - фактическое значение, соответствующее формальному параметру.

Артефакт - элемент информации, используемый или порождаемый в процессе разработки программного обеспечения.

Архитектура - совокупность существенных решений об организации программной системы; набор структурных элементов и интерфейсов, из которых она состоит, вкупе с поведением, описываемым в терминах коопераций этих элементов; составление из данных структурных и поведенческих элементов все более крупных систем; архитектурный стиль, которому подчинена организация элементов, интерфейсов, коопераций и их композиции.

Ассоциация - структурное отношение, описывающее набор связей, в котором каждая из них представляет собой соединение между объектами; семантическое отношение между двумя или более классификаторами, в котором участвуют соединения между их экземплярами.

Версия - относительно полный и самосогласованный набор артефактов, предназначенный для внутреннего или внешнего использования.

Взаимодействие - поведение, описываемое набором сообщений, которыми об-' мениваются между собой объекты в некотором контексте для достижения определенной цели.

Вид (представление) - проекция модели, рассматриваемой с определенной точки зрения, в которой высвечены детали, важные в данном аспекте, и опущены несущественные.

Вид (представление) системы с точки зрения прецедентов- вид систем-

59

ной архитектуры, охватывающий прецеденты, с помощью которых описывается поведение системы с точки зрения конечных пользователей, аналитиков и

тех, кто тестирует программы.

Вид (представление) с точки зрения проектирования- вид системной ар-

хитектуры, охватывающий классы, интерфейсы и кооперации, которые образуют словарь задачи и ее решения. Этот вид обращен к функциональным требованиям, предъявляемым к системе.

Вид (представление) с точки зрения процессов - вид системной архитектуры, охватывающий процессы и нити, которые формируют механизмы параллельности и синхронизации. Этот вид фокусирует внимание на производительности, масштабируемости и пропускной способности системы.

Вид (представление) с точки зрения развертывания - вид системной архитектуры, охватывающий узлы, образующие топологию аппаратных средств, на которых система исполняется. Этот вид отражает распределенность, поставку и установку частей, из которых составлена система.

Вид (представление) с точки зрения реализации - вид системной архитектуры, охватывающий компоненты, используемые при сборке и выпуске физической системы. Этот вид важен для управления конфигурированием версий системы, составленной из независимых(до определенной степени) компонентов, которые могут быть по-разному собраны для получения работающего комплекса.

Видимость - указывает, при каких обстоятельствах то или иное имя видимо и может быть использовано.

Внедрение - четвертая фаза цикла разработки программного обеспечения, в течение которой оно передается пользователям.

Выражение - строка, которая может быть использована для получения значения определенного типа.

Делегирование - способность объекта посылать сообщение другому объекту в ответ на получение сообщения.

Деятельность - протяженное во времени неатомарное вычисление внутри автомата.

Диаграмма - графическое представление множества элементов. Обычно изображается в виде графа с вершинами(сущностями) и ребрами (отношениями).

Диаграмма взаимодействия - диаграмма, на которой представлено взаимодействие, состоящее из множества объектов и отношений между ними, включая и сообщения, которыми они обмениваются. Диаграммы взаимодействия относятся к динамическому виду системы. Этот обобщенный термин применяется к нескольким видам диаграмм, в которых делается акцент на взаимодействии объектов, в том числе к диаграммам кооперации, последовательности и деятельности.

Диаграмма деятельности - диаграмма, на которой представлены переходы потока управления от одной деятельности к другой. Диаграммы деятельности относятся к динамическому аспекту поведения системы. Это разновидность диаграмм состояний, где все или большая часть состояний являются состояниями деятельности, а все или большая часть переходов срабатывают при завершении

60

деятельности в исходном состоянии.

Диаграмма классов - диаграмма, на которой представлено множество классов, интерфейсов, коопераций и отношений между ними; диаграммы классов относятся к статическому виду системы. Иными словами, это диаграмма, на которой показано множество декларативных (статических) элементов.

Диаграмма компонентов - диаграмма, на которой изображена организация некоторого множества компонентов и зависимости между ними; относится к статическому виду системы.

Диаграмма кооперации - диаграмма взаимодействий, в которой основной акцент сделан на структурной организации объектов, посылающих и получающих сообщения. На этой диаграмме изображено, как организованы взаимодействия между экземплярами и какие между ними существуют связи.

Диаграмма объектов - диаграмма, на которой представлено множество объектов и отношений между ними в некоторый момент времени. Диаграммы объектов относятся к статическому виду системы с точки зрения проектирования или процессов.

Диаграмма последовательностей - диаграмма взаимодействия, в которой основной акцент сделан на временном упорядочении сообщений.

Диаграмма прецедентов - диаграмма, на которой представлено множество прецедентов и актеров, а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы.

Диаграмма развертывания - диаграмма, на которой представлена конфигурация обрабатывающих узлов и размещенные на них компоненты; относится к статическому виду системы.

Диаграмма состояний - диаграмма, на которой изображен автомат; диаграммы состояний относятся к динамическому виду системы.

Динамическая классификация - семантическая разновидность обобщения, при которой объект может изменять тип или роль.

Динамический вид - аспект системы, в котором основное внимание уделено ее поведению.

Дополнение - деталь элемента спецификации, добавляемая к его базовому графическому символу.

Дорожка - разбиение диаграммы взаимодействия для распределения ответственности за действия.

Зависимость - семантическое отношение между двумя сущностями, при которой изменение одной (независимой) сущности может повлиять на семантику другой (зависимой).

Задача - путь выполнения программы, динамической модели или иного представления потока управления; процесс или нить.

Запрос - спецификация стимула, посылаемого объекту. Значение - элемент области определения типа.и.

Имя - название сущности, отношения или диаграммы; строка, идентифицирующая элемент.

Инкрементный подход: в контексте цикла разработки программного обеспечения - процесс непрерывного развития архитектуры системы, когда каждая новая версия содержит улучшения по сравнению с предыдущей.