Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Физическое проектирование




Логический проект не зависит от его физической реализации. Он описывает, как должна работать система.

Логическое проектирование

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

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

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

Этап анализа

На этапе анализа:

- выявляются бизнес-объекты и необходимые сервисы;

- определяются их атрибуты и взаимосвязи.

Сервисы представляют собой операции объектов. Обычно они выражаются глаголами, например, [создать] [удалить]. Сервисы состоят как из алгоритмически простых функций (создать, удалить), так и из выполняющих сложные вычисления и преобразования (например, [проверка] [передача] [оплата]). Объекты (выражаются существительными) – это люди, вещи, места, другие системы. Атрибуты – то, как объекты связаны со свойствами (определения объекта, например, [имя] [адрес] [тип]). Взаимосвязи определяются свойствами объектов и представляют объединяющую объекты логическую связь (целое/часть, взаимодействие, обобщение/специализация, зависимость; например, [содержит] [зарегистрирован в] [является] [знает]).

Этап анализа завершён, если выявлены сервисы и подготовлен их список; выявлены объекты и подготовлен их список; определены атрибуты и подготовлен их список; определены взаимосвязи и подготовлен их список.

Хороший финал стадии анализа – Class diagrams.

Этап рационализации

На этапе рационализации:

- проверяются бизнес-объекты;

- выявляются ненужные или дополнительные объекты и сценарии.

Главная задача – создать те сервисы и объекты, которые не были выявлены ранее. После создания объектов нужно “очистить” проект “от мусора” и проверить полноту и корректность проекта на уровне объектов. Определить предусловия и постусловия, чтобы гарантировать работу каждого отдельного объекта.

Физическое проектирование – это описание компонентов, сервисов и технологий, используемых для получения решения.

Результат этого этапа проектирования – набор компонентов, проект пользовательского интерфейса для определённой платформы и физический проект базы данных.

Стадия физического проектирования состоит из четырёх этапов: исследования, анализа, рационализации и реализации.

Каждый этап заканчивается конкретными результатами.

Этап исследования

На этапе исследования:

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

- определяются физические требования к решению;

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

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

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

Этап анализа

На этапе анализа:

- выбираются возможные технологии реализации;

- создаётся эскиз модели развёртывания, включающий сетевые и компонентные технологии, а также технологии данных.

К технологическим вопросам относятся: языки программирования (язык должен поддерживать реализацию взаимосвязанных компонентов, которые при необходимости придётся заменять и обновлять); стандарты взаимодействия компонентов (способ “общения” компонентов); методы доступа к данным (взаимодействие компонентов с хранилищами данных); системные сервисы; операционные системы.

Модель развёртывания (Deployment Diagram) состоит из топологии сети, данных и компонентов:

1. Сетевая топология – это инфраструктурная карта, где отмечено расположение оборудования и указаны связи между отдельными устройствами.

2. Топология данных – это карта размещения данных, где отмечено местонахождение хранилищ данных в соответствии с топологией сети.

3. Топология компонентов – это карта, где отмечено местонахождение самих компонентов и их сервисов в соответствии с топологией сети.

Анализ завершён, когда решены следующие задачи: составлен список технологий; создана предварительная модель развёртывания, включающая топологии сети, данных и компонентов.

Этап рационализации

На этапе рационализации:

- определяется способ комплектации и развёртывания;

- выполняется декомпозиция объектов на компоненты и сервисы;

- компоненты распределяются в соответствии с топологией;

- происходит “очистка” плана комплектации и развёртывания.

Развёртывание основывается на трёх уровнях сервисов: пользовательском (User Service), прикладном (Business Service) и уровне управления данными (Data Service). Для проверки проекта применяют прототип приложения. По мере появления новых компонентов их включают в прототип и изучают работу. За процесс “очистки” компонентов отвечают разработчики и тестеры. Одна из целей – добиться сильных элементных и слабых компонентных связей (связей между элементами компонента и связь между разными компонентами).

Рационализация завершена, когда решены следующие задачи: определена стратегия комплектации и развёртывания; объекты преобразованы в компоненты, основанные на сервисах; компоненты распределены по топологиям сети, данных и компонентов.

Этап реализации

На этапе реализации:

- выбирается программная модель;

- определяется интерфейс компонентов;

- компоненты описываются на языке разработки;

- изучается структура компонентов.

На данном этапе создаётся модель программирования. Ниже перечислены некоторые элементы программной модели:

Технологии реализации. Язык программирования; прикладные интерфейсы; серверы и серверные технологии.

Объекты с состоянием и без него. Объекты с состоянием хранят информацию (состояние) и отражают выполнение клиентских вызовов, а объекты без состояния – нет. При выборе типа объектов нужно учесть его масштабируемость, сложность и производительность.

Внутренние и внешние функции. Внутренние вызовы выполняются быстро и напрямую; внешние вызовы на том же компьютере также выполняются достаточно быстро и обеспечивают безопасное взаимодействие процессов. Внешние вызовы на разных компьютерах безопасны, надёжны и могут использовать гибкий протокол на основе вызова удалённых процедур в распределённой среде (Distributed Computing Environment Remote Procedures Calls, DCE-RPC).

Режимы с подключением и без него. В средах с подключением различные компоненты, участвующие в решении задачи, должны быть постоянно соединены друг с другом. Если соединение прервётся, – возникнет ошибка. Приложения реального времени обычно работают в режиме с подключением. Приложения и компоненты, написанные для использования в среде без подключения, способны установить соединение, только когда оно необходимо.

Синхронные и асинхронные программные модели. В синхронной модели выполнение компонента, вызвавшего интерфейс, блокируется до завершения выполнения вызова и возвращения управления компоненту. В асинхронной программной модели компоненты способны передавать друг другу сообщения и продолжать работу, не дожидаясь ответа. Асинхронная модель предпочтительнее.

Модель потоков. Зависит от назначения компонента. Произвольные потоки или синхронизированные.

Обработка ошибок. Методы обработки ошибок.

Защита. Каждый компонент или сервис имеет четыре варианта защиты: компонентный (на уровне методов, интерфейсов или компонентов), на уровне базы данных, на уровне пользовательского контекста (системная защита или на уровне приложения) и ролевой (например, администратор или обычный пользователь).

Развёртывание. Три логических уровня не обязательно преобразовывать в три физических уровня. Логические уровни можно распределять по физическим уровням (например, некоторые бизнес-сервисы разместить на клиенте).

Внешняя структура компонента описана в его интерфейсе:

- является контрактом, реализующим связь типа “поставщик-потребитель” между компонентами;

- является средством доступа к основным сервисам;

- реализует один или несколько сервисов;

- включает основные атрибуты объекта.

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

Этап реализации завершается, когда решены следующие задачи: выбрана программная модель; определены внешние структуры компонентов (в том числе, интерфейсы, атрибуты и сервисы); определены внутренние структуры компонентов.

 

 


[1] Суть маршрутизации заключается во включении наибольшего числа вагонов в маршруты, чтобы поезда следовали от станции погрузки до станции выгрузки без переформирования. Под отправительской маршрутизацией понимается такая, которая может осуществляться непосредственно со станций (мест) массовой погрузки.

[2] Модель – это абстракция, описывающая систему с определённой точки зрения и на определённом уровне абстрагирования.

[3] При проектировании бизнес-процессов корпоративных систем понятие узла может включать в себя организационные подразделения (состоящие из персонала), человека-оператора (принимающего решения в нештатных ситуациях).

[4] ГОСТ 19.201-78. Техническое задание.

ГОСТ 19.202-78. Спецификация.

ГОСТ 19.301-79. Программа и методика испытаний.

ГОСТ 19.503-79. Руководство системного программиста.

ГОСТ 19.504-79. Руководство программиста.

РД 50-34.698-90 – Методические указания. Информационная технология. Автоматизированные системы. Требования к содержанию документов.




Поделиться с друзьями:


Дата добавления: 2014-01-07; Просмотров: 1775; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.017 сек.