2.2.Стадия логического проектирования
Логическое проектирование — это процесс описания решения в терминах организации,структуры, синтаксиса и взаимодействие его частей с точки зрения проектной группы.
Его цель — применить принципы модели MSF и изучить структуру приложения и взаимодействие его частей.
Результат данной стадии — набор бизнес-объектов с соответствующими сервисами, атрибутами и взаимосвязями; детальный проект пользовательского интерфейса и логический проект базы данных.
На стадии логического проектирования:
• приложение упрощается благодаря определению его структуры,
описанию частей системы и их взаимодействия;
• устанавливаются границы и описываются интерфейсы, обеспечивающие организационную структуру взаимодействия между компонентами;
• выявляются все ошибки и несообразности концептуального проекта;
• устраняется избыточность и определяются части проекта, которые можно использовать повторно;
• закладывается фундамент физического проекта;
• улучшается работа различных частей приложения и приложения в целом;
• все члены группы приходят к единому мнению относительно проекта приложения.
логический проект не зависит от его физической реализации.
Он описывает, как должна работать система.
Логическое проектирование состоит из двух этапов:
•анализа
•рационализации.
(Нет стадии исследования, так как начальными данными для логического проектирования служат результаты концептуального.)
На стадии анализа: • выявляются бизнес-объекты и сервисы; • определяются их атрибуты и взаимосвязи.
На стадии рационализации:• бизнес-объекты проверяются;• выявляются неявно использованные или дополнительные бизнес-объекты и сценарии.
Первый этап: анализ
Назначение этого этапа — преобразовать сценарии концептуального проекта в модули, применяемые в логическом проектировании. Модули — это основные схемы использования системы, работающие в их рамках сервисы и виды деятельности, а также связи между ними. Они
являются логическими блоками, абстрагирующими схемы использования и сценарии концептуального проекта. Для каждого модуля проектная группа выявляет сервисы, объекты, атрибуты и взаимосвязи.
Для выявления сервисов, бизнес-объектов, атрибутов и взаимосвязей проектная группа изучает описанные в сценариях процессы и последовательности задач, обращая особое внимание на:
• действия (выражаются глаголами) — это сервисы:
• субъекты и объекты (выражаются существительными) — это бизнес-объекты;
• атрибуты — то, как они связаны со свойствами:
• взаимосвязи, которые определяются свойствами.
Кроме того, важный источник информации — текущая ситуация и физическая среда.
Сервис — это элементарная единица приложения, реализующая операцию, функцию или преобразование. Бизнес-объект инкапсулирует сервисы и данные, используемые при составлении и упрощении решения. Такие объекты — люди или веши.
Стадия анализа завершена, когда решены следующие задачи:
• выявлены сервисы и подготовлен их список;
• выявлены объекты и подготовлен их список;
• определены атрибуты и подготовлен их список;
• определены взаимосвязи и подготовлен их список.
Второй этап: рационализация
Главная задача рационализации — создать те сервисы и объекты, которых не было на предыдущих стадиях проектирования. Они нужны, потому что предполагается их существование или они потребовались для контроля. Затем проектная группа «вычищает» и проверяет проект.
--уточнить сервисы и объекты
Дополнительные сервисы и объекты
На этом этапе создаются объекты и сервисы, которых не было на предыдущих стадиях проектирования.
Контроль
Он позволяет удостовериться, что сервисы работают в правильном порядке и в нужное время. В распределенных системах для упорядочения сервисов и взаимосвязей объектов применяют транзакции. В других случаях для проверки целостности сценария, координации сервисов и управления связями объектов используют контрольные объекты.
----------- «Очистка» проекта от мусора
После создания объектов нужно «очистить» проект от «мусора*:
• уничтожить объекты, не относящиеся к поставленной задаче;
• объединить избыточные объекты;
• выявить неявно используемые объекты;
• разделить атрибуты и объекты;
• рассмотреть управление транзакциями;
• отделить роли и их исполнителей от объектов.
Проверка
Проверка — это тестирование полноты и корректности проекта на уровне объектов. При этом объекты проверяются как по отдельности, так и в совместной работе. Тестирование независимых объектов упрощает задачу их интеграции в единое целое, так как их тщательно проверили еще до сборки. Тестирование взаимодействия объектов гарантирует, что работа, предписанная сценарием, будет выполнена.
-------------Выявление неявности
- 2. Модель па
- 2.1.Бизнес - перспектива
- 2.2.Прикладная перспектива
- 2.3.Информационная перспектива
- 2.4.Технологическая перспектива
- 2.5 Основные опасности при разработке производственной архитектуры
- 2.6 Задачи модели производственной архитектуры msf
- 3. Создание производственной архитектуры
- 1. Общая характеристика модели приложения
- 1.1.Повторное использование компонентов
- 1.2.Размер приложения
- 1.3. Производительность приложения
- 1.4.Масштабируемость приложений
- 1.5.Виды архитектуры
- 2. Модель приложений
- 2.1. Бизнес-модель
- 2.2 Пользовательская модель
- 2.3 Логическая модель
- 2.4 Технологическая модель
- 2.5 Модель разработки
- 2.6 Физическая модель
- 1. Общие характеристики модели проектных групп
- 2. Обязанности членов группы
- 3. Модель проектой группы
- 3.1. Менеджер продукта
- 3.2Менеджер программы
- 3.3.Разработчик
- 3.4 Тестер
- 3.5.Инструктор
- 3.6 .Логистик
- 4.Размер групп и масштаб проекта
- 5. Создание группы
- 5.1.Поиск руководителей
- 5.2.Повышение эффективности коллективной работы
- 5.3. Координация работы с внешними группами
- 1. Модель разработки приложений
- 2.Модель процесса разработки msf
- Основные этапы
- Промежуточные этапы
- Итеративность
- 3. Фазы разработки и их основные этапы.
- 3.1 Фаза Анализ
- 3.3.Фаза «Планирование»
- 3.3.Фаза «Разработка»
- 3.4. Фаза «Стабилизация»
- 4. Принципы модели процесса разработки
- 5.Роли членов группы в модели процесса разработки
- Динамика фазы Анализ модели процесса разработки msf
- 1.Процесс исследования
- 1.1.Распределение обязанностей ролей
- 2. Модель управление рисками
- 2.1.Источники риска
- 2.2.Способы управления рисками
- 3.Этап «Одобрение концепции» и его результаты
- 3.1Концепция
- 3.2.Прототип
- 3.3. Структура проекта
- 3.4. Сводный документ оценки рисков
- 3.5. Согласование концепции
- Динамика фазы планирования
- 1.Общая характеристика фазы планирования
- Фаза «Планирование» и процесс проектирования
- Распределение ролей при планировании
- Обязанности ролей при планировании
- 12.Процесс проектирования
- 2.1. Стадии концептуального проектирования
- 2.2.Стадия логического проектирования
- 2.3.Стадия физического проектирования
- 2.1. Управление рисками на фазе планирования
- 4.Этап «Одобрение плана проекта» и его результаты
- 4.1.Функциональные спецификации
- 4.2.Основной план проекта
- 4.2.Основной график проекта
- 4.3.Пересмотренный документ оценки рисков
- Динамика фазы разработки и ее основные результаты.
- 1. Общая характеристика фазы разработки
- 2. Основные этапы разработки
- 2.1.Распределение обязанностей на стадии разработки
- 2.3.Первый этап: анализ и рационализация
- 2.4.Второй этап: реализация
- 2.5.Третий этап: аттестация
- 2.6.Управление рисками
- 3.Этап «Завершение разработки» и его результаты
- 3.1. Код и исполняемые модули
- 3.2.Средства повышения эффективности работы пользователей и сопроводительные материалы
- 3.3. Тестовые материалы
- Динамика фазы стабилизации
- Распределение обязанностей в группе
- Промежуточные этапы
- Управление рисками на фазе Стабилизации
- 1)Организованные риски;
- Этап «Выпуск продукта» и его результаты