На втором этапе нужно сделать совершенно противоположное общему описанию системы – перечислить все возможные элементы этой системы. Например, если мы хотим получить описание системы с точки зрения ее возможностей мы перечислим всех возможных пользователей – сотрудник кафедры вводящий данные, заведующий кафедры, сотрудник деканата, декан, студенты, преподаватели, заведующие лабораториями, уборщицы аудиторий, сотрудники учебно-методического отдела и т.д.
На третьем этапе нужно на основании двух «крайних»» форм «синтезировать» описания системы в требуемом виде, сгруппировав элементы системы. Например, среди перечисленных пользователей системы составления расписания можно выделить пользователей, которые имеют сходные функции – вводят данные. Это сотрудники деканата, кафедр, заведующий лабораториями. Представим их одним элементом системы и этот элемент «оператор». Также можно выделить «читателей» – студенты, преподаватели, уборщицы, и «диспетчеры» – составители расписания, деканы и т.д.
В общем случае, такое трехшаговое разбиение системы для одной диаграммы нужно повторить несколько раз. Например, для каждого из полученных пользователей системы составления расписания («оператора», «читателя» и «диспетчер») нужно определить их возможные действия.
Построение динамических диаграмм, которые описывают последовательностей действий, взаимодействия конкретных объектов, имеет свои особенности. Поскольку в этом случае структура системы с той или иной точностью уже определена, не нужно придумывать элементы, участвующие в действии, а выбрать нужные объекты из имеющихся. Для выбранных объектов нужно определить связи между ними, сообщения или другие способы взаимодействия. Т.е. построение динамических диаграмм фактически служит для уточнения деталей уже спроектированной системы.
Приводимый ниже курс лабораторных работ предполагает тренировку навыков построения диаграмм (с параллельным изучением конкретных типов диаграмм и нотации языка UML).
На ранних этапах развития объектно-ориентированного проектирования было несколько методологий, каждая из которых использовала свои термины, обозначения и подходы. Важным шагом стало создание единой нотации, позволяющей понимать модели систем составленными различными специалистами. Такой нотацией стал язык UML.
Язык UML содержит относительно небольшое число сущностей, которые разделяются на структурные, группирующие, поведенческие и аннотационные. Между сущностями может быть всего 4 типа отношений: зависимость, ассоциация, обобщение и расширение. В нашем курсе изучение сущностей и отношений будет проходить по мере необходимости их применения на диаграммах. Примеры сущностей и отношений приведены на рис. 1.
Рис. 1. Примеры сущностей и отношений
Сущности и отношения в UML имеют весьма абстрактный характер. Для того, чтобы обозначения на диаграммах имели более конкретное значение, имеются механизмы расширения – дополнения и стереотипы.
Дополнения добавляют к стандартному обозначению текстовую или графическую информацию, позволяющую указывать некоторые дополнительные свойства. Например, для отношения «ассоциация» существует добавление, позволяющая указывать кратность отношения (аналогично тому, как это делается на диаграммах «сущность-связь»).
Стереотипы позволяют конкретизировать смысл элемента UML. Например, для отношения «зависимость» существует стереотип «расширение», который показывает, что происходит расширение функций зависимого элемента.
Дополнения изображаются с помощью добавления к основному элементы специального символа или текста. Для указания стереотипа его имя в кавычках дописывается перед названием элемента UML. Примеры дополнений и стереотипов приведены на рис. 2.
Рис. 2. Примеры дополнений и стереотипов
В UML смысловое значение несет также тип диаграммы, на которой располагаются элементы. В первой версии языка существуют следующие виды диаграмм:
1) диаграммы классов;
2) диаграммы объектов;
3) диаграммы прецедентов;
4) диаграммы последовательностей;
5) диаграммы кооперации;
6) диаграммы состояний;
7) диаграммы действий;
8) диаграммы компонентов;
9) диаграммы развертывания.
Каждая из диаграмм предназначена для моделирования определенного аспекта работы системы. Язык UML предоставляет возможность рассмотреть системы с различных точек зрения. При этом важно понимать, что весь набор диаграмм описывает одно и туже системы, хотя и используются различные элементы.
Наиболее полно архитектура информационной системы, с точки зрения языка UML, может быть описаны с помощью 5 взаимосвязанных точек зрения, приведенных на рис. 3.
Рис. 3. Архитектура информационной системы, с точки зрения языка UML
Вид с точки зрения прецедентов описывает поведение системы и реализуется на диаграммах прецедентов.
Вид с точки зрения проектирования охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и ее решения. Для отображения этой точки зрения используются диаграммы классов и объектов.
Вид с точки зрения процессов отличается от точки зрения проектирования только тем, что особое внимание при этом уделяется активным классам, которые представляют соответствующие нити и процессы, с целью определения производительности и масштабируемости.
Вид с точки зрения реализации охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта, и реализуется с помощью диаграмм компонентов.
Вид с точки зрения развертывания описывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется, и реализуется с помощью диаграмм развертывания.
Динамические аспекты всех точек зрения описываются диаграммами взаимодействия, состояний и действий.
В курсе лабораторных работ по порядку рассматриваются несколько диаграмм UML.
Для каждого типа диаграмм в теоретической части указываются сущности, отношения и стереотипы, которые могут на ней применяться. Указывается, в каком порядке нужно определять элементы диаграммы, даются подсказки, на какие аспекты нужно обращать внимание при проектировании.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.