34. Средства UML для представления атрибутов коллекций в контексте проектирования статической структуры ПО

Что такое коллекции в UML?

Коллекции — это структуры данных, которые хранят множество элементов (например, список, множество, карта). В объектно-ориентированном моделировании важно правильно их отображать, чтобы показать, что класс содержит набор элементов.

Средства UML для представления коллекций

1.Атрибуты с указанием множественности (Multiplicity)

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

-Например:

-orders: Order [0..*]

означает, что у класса есть коллекция заказов, которая может содержать ноль или более элементов.

2. Использование коллекционных типов

-В UML можно явно указать тип коллекции:

-List<Order>

-Set<Product>

-Map<Key, Value>

-Эти типы указывают на конкретную структуру данных, используемую для хранения элементов.

3. Стереотипы и комментарии

-Для обозначения коллекций используют стереотипы, например:

<<collection>>

-Или добавляют комментарии к атрибутам, чтобы уточнить, что это коллекция.

4. Диаграммы Package и композиции

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

5.Использование UML-диаграмм объектов

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

35. Признаки существования зависимости между классами в контексте проектирования статической структуры ПО

Зависимость в проектировании — это структурная связь

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

Признаки:

1.​ Класс использует другой для выполнения своих обязанностей​ (например, вызывает методы, опирается на поведение или данные другого класса).

2.​ Класс зависит от интерфейса или контракта другого класса​ (например, реализует интерфейс или наследует от базового класса).

3.​ Один класс управляет жизненным циклом объектов другого​ (например, композиция — создаёт и уничтожает объект).

4.​ Изменение одного класса требует изменений в другом — признак логической или структурной связи.

5.​ Функциональная ответственность одного класса реализуется через другой — например, делегирование или координация поведения.

6.​ Совместное участие в одном варианте использования (use case) — если классы взаимодействуют при выполнении общей задачи, они, скорее всего, связаны.

36. Стадии создания информационной системы в рамках канонического проектирования

1. Предпроектное обследование (исследование и анализ)

●​ Анализ предметной области и текущей ситуации. ●​ Выявление проблем, целей и задач.

●​ Сбор и формализация требований пользователей.

●​ Анализ бизнес-процессов и информационных потоков.

2. Техническое задание (ТЗ)

●​ Описание назначения, функций и требований к системе.

●​ Установление требований к качеству, надежности, безопасности. ●​ Согласование и утверждение документа с заказчиком.

●​ Определение критериев приемки системы.

3. Эскизное проектирование (эскизный проект)

●​ Выбор принципиальных технических и программных решений. ●​ Разработка общей логической структуры системы.

●​ Построение предварительных моделей и диаграмм. ●​ Оценка стоимости и трудоёмкости проекта.

4. Техническое проектирование

●​ Подробное проектирование архитектуры системы.

●​ Разработка структуры баз данных, интерфейсов, алгоритмов.

●​ Проектирование технического, программного и организационного обеспечения.

5. Рабочее проектирование (разработка рабочей документации)