Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ППП-типо-похоже-на лекции!.docx
Скачиваний:
21
Добавлен:
21.09.2019
Размер:
2.06 Mб
Скачать

2.2.Стадия логического проектирования

Логическое проектирование — это процесс описания решения в терминах организации,структуры, синтаксиса и взаимодействие его частей с точки зрения проектной группы.

Его цель — применить принципы модели MSF и изучить структуру приложения и взаимодействие его частей.

Результат данной стадии — набор бизнес-объектов с соответствующими сервисами, атрибутами и взаимосвязями; детальный проект пользовательского интерфейса и логический проект базы данных.

На стадии логического проектирования:

• приложение упрощается благодаря определению его структуры,

описанию частей системы и их взаимодействия;

• устанавливаются границы и описываются интерфейсы, обеспечивающие организационную структуру взаимодействия между компонентами;

• выявляются все ошибки и несообразности концептуального проекта;

• устраняется избыточность и определяются части проекта, которые можно использовать повторно;

• закладывается фундамент физического проекта;

• улучшается работа различных частей приложения и приложения в целом;

• все члены группы приходят к единому мнению относительно проекта приложения.

логический проект не зависит от его физической реализации.

Он описывает, как должна работать система.

Логическое проектирование состоит из двух этапов:

•анализа

•рационализации.

(Нет стадии исследования, так как начальными данными для логического проектирования служат результаты концептуального.)

На стадии анализа: • выявляются бизнес-объекты и сервисы; • определяются их атрибуты и взаимосвязи.

На стадии рационализации:• бизнес-объекты проверяются;• выявляются неявно использованные или дополнительные бизнес-объекты и сценарии.

Первый этап: анализ

Назначение этого этапа — преобразовать сценарии концептуального проекта в модули, применяемые в логическом проектировании. Модули — это основные схемы использования системы, работающие в их рамках сервисы и виды деятельности, а также связи между ними. Они

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

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

• действия (выражаются глаголами) — это сервисы:

• субъекты и объекты (выражаются существительными) — это бизнес-объекты;

• атрибуты — то, как они связаны со свойствами:

• взаимосвязи, которые определяются свойствами.

Кроме того, важный источник информации — текущая ситуация и физическая среда.

Сервис — это элементарная единица приложения, реализующая операцию, функцию или преобразование. Бизнес-объект инкапсулирует сервисы и данные, используемые при составлении и упрощении решения. Такие объекты — люди или веши.

Стадия анализа завершена, когда решены следующие задачи:

• выявлены сервисы и подготовлен их список;

• выявлены объекты и подготовлен их список;

• определены атрибуты и подготовлен их список;

• определены взаимосвязи и подготовлен их список.

Второй этап: рационализация

Главная задача рационализации — создать те сервисы и объекты, которых не было на предыдущих стадиях проектирования. Они нужны, потому что предполагается их существование или они потребовались для контроля. Затем проектная группа «вычищает» и проверяет проект.

--уточнить сервисы и объекты

Дополнительные сервисы и объекты

На этом этапе создаются объекты и сервисы, которых не было на предыдущих стадиях проектирования.

Контроль

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

----------- «Очистка» проекта от мусора

После создания объектов нужно «очистить» проект от «мусора*:

• уничтожить объекты, не относящиеся к поставленной задаче;

• объединить избыточные объекты;

• выявить неявно используемые объекты;

• разделить атрибуты и объекты;

• рассмотреть управление транзакциями;

• отделить роли и их исполнителей от объектов.

Проверка

Проверка — это тестирование полноты и корректности проекта на уровне объектов. При этом объекты проверяются как по отдельности, так и в совместной работе. Тестирование независимых объектов упрощает задачу их интеграции в единое целое, так как их тщательно проверили еще до сборки. Тестирование взаимодействия объектов гарантирует, что работа, предписанная сценарием, будет выполнена.

-------------Выявление неявности