Процессы проектирования.

Проектирование программного обеспечения состоит из ряда этапов. Точное выполнение этих этапов позволяет создавать достаточно надёжные программное продукты.

Требования, цели

Проекты: управляемые пользователем, контролируемые пользователем, независимые от пользователя.

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

Оглавление – описание иерархии задач со ссылками на диаграммы. Диаграммы содержат вход (слева), обработку (по центру), выход (справа).

Цели – конкретные ориентиры программного продукта.

Типичные ошибки:

- неявное формулирование целей;

- составление наброска без учёта всех целей;

- есть конфликты при формулировании целей (должны быть компромиссы);

Цели ПО могут быть разбиты на 10 групп:

- общность – число, мощность, область действия пользовательских функций;

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

- адаптируемость – мера лёгкости расширения;

- удобство сопровождения – мера затрат времени и средств на исправление ошибок;

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

-документация;

- стоимость продукта;

- календарный план;

- эффективность (производительность);

- надёжность (средства повышения надёжности снижают эффективность).

Внешнее проектирование.

Составляется детальное описание каждой функции пользователя:

- описание входных данных;

- описание выходных данных и их функциональной связи с входными;

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

- характеристики надёжности;

- эффективность (по расходу памяти и по быстродействию);

- замечания по программированию.

Проверка:

- контроль «плюс-минус один» – эскизный проект контролируется исполнителями предыдущего и следующего этапов;

- контроль со стороны пользователя;

- таблицы решений;

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

Также при структурном подходе на этапе внешнего проектирования составляют следующие схемы.

Диаграммы потоков данных (Data Flow Diagrams).

Внешняя сущность – материальный объект или физическое лицо, выступающие в качестве источника или приёмника информации.

Процесс – преобразование входных потоков данных в выходные.

Хранилище данных – абстрактное устройство для хранения информации.

Поток данных – процесс передачи информации.

Нотация Гейна-Сарсона.

Диаграммы «сущность-связь» (Entity-Relationship Diagrams).

(см. структуры данных)

Диаграммы переходов состояний (State Transition Diagrams).

Функциональные диаграммы.

(слева – вход, справа – выход, сверху – управление, снизу – механизм)

Описание структур данных

Абстрактные структуры данных.

– элементы не связаны между собой (множества, кортежи);

– структуры с неявными связями элементов: векторы, матрицы, строки.

– структуры с явной связью элементов: графы.

Иерархические модели.

– диаграммы Джексона;

– скобочные диаграммы Ора.

Сетевые модели (почти реляционные).

Нотация Баркера.

Проектирование архитектуры

Архитектура программного обеспечения – это представление, которое даёт информацию о компонентах составляющих систему, о взаимосвязях между этими компонентами и правилах, регламентирующих эти взаимосвязи.

Архитектура показывает, как система выглядит «со стороны». Требуется только для больших проектов. Примеры: автономная программа (вырожденная архитектура), комплекс параллельно выполняющихся программ, слоистая (вертикальное взаимодействие) и т.д.

Проектирование модульной структуры.

Модуль

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

В структурном программировании:

– одна функция;

– набор функций, объединённых общими данными и/или назначением и собранные (как правило) в один файл;

В объектно-ориентированном программировании:

– класс;

– метод класса;

– несколько классов, объединённых общими данными и/или назначением и собранные (как правило) в один файл;

Хороший модуль снаружи проще, чем внутри. Хороший модуль проще использовать, чем построить.

Свойства.

1. Прочность – мера внутренних связей. Исторически сложились различные уровни прочности:

- по совпадению – между его элементами нет осмысленных связей, может возникать при «модулизации» программы;

- по логике – содержит набор независимо вызываемых связанных функций;

- по классу – последовательное выполнение набора несвязанных функций (инициализация, завершение);

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

- коммуникационно-прочный – процедурная прочность + связи по данным;

- функционально прочный – выполняет одну «элементарную» (с функциональной ТЗ) функцию;

- информационно прочный – выполняет несколько функций (со своими точками входа), работающих на единой структуре данных).

Для функции или метода рекомендуется функциональная прочность, для класса – информационная.

2. Сцепление – мера связи по данным.

- по содержимому – один модуль ссылается на данные другого;

- по общей памяти – ссылаются на единую структуру данных;

- по внешним данным – совместно используют глобальные простые типы данных;

- по управлению – один модуль запускает фрагменты другого;

- по формату – передача структуры данных;

- по данным – передача неструктурированных данных.

Другие свойства:

- предсказуемость – независимость от предыстории;

- структура принятия решений – влияние только на подчинённые модули;