Технологическая сеть проектирования системы
Технологическая сеть строится на основе использования объектно-ориентированной Case технологии, для которой характерно последующее расширение и уточнение на различных стадиях ЖЦ.
Технологическая сеть выглядит следующим образом:
Добсл – описание системы,
Д’пи, Д’’пи – диаграммы прецедентов использования
Д’о, Д’’о, Д’’’о – диаграммы классов объектов
Д’с, Д’’с, Д’’’с – диаграммы состояния отчетов
Д’пк, Д’’пк – диаграммы пакетов
Д’’в – диаграммы взаимодействия
Д’’д, Д’’’д – диаграммы деятельности
Д’’’к – диаграммы компонентов
Д’’’р – диаграммы размещения компонентов
Uяз – универсум языков программирования
G0 – классы объектов,
Gn – процедуры методов
П1: Анализ системных требований к системе
На входе этапа анализа системных требований используется описание системы, полученное в результате выполнения работ по анализу и проектированию процессов. Эти материалы содержат описание организационной структуры, структуры потоков, которая может быть выполнена с помощью графического отображения либо на основе использования методологии.
Анализ системных требований начинается с идентификации основных прецедентов использования (Д’пи) и объектов сущностей (Д’о), которые будут применяться в ИС. Работы по идентификации прецедентов использования и классов объектов сущностей выполняется параллельно. Разработка ДПИ предполагает выделение тех последовательностей, которые будут автоматизировать необходимые процессы. При этом определяются основные пользователи, которые взаимодействует с прецедентами использования.
|
|
|
Разработка диаграмм классов объектов предполагает задание состава основных атрибутов и определения характера взаимодействующих классов объектов. Разработка диаграмм состояний объектов выполняется только для классов объектов со сложным поведением. При этом рассматриваются все прецеденты использования, в которых объекты данного класса используются или меняют свои состояния. Разработка диаграмм пакетов осуществляется путем группирования классов объектов по подсистемам. При этом выделяются функциональные пакеты, которые объединяют классы объектов, которые реализуют функции управления и базовые пакеты с нормативно-справочной информацией.
Логическое проектирование
На этапе логического проектирования осуществляется детализация моделей прецедента использования классов объектов и разработки моделей взаимодействия объектов, а так же при необходимости производится разработка моделей деятельности, которая определяет характер процедур обработки объектов.
|
|
|
Детализация программы прецедентов использования
П23 - уточн. диаграмма состояний
П22 – детализированная диаграмма классов объектов
П24 – разработка диаграмм взаимодействий объектов
П25 – разработка диаграмм деятельности
П26 – детализация диаграмм компонентов
Дпи – диаграммы прецедентов использования
До – диаграммы классов объектов
Дс – диаграммы состояний объектов
Дпк – диаграммы пакетов
Дв – диаграммы взаимодействий
Дд – диаграммы деятельности
Детализация диаграмм прецедентов использования предполагают разработку альтернативных и основных потоков событий, который может представлять самостоятельную диаграмму деятельности.
Детализация диаграмм классов объектов выполняется уточнением классов объектов сущности и введенный интерфейс и управление классов объектов.
Уточняющие диаграммы связи объектов выполняются в связи с детализацией диаграмм прецедентов использования и диаграмм классов объектов.
Разработка диаграмм взаимодействия выполняется отдельно для каждого прецедента использования с учетом построения диаграмм классов объектов и состояний.
Разработка диаграмм деятельности уточняет характер деятельности в нескольких прецедентах использования.
|
|
|
Детализация пакетов связана с уточнением состава классов, объектов, сущности и появления интерфейса управления классов объекта.
Физическое проектирование ИС
На этапе физического проектирования происходит реализация диаграмм классов объектов и пакетов с позиции их реализации в конкретной программно-технической среде.
П31 – спецификация физ. реализации диаграммы классов объектов
П32 – детализация диаграммы пакетов
П33 – разработка диаграммы компонентов
П34 – разработка диаграмм размещения компонент
До – диаграммы классов объектов
Дпк – диаграммы пакетов
Дк – диаграммы компонентов
Др – диаграммы размещений
Спецификация ФР, т.е. диаграмма КО предусматривает определение форматов данных атрибутов и методов реализации отношений классов объектов.
Детализация диаграмм пакетов предполагает разработку обеспечения компонентов, т.е. БД и вспомогательных функций.
Разработка диаграммных компонентов и размещений компонентов реализует КС архитектуру и определяет схему размещения компонентов по узлам ВС.
Реализация ИС
Реализация ИС осуществляется кодогенерацией классов объектов, программируемых процедур методов классов, наполнение БД и размещение компонентов по узлам.
|
|
|
П41 – генератор классов объектов
П42 – генератор процедур методов
П43 – прогр. процедур методов
До – диаграмма КО
Да – диаграмма активности
Дв – взаимодействия
Дс – состояния объектов
G0 – классы объектов
Gш – шаблоны процедур, методов класса объекта
Gm – процедурные метки
Uяз – множество языков
Генератор КО в конкретной ОО среде, выбираемой из множества языков программирования, осуществляется на основе диаграммы КО.
Генератор шаблонов производится на основе диаграмм взаимодействия объектов.
Прогр. процедур методов КО с помощью ОО языка выполняется на основе шаблона процедур по специф. диаграмм деятельности и диаграмм состояния объектов.
Прототипное проектирование
С появлением КИС, базирующихся на КС технологии, появляется возможность ускорить разработку приложений, за счет параллельной разработки клиентской и серверной части системы.
Реальное использование этих возможностей является сложным, из-за резко возросшей сложности создания приложений.
Кроме естественных сложностей создания приложений в неоднородной среде, существуют тенденции усложнения приложений с течением времени. Основным условием является вовлечение пользователя в процесс разработки. Данная технология проектирования обеспечивает создание на ранней стадии действующей интерактивной модели системы (система прототипа), которая позволяет наглядно продемонстрировать пользователю будущую ИС. Т.о. пользователь может реально оценить возможности будущей системы и определить наиболее удобный режим обработки данных.
Согласованная система – прототип служит спецификой создания будущей системы.
Возможности:
1. использование макрокоманд
2. повторное использование пусков кода
3. наличие автоматизированных инструментов разработки
4. привлечение будущих пользователей к процессу разработки
Преимущества:
1. низкая стоимость
2. высокое качество
3. лучшее удовлетворение требованию юзеров
4. меньшая стоимость сопровождения
Все приемы быстрой разработки служат однозначно для обеспечения качества и низкой стоимости разработанного проекта.
К числу таких приемов относятся:
1. разработка проекта итерациями
2. необязательность завершения работ на любом из этапов ЖЦ
3. обязательное привлечение пользователей к процессу разработки
4. параллельность выполнения работ
5. повторное использование частей проекта
6. обязательное использование СС
7. использование элементов прототипной модели
8. тестирование проекта, одновременно с разработкой нескольких версий проекта
9. использование в разработке различных генераторов кода
Для реализации проектирования часто используют инструментальные средства, которые позволяют быстро преобразовать прототип модели в действующую версию.
Такие инструментальные средства подразделяются на два класса:
- инструменты быстрой разработки Developer
- интегрированные средства быстрой разработки приложений Builder
К инструментам этих классов относят ПО, позволяющее генерировать компоненты приложений:
- генераторы таблиц БД
- генераторы форм ввода-вывода
- генераторы запросов
- генераторы отчетов
- генераторы меню
Такие генераторы существуют во всех СУБД как персональные, так и в окружении промышленных серверов. Отличительной чертой класса Builder является то, что инструменты данного типа легко интегрируются в СС. Таким образом они образуют единую среду быстрой разработки приложений.
ЖЦ создания системы на основе RAW технологий предполагает формирование технического задания и декомпозиции системы с дальнейшей независимой разработкой подсистем с последующей сборкой, тестированием и внедрением системы.
1 – разработка технического задания
2 – разбиение системы на подсистемы
3 – независимая разработка подсистем по методологии RAW
4 – сборка и тестирование
5 – внедрение
Накопленный опыт использования RAW технологий позволил выявить 2 варианта организации технологического процесса проектирования на основе использования систем прототипов. В первом варианте создаются системы прототипов использования для лучшей спецификации требований системы. После окончания разработки системы сам прототип оказывается не нужным. В этом варианте проектирования традиционно разрабатывается постановка задачи, документация которой является спецификацией системы прототипов. После демонстрации пользователю и доработки разрабатывается новая постановка задачи, которая является основой создания действующей системы. Технологическая сеть данного варианта проектирования выглядит следующим образом:
Д1 – Техническое задание на разработку
Д2 – описание ПО
Д3 – постановка задачи
Д4 – результаты работы приложений
Д5 – уточненные требования к системе
Д6 – новая постановка задачи
U1 – универсум средств быстрой разработки приложений
U2 – множество средств генерации кода
G1 – приложение прототип
G2 – доработанный прототип
G3 – готовое приложение
П1 – разработка постановки задачи
П2 – разработка системы прототипов
П3 – демонстрация работы прототипов
П4 – доработка системы прототипов
П5 – разработка новой постановки задач
П6 – разработка приложений
Основным недостатком данного варианта проектирования является не эффективное использование системы прототипа, т.к. прототипы не используются в дальнейшей разработке системы после того, как выполнили свою задачу.
Второй вариант предполагает итерационное развитие системы прототипа в готовый для эксплуатации программный продукт. Итерации разработки системы прототипа включают создание и модификацию системы прототипа, её демонстрацию пользователю, разработку новых спецификаций в системе, пока не будет создана готовая система. Технологическая сеть проектирования выглядит следующим образом.
Д1 – Техническое задание на разработку
Д2 – описание ПО
Д4 – результаты работы приложений
Д5 – уточненные требования к системе
Д6 – новая спецификация и требования
Д7 – необходимая документация
U1 – множество тестирования
G1 – приложение прототип
G2 – доработанный прототип
G3 – готовое приложение
П1 – разработка системы прототипов
П2 – демонстрация работы прототипов
П3 – доработка системы прототипов
П4 – разработка новой спецификации и требований
П5 – документирование готовых приложений
Итерационное использование прототипного подхода обеспечивает экономию ресурсов на проектирование и резкое сокращение времени на разработку и внедрение в эксплуатацию системы.
Основное достоинство прототипной технологии является уменьшение объема доработок системы при её внедрении, которая для традиционных методов проектирования соразмерен с затратами на первоначальную реализацию.
Межсистемные интерфейсы
Дата добавления: 2018-04-15; просмотров: 679; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!