Контрольная работа
Тема: Визуальное моделирование программной системы в StarUML
Введение
UML - это язык визуального моделирования программных систем. Моделирование систем с помощью UML предполагает построение ряда взаимосвязанных диаграмм. Для сопровождения процесса построения, анализа и документирования модели, а также проверки модели и генерации программных кодов разработчики используют специально для этих целей созданные CASE-инструменты проектирования систем.
В общем смысле CASE (Computer-Aided Software Engineering) — это набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов.
Существует достаточно много CASE-инструментов моделирования и проектирования систем и баз данных (не только с помощью UML). В нашем случае выбран программный инструмент моделирования StarUML.
Данная программная платформа имеет свободную лицензию и доступна для установки с официального сайта StarUML:
http://sourceforge.net/projects/staruml/files/staruml/5.0/staruml-5.0-with-cm.exe/download?use_mirror=netcologne&download=&failedmirror=dfn.dl.sourceforge.net
StarUML поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0, а также подход MDA (Model Driven Architecture), предлагает настройку параметров пользователя для адаптации среды разработки, поддерживает расширения, предоставляет различного рода модули, расширяющие возможности StarUML.
Постановка задачи. Определение подхода к моделированию
Рассмотрим визуальное моделирование систем с использованием UML на примере проектирования системы заказов интернет-магазина «Style».
Магазин занимается продажей детской и взрослой одежды и обуви различных брендов. Покупатель просматривает каталог и делает заказ. Предполагаем, что потенциальный клиент заходит на сайт магазина, он может нажать кнопку просмотра (или загрузки) каталога, далее может положить понравившийся товар в корзину, изменить корзину и, приняв решение о покупке товаров, перейти из корзины к оформлению заказа.
Для того чтобы корректно создать систему, отвечающую всем требованиям заказчика, мы должны абсолютно четко представить себе ее основные бизнес-функции и выяснить предъявляемые к системе требования. Для этого необходимо провести обследование компании и построить ее полную бизнес-модель. Поскольку наш пример является придуманным, мы не можем провести такое обследование и не имеем возможности общаться с заказчиком, то мы будем опираться на придуманное нами словесное описание системы.
Создание проекта
Создадим новый проект в StarUML, выбрав Rational Approach из списка предложенных подходов. Наша модель будет иметь четыре представления: Use Case, Logical, Component и Deployment. Данный подход по структуре представлений соответствует методологии Rational Unified Procces (RUP), которая поддерживает итеративный процесс разработки информационных систем.
Сохраните созданный вами проект под любым именем.
3 Диаграммы вариантов использования
Поведение системы (т.е. функциональность, которую она обеспечивает) описывают с помощью функциональной модели, которая отображает системные прецеденты (use cases, случаи использования), системное окружение (действующих лиц, актеров, actors) и связи между ними (use cases diagrams).
Диаграмма вариантов использования (диаграмма прецедентов, use case diagram) - это диаграмма, на которой изображаются отношения между актерами и вариантами использования.
С помощью этой диаграммы можно:
- Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;
- Сформулировать общие требования к функциональному поведению проектируемой системы;
- Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;
- Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Диаграмма вариантов использования (прецедентов) представляет собой граф, в вершинах которого расположены актеры или прецеденты, связи между вершинами – это разного вида отношения.
Актером (действующее лицо, actor) называется любой объект, субъект или система, взаимодействующая с моделируемой системой извне.
Это может быть человек, техническое устройство, программа или любая другая система, которая служит источником воздействия на моделируемую систему так, как определит разработчик. На диаграммах вариантов использования актер изображается в виде человечка, под которым записывается его имя (рис. 8).
Рис. 8 - Актер
Вариант использования (прецедент, use case) — описание множества последовательности действий (включая варианты), выполняемых системой для того, чтобы актер мог получить определенный результат.
Каждый вариант использования должен быть независимым в том смысле, что если он всегда выполняется совместно с другим вариантом использования, то, скорее всего, это один прецедент, а не два, либо они связаны отношением включения или расширения, о чем речь пойдет позже. Как следует из определения, прецедент (или вариант использования) должен обладать результирующей ценностью для актера, актер должен получить некоторый результат исполнения прецедента. Скорее всего, после исполнения прецедента в системе произойдут некоторые изменения: появятся новые данные, изменится поведение. Каждый вариант использования должен исполняться от начала до конца.
Прецедент описывает, что делает система, но никак не уточняет, как она это делает. Заметим, что диаграмма прецедентов не отображает последовательность, в которой будут выполняться варианты использования. На диаграмме прецедент изображается в виде эллипса. Имя прецедента может состоять из нескольких слов и знаков препинания (за исключением двоеточия), как правило, имя выбирают в виде словосочетания или глагольного выражения (рис. 9).
Рис. 9 - Варианты использования (прецеденты)
Одним из наиболее важных (и дорогостоящих) этапов проектирования информационных систем является этап определения требований к системе. Если требования заказчика информационной системы разработчиками будут определены не корректно, то в итоге заказчик может получить совсем не ту систему, которую он ожидал.
Моделирование прецедентов и актеров помогает нам лучше понять требования, предъявляемые к системе, и согласовать их с заказчиком с помощью демонстрации и обсуждения диаграммы прецедентов. Прецеденты и актеры – это отражение требований к системе, они показывают, кто и для чего будет использовать будущую систему.
Пример. Определим актеров и прецеденты системы заказов магазина «Style».
Напомним, что покупатель делает заказ, складывая товары в корзину. Возможна только одна форма оплаты: банковской картой по интернету, невозможно оформление заказа без оплаты. Заказ имеет статус: оплачен, передан на комплектацию, собран, получен. Статус заказа изменяется автоматически либо сотрудником магазина. Покупатель может узнать статус своего заказа по уникальному номеру заказа.
Система не занимается поставками товаров в магазин. Этим занимается другая система, назовем ее Cклад.
Таким образом, с нашей системой взаимодействуют покупатель, сотрудники магазина и внешняя система Склад. С нашей системой взаимодействуют сотрудник отдела продаж, который проверяет оплату заказа и отправляет его на комплектацию, и кладовщик, который собирает заказ и выдает его покупателю. С точки зрения бизнеса – это две разных должности, выполняющих разные функции, но с точки зрения системы они играют одну роль сотрудника, изменяющего статус заказа покупателя с использованием программного обеспечения моделируемой системы. В этом смысле для системы нет разницы между сотрудником отдела продаж и кладовщиком. Выбирая действующих лиц, нужно помнить о том, что мы должны отразить их роль, а не должность. Введем обобщающее сотрудников действующее лицо – Сотрудник. Другой пример: сотрудник магазина «Style» (положим, кладовщик) может выступать в роли сотрудника и общаться с системой как сотрудник магазина, а может выступать и в роли покупателя, сделав заказ в магазине. Не смотря на то, что физически это один человек, он выступает в роли двух актеров: покупателя и сотрудника. Итак, актеры системы заказов магазина «Style» будут следующие:
Покупатель, Сотрудник, Система Склад.
Покупатель использует нашу систему для того, чтобы заказать вещи, он просматривает каталог, добавляет понравившиеся ему товары в корзину, открывает корзину, удаляет из нее товары или изменяет их количество и, наконец, может оформить свой заказ, при этом его оплатив. В конечном итоге результат использования системы покупателем будет получен, если он выполнил все эти действия от начала до конца. Поэтому не будем разделять заказ товаров на несколько прецедентов, а выделим только один: Заказ товаров.
Покупатель, сделав заказ в магазине «Style», может в дальнейшем узнавать статус своего заказа, это тоже случай использования системы, назовем его Получение информации о заказе.
Сотрудник должен изменять статус сделанного заказа, для него определим прецедент Управление статусом заказа.
Система Склад должна получать информацию о сделанных заказах для возможности управления наличием товаров на складе, для нее также должен быть доступен прецедент Получение информации о заказе.
Итак, прецеденты системы заказов магазина «Style»: Заказ товаров, Управление статусом заказа, Получение информации о заказе.
Потоки событий
Одним из требований языка UML является самодостаточность диаграмм для представления информации о моделях проектируемых систем. Однако, как уже отмечалось выше, диаграммы вариантов использования описывают то, что делает система, без уточнения того, как она это делает.
Для реального описания системы потребуются более специфические данные, которые отражены в потоке событий. Потоки событий уточняют или детализируют последовательность действий, совершаемых системой при выполнении ее вариантов использования, а также описывают логику переходов через варианты использования.
Поток событий – это определенная последовательность действий, которая описывает действия актеров и поведение моделируемой системы в форме обычного текста.
Потоки событий – это текстовые описания пошагового выполнения прецедентов, они понятны не только разработчику, но и стороннему читателю. Их задача – еще больше детализировать описание функциональности системы до того, как разработчики приступят к написанию программного кода, и устранить возможное недопонимание требуемой функциональности, как можно больше сблизить представления разработчика о системе и заказчика.
Потоки событий бывают трех типов: основной, альтернативный и поток ошибок.
Основной (главный) поток описывает наилучший сценарий либо наиболее используемый путь исполнения прецедента.
Альтернативный поток специфицирует отклонения от основного потока, которые не рассматриваются как ошибочные.
Поток ошибок рассматривается как отклонение от альтернативного или основного, которое порождает условия формирования ошибки.
Пример. Опишем потоки событий прецедента Заказ товаров.
Основной поток событий:
1. Прецедент начинается с выбора покупателем режима показа каталога.
2. Система открывает каталог.
3. Покупатель выбирает режим показа корзины.
А1. Покупатель просматривает каталог и запускает поток «добавление товара в корзину»
4. Система открывает корзину.
5. Покупатель нажимает кнопку «оформить заказ».
А2. Покупатель просматривает корзину и запускает поток «изменение корзины».
А3. Покупатель решает вернуться в каталог.
6. Система переходит к первому шагу оформления заказа: запрашивает у покупателя личные данные и телефон.
7. Покупатель вводит личные данные и телефон.
8. Система переходит ко второму шагу оформления заказа: показывает содержимое заказа и просит подтвердить заказ.
9. Покупатель подтверждает заказ.
А4. Покупатель возвращается в корзину.
10. Система переходит к третьему шагу оформления заказа: запрашивает тип кредитной карты, ее номер, секретный код, имя владельца и дату завершения срока действия.
11. Покупатель вводит тип кредитной карты, ее номер, секретный код, имя владельца и дату завершения срока действия.
12. Система переходит к четвертому шагу оформления заказа: подтверждает оплату.
А5. Счет пользователя не найден.
А6. Недостаточно денег на счете.
Е1. Платежная система недоступна.
13. Система присваивает заказу номер и отправляет его вместе с подтверждением заказа на электронный адрес покупателя.
14. Вариант использования завершается.
Альтернативные потоки:
А2. Изменение корзины
1. Покупатель нажимает кнопку «Удалить» напротив одного выбранного товара.
А9. Покупатель изменяет количество позиций одного выбранного товара.
2. Система удаляет товар из корзины.
3. Поток возвращается к этапу 4 основного потока.
Потоки ошибок.
Диаграммы деятельности
Диаграммы деятельности обеспечивают еще один способ моделирования потока событий. С помощью текстового описания можно рассказать о потоке, но трудно будет понять логику событий в сложных и запутанных потоках с множеством альтернативных ветвей.
Диаграммы деятельности создаются также на разных этапах жизненного цикла системы для отражения последовательности выполнения операций.
Диаграммы классов
Диаграмма классов является частью логической модели системы и представляет статическую картину системы.
Для каждой системы строится не одна, а несколько диаграмм классов: возможно, что для каждого прецедента или сценария своя. На одних показывают подмножества классов, объединенные в пакеты, и отношения между ними, на других – отображают те же подмножества, но с атрибутами и операциями классов. Для представления системы разрабатывается столько диаграмм классов, сколько потребуется.
Выявление классов
Выявление классов можно начать с изучения потока событий. Имена существительные в описании этого потока дадут понять, что может являться классом. В общем случае существительное может оказаться действующим лицом, классом, атрибутом класса или выражением, не являющимся ни действующим лицом, ни классом, ни атрибутом класса.
Некоторые возможные классы будут выявлены при рассмотрении трех стереотипов: сущность (entity), граница (boundary) и управление (control). Мы уже встречались со стереотипами отношений, когда говорили об отношениях на диаграммах прецедентов. Тот же принцип создания нового типа на основе уже существующего применим и для классов.
Стереотип – это механизм, позволяющий категоризировать классы. Он используется для создания нового типа элемента, в данном случае нового типа класса.
Например, Вы хотите выделить все экранные формы в модели. Для этого нужно создать стереотип Form (Форма).
Стереотипы помогают лучше понять ответственности каждого класса в модели, категоризировать выполняемые ими функции. В UML для этого применяют три основных стандартных вида стереотипов классов: классы-сущности, граничные классы и управляющие классы. Подобное выделение стереотипов основано на модели MVC (Model-View-Controller - Модель-Представление-Контроллер)
Класс-сущность содержит информацию, хранимую постоянно. Используется для моделирования данных и поведения с длинным жизненным циклом. Они могут представлять информацию о предметной области, а могут представлять элементы самой системы. Часто являясь абстракциями предметной области, они имеют наибольшее значение для пользователя, поэтому в их названиях применяются термины предметной области. Если существует проект базы данных, то можно обратиться к изучению названий таблиц, многие из них станут классами-сущностями. Обозначаются классы-сущности стереотипом <<entity>> либо специальной пиктограммой (рис. 35).
Рис. 35 - Обозначение классов-сущностей
Граничными классами называются классы, расположенные на границе системы со всем остальным миром, и т.о. они обеспечивают взаимодействие между окружающей средой и внутренними элементами системы.
Для вычисления пограничных классов необходимо исследовать диаграммы вариантов использования. Для каждого взаимодействия между актером и прецедентом нужно создать хотя бы один граничный класс. Обратите внимание, что если два действующих лица инициируют один прецедент, то они могут применять один общий пограничный класс для взаимодействия с системой. Обозначаются граничные классы именем стереотипа <<boundary>> либо специальной пиктограммой (рис. 36).
Рис. 36 - Обозначение граничных классов
Управляющий класс отвечает за координацию действий других классов. Они служат для моделирования последовательного поведения одного или нескольких прецедентов и координации событий, реализующих заложенное в них поведение. Обозначаются управляющие классы именем стереотипа <<control>> либо специальной пиктограммой (рис. 37).
Рис. 37 - Обозначение управляющих классов
Управляющие классы можно представить, как «исполняющие» прецедент, поэтому у каждого варианта использования обычно имеется один управляющий класс, контролирующий последовательность событий этого прецедента. Они обычно зависят от приложения.
Управляющий класс делегирует ответственности другим классам. Сам он может получать мало сообщений, но отсылать множество. Его называют классом-менеджером. Он запускает альтернативные потоки и знает, как поступить в случае ошибки. На начальном этапе проектирования управляющие классы создаются для каждой пары актер/прецедент, в дальнейшем они могут объединяться, разделяться или исключаться.
Документирование классов
После того, как класс создан, информацию о нем необходимо документировать. Заметим, что документация предназначена для описания предназначения класса, а не его структуры.
Пример. Если в нашей модели присутствует класс Сотрудник, то хорошим описанием для него будет:
Сотрудник – это человек, работающий на фирме. Класс содержит информацию, необходимую для исполнения организацией своих обязанностей по отношению к сотруднику (начисление зарплаты, перевод на другую должность, увольнение и т.п.)
Плохим описанием будет описание структуры класса, которая может быть и так описана с помощью атрибутов. Например, плохое описание класса Сотрудник:
Имя, телефон, адрес, должность, зарплата.
В StarUML документирование классов выполняется также как и описанное выше документирование прецедентов. Нужно выделить класс, который вы хотите описать, открыть окно документирования Documentation на инспекторе модели и ввести описание класса.
Назначение стереотипов
Чтобы присвоить классу один из стереотипов UML, нужно выделить класс щелчком правой кнопки мыши, открыть редактор свойств Properties на инспекторе модели и выбрать раздел стереотип Stereotype (рис. 43).
Рис. 43 - Назначение стереотипа классу
Если мы нажмем на значок ..., то в появившемся диалоге нам будет представлен список доступных стереотипов с кратким описанием и графическим обозначением. Для того чтобы присвоить классу стереотип, нужно выбрать его в списке, выделить и нажать кнопку OK (рис. 44).
Рис. 44 - Выбор стереотипа
После присвоения классу стереотипа его внешний вид изменится. Рядом с именем класса появится имя стереотипа, заключенное в угловые скобки (рис. 45).
Рис. 45 - Отображение стереотипа класса
Пример. Присвоим классам сценария Оформление заказа соответствующие стереотипы. Диаграмма классов изменится (см. рис. 46).
Рис. 46 - Диаграмма классов сценария Оформление заказа со стереотипами
Мы можем отобразить стереотипы классов с помощью пиктограмм. Для этого нужно выделить класс, щелкнуть по выделенной области правой кнопкой мыши, в контекстном меню выберите пункт Format, затем выберите пункт Stereotype Display, далее в списке выберите Iconic (рис.47).
Рис. 47 - Задание отображения стереотипов классов в виде пиктограмм
Классы будут отображаться как пиктограммы (рис. 48).
Рис. 48 - Отображение классов с помощью пиктограмм стереотипов
Пример. Диаграмму классов сценария Оформление заказа отобразим с помощью пиктограмм (см. рис. 49).
Рис. 49 - Диаграмма классов сценария Оформление заказа в пиктограммах
Пакеты в UML
Если в нашей модели немного классов, то нам легко ими управлять, однако многие системы содержат большое количество классов, поэтому необходим механизм, позволяющий классы группировать и облегчающий их повторное использование. Таким механизмом в UML являются пакеты.
Пакет (package) — общецелевой механизм для организации различных элементов модели в группы.
Подпакет (subpackage) — пакет, который является составной частью другого пакета.
Пакет в логическом представлении модели – это объединение классов или других пакетов. С помощью объединения классов в пакеты мы можем получить представление о системе на более высоком уровне. Напротив, рассматривая пакет, мы получаем более детальное представление модели.
Объединять классы в пакеты можно как угодно, однако, существует несколько наиболее распространенных подходов.
- можно группировать классы по стереотипам: классы-сущности, граничные и управляющие классы.
- группировка классов по их функциональности: например, пакет классов, отвечающих за безопасность системы или пакет классов Работа с сотрудниками и т.п.
- наконец, применяют комбинацию двух указанных методов.
В дальнейшем можно вкладывать пакеты друг в друга.
Чаще всего пакет на диаграмме изображается в виде папки с закладкой с именем пакета (рис. 50).
Рис. 50 - Пакет
Главную диаграмму пакетов системы обычно помещают диаграмме Main представления Logical View. Для того чтобы создать пакет на диаграмме, нужно открыть рабочее поле диаграммы, щелкнуть по элементу пакет Package на панели элементов слева, затем щелкнуть по рабочему полю диаграммы в том месте, где вы хотите поместить пакет. В окне редактора свойств можно задать новое имя пакета.
Чтобы разместить классы по пакетам, используют метод перетаскивания: на навигаторе модели нужно перетащить, удерживая левую кнопку мыши, классы в соответствующие пакеты на навигаторе модели.
Пример. Созданные ранее классы сценария Оформление заказа сгруппируем по пакетам, диаграмму пакетов поместим на листе Main представления Logical View. Создадим пакеты Граничные классы, Классы-сущности, Управляющие классы (рис. 51).
Рис. 51 - Диаграмма пакетов
Перетащим на навигаторе модели класс Customer (Покупатель) в пакет Классы-сущности (рис. 52).
Рис. 52 - Перемещение классов в пакеты
Аналогично классы Item (Товар) и Order (Заказ) разместим в пакете Классы-сущности, классы ОформлениеЗаказа (PlaceOrder), ВводЛичныхДанных (EnterPersonalInformation), ПроверкаДеталейЗаказа (ConfirmOrder) и ПодтверждениеЗаказа (OrderConfirmation) разместим в пакете Граничные классы, а класс МенеджерОформленияЗаказа (PlaceOrderManager) – в пакете Управляющие классы.
Обратите внимание, что при этом внешний вид диаграмм классов Place Order и диаграммы пакетов Main не изменится.
Задание
Для выбранного варианта в StarUML, используя подход RationalApproach, разработать:
- основную диаграмму вариантов использования для проектируемой системы;
- для выбранных двух основных прецедентов:
- поясняющие диаграммы вариантов использования;
- потоки событий;
- для выбранных двух дополнительных прецедентов:
- диаграммы деятельности;
- диаграммы классов со стереотипами;
- разместить по пакетам созданные классы для каждой диаграммы классов.
Варианты
1. Программный модуль «Информационная система библиотеки». Приложение позволяет искать книги в своем каталоге, учитывать выдачу книг на руки и возврата книг, а также добавлять книги в фонд и списывать их.
2. Программный модуль «Кафедра». Содержит сведения о сотрудниках кафедры (ФИО, должность, ученая степень, дисциплины, нагрузка, общественная работа, совместительство и др.). Модуль предназначен для использования сотрудниками отдела кадров и деканата.
3. Программный модуль «Лаборатория». Содержит сведения о сотрудниках лаборатории (ФИО, пол, возраст, семейное положение, наличие детей, должность, ученая степень). Модуль предназначен для использования сотрудниками профкома и отдела кадров.
4. Программный модуль «Химчистка». При записи на обслуживание заполняется заявка, в которой указываются ФИО владельца, описание изделия, вид услуги, дата приема заказа и стоимость услуги. После выполнения работ распечатывается квитанция.
5. Программный модуль «Поликлиника». Приложение должно позволяет ставить и снимать больных с учета, записывать больных на прием к врачам, учитывать факт приема, а также вести историю болезни (медицинскую карту) больного.
6. Программный модуль «Картотека автомагазина». В базе содержатся сведения об автомобилях (марка, объем двигателя, дата выпуска и др.). При поступлении заявки на покупку производится поиск подходящего варианта. Если такого нет, клиент заносится в клиентскую базу и оповещается, когда вариант появляется.
7. Программный модуль «Картотека абонентов АТС». Картотека содержит сведения о телефонах и их владельцах. Фиксирует задолженности по оплате (абонентской и повременной).
8. Программный модуль «Автокасса». Содержит сведения о наличии свободных мест на автобусные маршруты. В базе должны храниться сведения о номере рейса, маршруте, водителе, типе автобуса, дате и времени отправления, а также стоимости билетов. При поступлении заявки на билеты программа производит поиск подходящего рейса.
9. Программный модуль «Книжный магазин». Содержит сведения о книгах (автор, название, издательство, год издания, цена). Покупатель оформляет заявку на нужные ему книги, если таковых нет, он заносится в базу и оповещается, когда нужные книги поступают в магазин.
10. Программный модуль «Автостоянка». Содержитс информация о марке автомобиля, его владельце, дате и времени въезда, стоимости стоянки, скидках, задолженности по оплате и др.
11. Программный модуль «Учет успеваемости студентов». Предназначен для оперативного учета успеваемости студентов в сессию деканом, заместителями декана и сотрудниками деканата. Сведения об успеваемости студентов должны храниться в течение всего срока их обучения и использоваться при составлении справок о прослушанных курсах и приложений к диплому.
12. Программный модуль «Личные дела студентов». Предназначен для получения сведений о студентах сотрудниками деканата, профкома и отдела кадров. Сведения должны храниться в течение всего срока обучения студентов и использоваться при составлении справок и отчетов.
13. Программный модуль "Информационная система склада".
Предназначен для учета поступления и списание товаров со склада, а также для определения места хранения товаров на складе.
14. Программный модуль «Информационная система технической экспертизы». Позволяет соискателям грантов подавать заявки, независимым экспертам оценивать заявки, а держателям фонда принимать решение о выдаче гранта по результатам экспертизы заявок.
15. Программный модуль «Органайзер». Предназначен для записи, хранения и поиска адресов и телефонов физических лиц и организаций, а также расписания, встреч и др.
Рекомендуемые источники
- Шмуллер Д. Освой самостоятельно UML 2 за 24 часа. Практическое руководство / Шмуллер Д.; пер. с англ. - М.: Вильямс, 2005. - 416 с.: ил. - ISBN 0-672-32640-X;
- Арлоу Д. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2е издание / Арлоу Д., Нейштадт И.; пер. с англ. - Спб: Символ-Плюс, 2007. - 624с.: ил. - ISBN 978-5-93286-094-6;
- Национальный открытый университет «Интуит» / Нотация и семантика языка UML. URL: http://www.intuit.ru/studies/courses/32/32/info
- Национальный открытый университет «Интуит» / Введение в UML. URL: http://www.intuit.ru/studies/courses/1007/229/info
Контрольная работа
Тема: Визуальное моделирование программной системы в StarUML
Введение
UML - это язык визуального моделирования программных систем. Моделирование систем с помощью UML предполагает построение ряда взаимосвязанных диаграмм. Для сопровождения процесса построения, анализа и документирования модели, а также проверки модели и генерации программных кодов разработчики используют специально для этих целей созданные CASE-инструменты проектирования систем.
В общем смысле CASE (Computer-Aided Software Engineering) — это набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов.
Существует достаточно много CASE-инструментов моделирования и проектирования систем и баз данных (не только с помощью UML). В нашем случае выбран программный инструмент моделирования StarUML.
Данная программная платформа имеет свободную лицензию и доступна для установки с официального сайта StarUML:
http://sourceforge.net/projects/staruml/files/staruml/5.0/staruml-5.0-with-cm.exe/download?use_mirror=netcologne&download=&failedmirror=dfn.dl.sourceforge.net
StarUML поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0, а также подход MDA (Model Driven Architecture), предлагает настройку параметров пользователя для адаптации среды разработки, поддерживает расширения, предоставляет различного рода модули, расширяющие возможности StarUML.
Дата: 2018-12-28, просмотров: 1956.
