Построение диаграмм видов деятельности.

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

Диаграмма видов деятельности UML представляет собой блок-схему, в которой точками принятия решений и переходов описывается последовательность шагов.

Точки принятия решений изображаются двумя способами.

 

47. Структура UML.

UML представляет собой универсальную структуру, с помощью элементов которой в процессе проектирования можно ясно представить любую систему и способы ее разработки.

UML имеет четырехуровневую структуру, определяемую степенью обобщения элементов:

уровень пользовательских объектов (имеется в виду пользователь UML) – нижний (наиболее частный) уровень предназначен для описания конкретной предметной области;

уровень модели – предназначен для работы с классами. На этом уровне выполняются начальные стадии анализа – работа с экспертом или с клиентом для изучения предметной области и работа с потенциальным системным пользователем для выявления прецедентов, которые войдут в систему;

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

уровень моделирования метамодели – определения способов описания классов, прецедентов, компонентов и других элементов UML.Основой построения структуры UML является уровень метамодели.

 

 

Методика быстрого проектирования GRAPPLE.

Для решения сложной и многогранной задачи структурирования процесса разработки можно предложить принципы быстрого проектирования приложений — GRAPPLE (Guidelines for Rapid APPLication Engineering).

Структура GRAPPLE

GRAPPLE состоит из пяти сегментов. Каждый сегмент, в свою очередь, состоит из нескольких операций, выполнение которых завершается результатом (продуктом). Сегменты GRAPPLE имеют такие названия:

n Формулировка набора требований (Requirements);

n Анализ (Analysis);

n Проектирование (Design);

n Разработка (Development);

n Развертывание (Deployment).

Эту совокупность сегментов обозначают по начальным буквам английского названия каждого сегмента RADDD или RAD³

Формулировка требований

В сегменте Формулировка требований необходимо предпринять следующие шаги:

n Изучение бизнес-процессов

Путь решения – изучение аналитиком рабочей терминологии клиента.

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

n Анализ предметной области

Путь решения – общение аналитика с клиентом с целью понимании сути предметной области.

Результат – разработчик модели отмечает существительные и представляет их в виде классов.

n Определение взаимосвязанных систем

Путь решения – исследуется от каких систем будет зависеть новая система и какие системы будут зависеть от нее.

Результат – системный инженер строит диаграмму развертывания.

n Выяснение системных требований

Путь решения – проведение семинара по совместной разработке приложения JAD (Joint Application Development).

Результат – создаются диаграммы пакетов.

n Представление результатов клиенту

Путь решения – руководитель проекта представляет результаты клиенту.

Результат – составляется смета расходов.

Анализ

В сегменте Анализ предпринимаются следующие шаги:

n Определение прецедентов системы

Путь решения – анализ прецедентов высокого уровня в рамках семинара разработчиков с пользователями.

Результат – набора диаграмм прецедентов со стереотипами («расширяет» и «включает»).

n Внесение уточнений в диаграммы классов

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

Результат – проводится уточнение диаграммы классов.

n Анализ изменений состояния объектов

Путь решения – уточняется изменения состояний объектов.

Результат – составляется диаграмма состояний.

n Определение взаимодействий между объектами

Путь решения – определяется взаимодействие объектов.

Результат – составляются диаграммы последовательностей и коопераций.

n Анализ уровня интеграции с другими системами

Путь решения – определяется характер интегрирования системы с другими системами.

Результат – составляется диаграмма развертывания и модели данных.

Проектирование

В сегменте Проектирование предпринимаются следующие шаги:

n Построение и уточнение диаграмм объектов

Путь решения – на основе диаграмм классов создаются необходимые диаграммы объектов.

Результат – составляется диаграммы объектов и диаграммы видов деятельности.

n Построение диаграмм компонентов

Путь решения – составляютсядиаграммы компонентов.

Результат – диаграммы компонентов.

n План развертывания

Путь решения – системный инженер начинает планирование развертывания и интеграции системы.

Результат – уточнение диаграммы развертывания.

n Проектирование и создание пользовательского интерфейса

Путь решения – проведение семинара по обсуждению интерфейса.

Результат – экранные формы пользовательского интерфейса.

n Проектирование тестов

Путь решения – написание тестовых программ для средств тестирования.

Результат – тестовые программы.

n Создание технической документации

Путь решения – создание структур высокого уровня для каждого документа.

Результат – документация.

Разработка

В сегменте Разработка выполняется следующее:

n Конструирование и тестирование кода

Путь решения – программисты реализуют систему в коде.

Результат – код программы.

n Подключение пользовательского интерфейса к коду и тестирование

Путь решения – подключение и тестирование кода программы.

Результат – система, оснащенная пользовательским интерфейсом.

n Завершение комплекта документации

Развертывание

В сегменте Развертывание выполняется следующее:

n Планирование средств резервирования и восстановления

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

Результат – восстановление работы системы.

n Установка готовой системы на соответствующих аппаратных средствах

Путь решения – Установка готовой системы на компьютере

Результат – полностью развернутая система.

n Тестирование установленной системы

Путь решения – представитель разработчиков тестирует систему.

Результат – полностью работоспособная система.

 

Етапи розробки ПО

 

Процесс разработки ПО мыслится как последовательное выполнение ряда этапов:

n Определение требований - это наиболее важный этап из всех остальных, поскольку он существенно на них влияет.

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

n Этап проектирования - (программирование "в большом") предполагает решение основных системных вопросов, в числе которых разбиение на подсистемы, разработка сценария работы (в том числе и диалога с пользователем), структуры данных, функциональной структуры и иерархии разбиения на программные модули.

n Этап программирования - (программирование "в малом") имеет целью получение исходных текстов программных модулей на каком-либо алгоритмическом языке (иногда на нескольких) и включает в себя алгоритмизацию, кодирование (запись исходного текста на алгоритмическом языке) и отладку.

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

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

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

 

Зміст типового ТЗ

Выработка технического задания (ТЗ) на проектирование.

Важнейшее требование к ТЗ - это его полнота.

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

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

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

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

Техническое проектирование - это выполнение укрупненного представления всех конструкторских и технологических решений.

Результатом этапа является технический проект.

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

Заключительный этап - изготовление опытного образца.

 

Методи проектування програм

 

Модульный принцип лежит в основе трех основных методов проектирования сложных программ:

• восходящее проектирование (метод "снизу-вверх", bottom-up);

• нисходящее проектирование (метод "сверху-вниз", top-down);

• метод расширения ядра.