Понятие жизненного цикла (ЖЦ). Основные, вспомогательные и организационные процессы

Этап анализа требований включает в себя:

1. Формулировка (установление) требований.
2. Спецификация требований к программному продукту.

 

Объектный анализ

Основное внимание – определению  и описанию объектов или понятий  в терминах предметной области. В результате составляется концептуальная модель.

Необходимые, но недостаточные результаты анализа:

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

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

 

Тип	Описание
1. Модели системного окружения	Определяет границы системы
2. Поведенческие модели Модели потоков данных Модели конечных автоматов	Описывают общее поведение системы
3. Модели данных	Показывает структуру данных, их атрибуты и отношения между ними. Используется при проектировании баз данных.
4. Объектные модели Модели наследования Модели агрегирования объектов Моделирование поведения объектов (диаграммы взаимодействия)	Естественный способ отображения  реально существующих объектов, которые находятся под управлением системы. Могут использоваться как для представления данных, так и для процессов их обработки.

 

Проектирование (предварительное, детальное, интерфейсное). Фазы проектирования. Типовая  структура распределения проектных работ.

Создается структура будущей программой системы. Фазы проектирования:

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

 

Типовая структура распределения проектных работ:

Две ступени проектирования:

• предварительное (архитектурный уровень)
• детальное (алгоритмический уровень).

Часто выделяют интерфейсное проектирование, цель которого – сформировать графический интерфейс пользователя (GUI).

 

Предварительное проектирование обеспечивает:

• идентификацию подсистем
• определение основных принципов управления подсистемами и их взаимодействия

Три типа деятельности:

1. Структурирование системы. Разбить на несколько подсистем (независимых программных компонент), определить их взаимодействие.
2. Моделирование управления. Разработать модель связей управления между частями системы.
3. Декомпозиция подсистем на модули. Разбивается подсистемы на модули, определить типы модулей и межмодульные соединения.

Детализированный проект описывает  каждый модуль. При разработке типичной ИС модули реализуются в виде клиентской компоненты, либо серверной компоненты. Как правило, за первую компоненту отвечают проектировщики прикладной части, вторую должны разрабатывать проектировщики баз данных.

Структурирование системы. Модели системного структурирования.

В процессе структурирования необходимо ответить на вопросы:

1. Какие подсистемы можно выделить из системы?
2. Как подсистемы связать друг с другом?
3. Как будут взаимодействовать подсистемы?

 

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

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

 

Архитектура системы может строиться  в соответствии с определенной архитектурной  моделью.

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

 

Четыре модели системного структурирования:

1. модель хранилища данных (репозитария)
• подсистемы разделяют данные, находящиеся в общей памяти
2. модель клиент-сервер
• система – набор сервисов, которые серверы предоставляют клиентам. Серверы и клиенты отличаются друг от друга. Используется для распределенных систем. Для передачи данных - сетевой протокол.
3. архитектура распределенных объектов
• между серверами и клиентами нет различий; система - набор взаимодействующих объектов, местоположение которых не имеет особого значения. Между поставщиками сервисов и их пользователями не существует различий.
4. модель абстрактной машины
• отображает многослойную систему. Каждый текущий слой реализуется с использованием средств, обеспечиваемых слоем-фундаментом.

Моделирование управления. Типы управления в программных системах.

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

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

1. Централизованное управление – одна подсистема выделяется как системный контроллер. Её обязанности – руководить работой других подсистем.
1. модель вызов-возврат

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

2. модель диспетчера

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

2. Управление, основанное на событиях

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

1. модель передачи сообщений (широковещательная модель)

Каждая подсистема уведомляет обработчика  о своем интересе к конкретным событиям. Когда событие происходит, обработчик посылает его подсистеме, которая может обработать это событие. Алгоритм управления не встроен в обработчик событий и сообщений. Подсистемы определяют, какие события им требуются, а обработчик сообщений и событий следит, чтобы данные события были направлены именно им. Преимущество: относительно простая модернизация систем. Новую подсистему можно интегрировать, регистрируя ее события в обработчике событий. Каждая подсистема может активизировать любую другую подсистему, не зная ее имени или размещения. Подсистемы можно реализовать на разных машинах. Недостаток: подсистемам неизвестно, когда произойдет обработка события. Вполне допустима ситуация, когда разные подсистемы реагируют на одинаковые события (может привести к конфликтам при получении доступа к результатам обработки события).

2. модель, управляемая прерываниями

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

Используется только в жестких СРВ, где требуется немедленная реакция на определенные события. Можно комбинировать эту модель с моделью централизованного управления (центральный диспетчер обрабатывает нормальный ход выполнения системы, а в критических ситуациях используется управление, основанное на прерываниях). Преимущество – мгновенная реакция системы на происходящие события. Недостаток – сложность программирования и аттестации системы.

Декомпозиция  систем на модули. Модульность. Связность. Сцепление.

Следует после этапа разработки системной структуры. Рассматриваются две модели:

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

Модульность

Большая система должна быть расчленена на обозримые модули. Расчленение должно быть выполнено таким образом, чтобы:

• модули были как можно более независимы (критерий сцепления),
• каждый модуль выполнял единственную функцию (критерий связности).

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

Связность

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

• функциональная,
• модуль содержит объекты, предназначенные для выполнения одной и только задачи, например: Расчет заработанной платы, Считывание данных кредитной карты. Имеет одну четко определенную цель, при вызове выполняется только одна задача (полностью, без исполнения любого другого дополнительного действия).
• последовательная,
• объекты модуля охватывают подзадачи, для которых выходные данные одной из подзадач служат входными данными для следующей, например: Открыть файл - Прочитать запись - Закрыть файл.
• информационная,
• модуль содержит объекты, использующие одни и те же входные или выходные данные. Например, выяснить некоторые сведения о книге, зная ее ISBN: название книги, ее автора и цену.
• процедурная,
• объекты модуля включены в различные (возможно несвязные) подзадачи, в которых управление переходит от каждой подзадачи к последующей. Пример: 1. Сделать зарядку 2. Принять душ 3. Сварить кофе 4. Одеться 5. Отправиться на службу Шаги в этом списке связаны только тем, что они происходят в данном порядке в течение конкретного дня.
• временная,
• объекты включены в подзадачи, связанные временем исполнения. Например: 1. Почистить зубы 2. Выключить телевизор 3. Выгнать кота в коридор
• логическая,
• модуль содержит некоторое количество подзадач одного и того же общего вида, они должны обладать одним и только одним интерфейсом с внешним миром; семантика каждого параметра зависит от используемой подзадачи. Чтобы использовать модуль, необходимо выбрать именно ту часть (части), которые требуются. Например: Поехать автомобилем, Поехать поездом, Поплыть на корабле, Полететь на самолете. Все они являются способами перемещения, но для поездки человек должен выбрать конкретный способ перемещения.
• случайная.
• объекты модуля соответствуют подзадачам, незначительно связанным друг с другом. Модуль подобен логически связному модулю, но его объекты не связаны ни потоками данных, ни потоками управления. Подзадачи - не обязательно одной категории. Например: Ремонтировать автомобиль, Пить пиво, Смотреть фильм