Читайте также:
|
|
Унифицированный язык моделирования (Unified Modeling Language) – это универсальный язык визуального моделирования систем.
UML объединил лучшие современные технические приемы моделирования и разработки программного обеспечения. По сути, язык UML был задуман так, чтобы его можно было реализовать посредством его же инструментальных средств. Фактически это признание того, что большие современные программные системы, как правило, нуждаются в инструментальной поддержке. UML-диаграммы легко воспринимаются и при этом без труда генерируются компьютерами.
Основная идея UML – возможность моделировать программное обеспечение и другие системы как наборы взаимодействующих объектов.
Это, конечно же, замечательно подходит для ОО программных систем
и языков программирования, но также очень хорошо работает и для бизнес-процессов и других прикладных задач.
В UML-модели есть два аспекта:
• Статическая структура – описывает, какие типы объектов важны для моделирования системы и как они взаимосвязаны.
• Динамическое поведение – описывает жизненные циклы этих объектов и то, как они взаимодействуют друг с другом для обеспечения требуемой функциональности системы.
Эти два аспекта модели UML идут рука об руку, и ни один из них не является по-настоящему полным без другого.
Понимание работы UML как визуального языка начинается с рассмотрения его структуры. Эта структура включает:
• строительные блоки – основные элементы, отношения и диаграммы UML-модели;
• общие механизмы – общие UML-пути достижения определенных
целей;
• архитектура – UML-представление архитектуры системы.
Наличие структуры указывает на то, что сам UML – это спроектированная система с собственной архитектурой.
UML состоит всего из трех строительных блоков (см. рис. 2.2):
• Сущности – это сами элементы модели.
• Отношения связывают сущности. Отношения определяют, как семантически связаны две или более сущностей.
• Диаграммы – это представления моделей UML. Они показывают
наборы сущностей, которые «рассказывают» о программной системе и являются нашим способом визуализации того, что будет делать система (аналитические диаграммы) или как она будет делать
это (проектные диаграммы).
Сущности – это существительные UML-модели. Все UML-сущности можно разделить на:
• структурные сущности – существительные UML-модели, такие как класс, интерфейс, кооперация, прецедент, активный класс, компонент, узел;
• поведенческие сущности – глаголы UML-модели, такие как взаимодействия, деятельности, автоматы;
• группирующая сущность – пакет, используемый для группировки семантически связанных элементов модели в образующие единое целое модули;
• аннотационная сущность – примечание, которое может быть добавлено к модели для записи специальной информации.
Отношения позволяют показать взаимодействие в пределах модели
двух или более сущностей. Для понимания роли, которую отношения
играют в моделях UML, достаточно представить отношения между членами отдельной семьи. Отношения в модели UML позволяют зафиксировать значимые (семантические) связи между сущностями, как показано в таблице. В ней представлены UML-отношения, применяемые к структурным и группирующим сущностям модели. Правильное понимание семантики различных типов отношений является очень важной частью моделирования.
Диаграммы – это своего рода картины, или представления модели.
Диаграмма - это не модель! На самом деле, различие между диаграммой
и моделью является очень важным для понимания, поскольку сущность или отношение могут быть удалены с диаграммы, или даже со всех диаграмм, но по-прежнему они продолжают существовать в модели. Они будут оставаться в модели до тех пор, пока не будут явно удалены из нее. Общая ошибка новичков в UML-моделировании состоит в том, что они удаляют сущности с диаграмм, не удаляя их из модели. Существует множество различных типов UML-диаграмм. Эти диаграммы можно разделить на те, которые моделируют статическую структуру системы (статическую модель), и те, которые моделируют динамическую структуру системы (динамическую модель). Статическая модель фиксирует сущности и структурные отношения между ними; динамическая модель отображает, как сущности взаимодействуют для генерирования требуемого поведения программной системы. Определенного порядка создания UML-диаграмм не существует, хотя обычно начинают с диаграммы прецедентов для определения предметной области системы. Как правило, работа идет одновременно над несколькими диаграммами, каждая из которых уточняется по мере выявления более подробной информации о разрабатываемой программной системе. Таким образом, диаграммы являются как представлением модели, так и основным механизмом введения информации в модель.
В рамках данной курсовой работы мы ограничимся двумя диаграммами:
- Диаграмма прецедентов;
- Диаграмма отношений сущностей.
Моделирование прецедентов – это форма выработки требований. Моделирование прецедентов обычно происходит следующим образом:
• Устанавливаются границы потенциальной системы;
• Выявляются актеры;
• Выявляются прецеденты:
o определяется прецедент;
o устанавливаются основные альтернативные потоки.
• Предыдущие шаги повторяются, пока прецеденты, актеры и границы системы не стабилизируются.
Обычно начинают с самой общей оценки границ системы, чтобы обозначить область моделирования. Затем все действия осуществляются итеративно и зачастую параллельно. Результат этой деятельности – модель прецедентов. В этой модели четыре компонента:
• Граница системы – прямоугольник, очерчивающий прецеденты для обозначения края, или границы, моделируемой системы (см. Рис. 1.1.);
Рис. 1.1. Граница система
• Актеры – роли, выполняемые людьми или сущностями, использующими систему (см. Рис. 1.2.);
Рис. 1.2. Изображение актера
• Прецеденты – то, что актеры могут делать с системой (см. Рис. 1.3.);
Рис. 1.3. Изображение прецедента
• Отношения – значимые отношения между актерами и прецедентами (см. Рис. 1.4.)
Рис. 1.4. Изображение отношения
Моделирование диаграммы отношений сущностей – это моделирование структуры базы данных. В реальном проектировании структуры базы данных применяются другой метод - так называемое, семантическое моделирование. Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).
Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов как "Клиент", "Сотрудник", "Склад". Каждая сущность в модели изображается в виде прямоугольника с наименованием (см. Рис. 1.5.)
Рис. 1.5. Сущность в ER-моделировании
Экземпляр сущности - это конкретный представитель данной сущности. Например, представителем сущности "Клиент" может быть "Сотрудник Вася". Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.
Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности. Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Примерами атрибутов сущности "Клиент" могут быть такие атрибуты как "Идентификатор", "Фамилия", "Имя", "Отчество", "Должность", "Адрес" и т.п. Атрибуты изображаются в пределах прямоугольника, определяющего сущность (см. Рис. 1.6.).
Рис. 1.6. Сущность с атрибутами
Связь - это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою. Связи позволяют по одной сущности находить другие сущности, связанные с нею (см. Рис. 1.7.).
Рис. 1.7. Связи в диаграмме отношений сущностей UML
Глава 2. Моделирование диаграмм. Обзор структуры базы данных по предметной области «Провайдер конечной мили Gigabit»
Дата добавления: 2015-09-04; просмотров: 299 | Нарушение авторских прав
<== предыдущая страница | | | следующая страница ==> |
Особенности СУБД PostgreSQL. | | | Моделирование диаграммы прецедентов и диаграммы отношений сущностей по предметной области «Провайдер конечной мили Gigabit». |