- •Лабораторная работа №5
- •Основы объектной технологии
- •Объект-экземпляр
- •Объектная нотация
- •Как объекты кооперируются
- •Как объекты идентифицируют друг друга
- •Постоянная связь
- •Временная связь
- •Атрибуты
- •Тип атрибута, обозначающий класс
- •Видимость атрибутов
- •Операции
- •Видимость операций
- •Ассоциации
- •Порядок ассоциации
- •Кратность ассоциации
- •Ассоциативная связь и объем ассоциации
- •Ассоциативный класс
- •Наставление по моделированию анализа
- •Internet-магазин
- •Моделирование прецедентов
- •Субъекты
- •Прецеденты
- •Распределение требований по субъектам и прецедентам
- •Документирование прецедентов
- •Моделирование видов деятельности
- •Виды деятельности
- •Диаграмма видов деятельности
- •Моделирование классов
- •Соответствие функциональных требований и классов-сущностей (Іnternet - магазин)
- •Ассоциации
- •Агрегации
- •Обобщения
- •Диаграмма классов
- •Моделирование взаимодействий
- •Взаимодействия
- •Диаграмма последовательностей
- •Моделирование состояний
- •Состояния и переходы
- •Диаграмма состояний
Ассоциативный класс
Иногда ассоциация обладает своими собственными атрибутами (и/или операциями). В качестве модели подобной ассоциации необходимо использовать класс, поскольку атрибуты могут быть определены только в классе. Каждый объект ассоциативного класса обладает значениями атрибутов и связями с ассоциированными классами. Поскольку ассоциативный класс является классом, он может быть ассоциирован с другими классами модели обычным способом.
Наставление по моделированию анализа
В данном разделе представлено краткое наставление по визуальному моделированию на языке UML с использованием простого примера. Цель состоит в том, чтобы продемонстрировать различные виды диаграмм UML и показать, как они согласуются друг с другом. Каждая из диаграмм UML символизирует определенный взгляд на систему. Чтобы понять систему в целом, необходима разработка и интеграция нескольких видов диаграмм, представляющих разные взгляды.
На самом общем уровне можно выделить три типа UML-моделей— каждая со своим собственным набором диаграмм и связанных с ними конструкций.
1. Модель состояний (state model), которая представляет статический взгляд на систему, — это модель требований к данным. Модель состояния представляет структуры данных и отношения на них. Основной метод визуализации модели состояний состоит в использовании диаграммы классов.
2. Модель поведения (behavior model), которая представляет операционный взгляд на систему, — это модель функциональных требований. Модель поведения представляет биз-неочранзакции, операции и алгоритмы над данными. Для визуализации модели поведения существует несколько способов — диаграммы прецедентов, диаграммы последовательностей, диаграммы коперации и диаграммы видов деятельности.
3. Модель изменения состояний (state change model), которая представляет динамический взгляд на систему, — это модель эволюции объектов со временем. Модель изменения состояний представляет возможные изменения состояний объекта (где под состоянием понимаются текущие значения атрибутов и ассоциативных связей с другими объектами). Основной метод визуализации модели изменения состояний заключается в использовании диаграммы состояний [1].
Internet-магазин
Internet вызвал революцию в способах ведения бизнеса. Чтобы оставаться конкурентоспособными организациям, необходимо "присутствовать" в Internet и расширить круг своих бизнес-приложений, включив в них средства электронной коммерции (е-commerce). Изменения касаются прежде всего клиентской части (front end) приложений, однако, основная серверная часть (back end) систем управления базами данных (СУБД) по-прежнему должна выполнять вполне традиционную обработку деловых операций.
Наставление задумано с целью продемонстрировать методы визуального моделирования языка UML. Представленная последовательность видов деятельности по моделированию также задумана таким образом, чтобы показать зависимости между диаграммами UML.
Последовательность видов деятельности не должна рассматриваться как рекомендуемый процесс. В действительности процесс является итеративным процессом с наращиванием возможностей. Слишком сильная опора в наставлении на моделирование прецедентов в действительности не отражает сложившейся практики разработки ПО. Обычно наряду с моделированием прецедентов должно проводиться моделирование классов.