Монолитно-модульная структура.

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

       Недостаток:

Сложность для понимания, проверки и сопровождения.

 

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

 

Последовательно-модульная структура.

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

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

 

Недостаток: реализуется только для простых программ.

 

Модульно-иерархическая структура.

 

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

 

 

Модульно-хаотическая структура.

 

 

Модули в структуре связаны между собой таким образом, что они не образуют в явном виде ни одну из перечисленных выше структур. Эти программы сложны для проверки и сопровождения. Следует избегать получения таких программ. Такая структура может оказаться допустимой только в системах реального времени с жёсткими объёмно-временными ограничениями.

Технологический цикл конструирования программной системы (ПС): три процесса.

Технологический цикл конструирования программной системы (ПС) вклю-

-чает 3 процесса:

     1.Анализ.

     2.Синтез.

     3.Сопровождение.

Анализ.

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

Синтез.

Отвечают на вопрос каким образом система будет реализовывать предъявляемые к ней требования. Три этапа синтеза:

a) Проектирование;

b) Кодирование;

c) Тестирование.

 

Информационные потоки процесса синтеза программной системы.

 

Модель анализа: Ø Информационная; Ø Функциональная ; Ø Поведенческая .

 

 

Этап проектирования

Этап кодирования

Процедурная разработка

Разработка архитектуры

Разработка данных

Этап тестирования

Процедурные модули

 

 

 

Проверенная и объединённая ПС

 

 

Информационная модель описывает информацию, которую должна обрабатывать ПС.

Функциональная модель определяет перечень функций обработки.

Поведенческая модель фиксирует режимы работы ПС.

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

Разработка архитектуры выделяет основные структурные компоненты и фиксирует связи между ними.

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

На проектирование, кодирование и тестирование приходится более 75% стоимости конструирования ПС. Решение, принимаемое в ходе проектирования, делают его стержневым этапом процесса синтеза.

Особенности этапа проектирования.

Выделяют две ступени:

1. Предварительное.

2. Детальное.

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

1) Идентификацию подсистем;

2) Определение основных принципов управления подсистема-ми, взаимодействие подсистем.

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

Ø I .Структурирование системы (система разбивается на несколько подсистем – независимых программных компонентов. Определяется взаимодействие подсистем);

Ø II .Моделирование управления.(Определяется модель связей управления между подсистемами);

Ø III .Декомпозиция подсистем на модули.(Определение типов модулей и межмодульных соединений)

Информационные связи процесса проектирования.

Предварительное проектирование

Детальное проектирование

Требования                                  Архитектура                                   Структура

                                                         программ и                                     данных и

                                                           данных                                          алгоритм

Интерфейсное проектирование

                                                                                                       программ   

     Характеристики , формы

       человеко-машинного

           взаимодействия 

на выход

I.Структурирование систем.

 

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

I. Модель хранилища данных.

Редактор проекта

Генератор кода

Хранилище данных проекта

Редактор программы

Анализатор проекта

Проектный транслятор

 

В данной модели подсистемы разделяют данные находящиеся в общей памяти. Как правило данные образуют базы данных.Предусматривается система управления этой базой.

II.Модель клиент – сервер.

 

Клиент 1

Клиент 3

Клиент N

Клиент 2

Видео- -сервер

Сервер каталога

Сервер гипер-текстов

Сеть (Протокол взаимодействий TCP/IP)

                                                                                                                                                                            

 

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

 

 

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

III.

Графический интерфейс пользователя

Трёхуровневая модель. (Развитие модели клиент – сервер)                                                                          

Бизнес - логика

Реляционная СУБД

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                Уровень графического интерфейса запускается на машине клиента.

Бизнес – логику образуют модули осуществляющие функциональные обязанности подсистемы. Этот уровень запускается на сервере приложения.

Реляционная СУБД хранит данные необходимые уровню бизнес – логики. Этот уровень запускается на втором уровне - сервере базы данных(БД).

Преимущества трёхуровневой модели:

Ø Упрощается такая модификация уровня, которая не влияет на другие уровни;

Ø Отделение прикладных функций от функций управления БД,

              упрощает оптимизацию всей системы.

IV. Модель абстрактной машины.

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

Управление версиями

Управление объектом

 

 

 

СУБД

 

ОС

                                                                                                                                                                         

                                                                                                                                                                     

 

 

II.Моделирование управления.

 

Известно два типа моделей управления:

I. Модель централизованного управления.

II. Модель событийного управления.

I. В этой модели одна подсистема выделяется как системный контроллер. Ёе обязанности – руководить работой других систем.

            Две разновидности:

Ø Модель вызов – возврат.

Главная программа

 

 

 

Подпрограмма 2

Подпрограмма 1

 

Подпрограмма 2.1

Подпрограмма 1.2

Подпрограмма 1.1.1

Подпрограмма 1.1

                                                                                                                                                      

 

 

Ø Модель менеджера. Она используется в системах параллельной обработки.

 

Процессы- -датчики

Процессы- -исполнители

 

 

Процессы- -обработчики отказов

Вычислительные процессы

Системный контроллер

                                                                                                                                                      

 

 

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

 

II. Здесь системой управляют внешние события. Две разновидности:

Ø Широковещательная модель. Каждая подсистема уведомляет обработчика о своём интересе к конкретным событиям. Когда событие происходит, обработчик пересылает его подсистеме, которая может обработать это событие. Функции управления в обработчик не встраиваются.

 

Подсистема 2

Подсистема N

Подсистема 1

Обработчик событий и сообщений

                                                                                         

 

 

Ø Модель управляемая прерываниями. Здесь все прерывания разбиты

        на группы – Типы прерываний, которые образуют вектор прерываний.

        Для каждого типа прерывания есть свой обработчик.Каждый обработ-

        чик реагирует на свой тип прерывания и запускает свой процесс.                  

 

 

                                 Прерывания

 

                                                                                                               

                              Вектор          В

                                  

Процесс 1

Обработчик 1

Вектор прерывания                                                                                          

 

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

Известны два типа моделей модульной декомпозиции:

1) Модель потока данных(в основе лежит разбиение по функциям);

2) Модель объектов.(Эта модель основана на слабо сцеплённых единицах имеющих собственные наборы данных состояния и наборы операций).

Выбор типа декомпозиции зависит от сложности разбиваемой подсисте-мы.

 

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

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

 

X – Проблема

C(X) – Сложность решения проблемы X

T(X) – Затраты на решение X

Пусть p1,p2 – Проблемы

C(p1) > C(p2) => T(p1) > T(p2)

C(p1+p2) > C(p1) + C(p2) -из практики решения проблем человека

T(p1+p2) > T(p1) + T(p2)

Таким образом сложную проблему легче решить разделив её на управляемые части. Это аргумент в пользу модульности. В данном случае не учитываются затраты на межмодульный интерфейс.

            

 

          Стоимость

 

                                                                                                         Стоимость

                                          Общая стоимость                           интерфейса

                                                                                                                                                                      

 

 

 

                                                                                          Стоимость                                        

                                                                                          одного модуля

                    

                                                                    Количество

                 Область min стоимости            модулей

 

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

1) Снаружи он проще чем внутри;

2) Его проще использовать чем построить.

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: