Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
АПCОС_ЛЕКЦИИ_10.doc
Скачиваний:
1
Добавлен:
01.04.2025
Размер:
2.46 Mб
Скачать

Эволюция системы – совмещает традиционные этапы: составление программ, их тестирование и интеграцию (комплексирование): Происходит последовательная разработка ряда прототипов.

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

В процессе эволюции выясняется, какое ограничение действительно важно: размер и вес ЭВМ, памяти (космический корабль), размер программы, который связан с ОЗУ.

Стратегия эволюции должна быть следующей:

  • Проектирование, направленное на выполнение заданных функций (всё улучшить);

  • Затем проверка выполнения характеристик ограничений (что при этом ухудшается);

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

Виды изменений при ОО разработке ПП;

  1. Добавление нового класса – расширяет функциональность или гибкость;

  2. Изменение реализации класса (внутренние изменения – поддерживаются инкапсуляцией и определениями функций –членов класса);

  3. Изменение представления класса - изменение его интерфейса пользователя;

  4. Реорганизация структуры класса - (внутренние изменения – поддерживаются инкапсуляцией и внутренней структурой хранения данных);

  5. Изменение интерфейса класса для клиентов.

  • Модификации. Модификация связана с изменением ПО, увеличивает сложность системы, иногда увеличивается связность и нарушается инкапсуляция. При ООП модификация является естественной операцией, происходит развитие «сознания» класса [Т. Сван].

При совершенствовании ПО действуют законы:

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

  • закон непрерывного изменения ПО. Программа, которая реально используется, должна изменяться, иначе она снижает свои потребительские свойства;

В целом разработка моделей ЖЦ CASE – средств и технологий создания ПО превратила проектирование в инженерную дисциплину, обеспечивающую документирование и контроль качества разработки.

Существуют две базовые модели: структурная и ОС.

Кроме логического и физического уровней появились методологии концептуального моделирования

Развиты методы поддержки общих процессов проектирования:

- управление проектом;

- управление качеством;

- репозитарии.

В целом структура ЖЦ является стандартом ISO/IEC 12207. ЖЦ базируется на трёх группах процессов:

1. Основные процессы ЖЦ ПО – это приобретение, поставка, разработка, эксплуатация, сопровождение.

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

3. Организационные процессы: управление проектами, создание инфраструктуры проекта, определение этапов, оценка и улучшение самого ЖЦ, обучение.

Алгоритмическая и ОО декомпозиция

Алгоритмическая декомпозиция используются при структурном проектировании по методу сверху - вниз.

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

В результате создаётся дерево функций.

Рисунок

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

Алгоритм декомпозиции документируют, с помощью диаграммы потоков данных DFD (логическая модель).

ОО декомпозиция

Это альтернативный способ разделения системы. Базируется на выделении понятий (существенных) данной ПО. Понятие сохраняется в словаре данных.

Например, «основной файл (управляющий)», файл изменений «контрольная сумма».

Рисунок

Разработка ПО двумя путями сразу недопустима. ОО программирование (подход) сразу применять лучше, а потом можно перейти и к функциональному. Каждый из них основан на применении ряда средств анализа систем. Для структурного анализа используют диаграммы потоков данных (DFD), диаграммы сущность-связь (ERD) и диаграммы переходов состояний (STD) [3].

В ООП каждый объект характеризуется состоянием, поведением и индивидуальностью [4]. Для логического представления системы применяют диаграммы классов и объектов, однако не исключают и перечисленные средства структурного анализа. Например, средства структурного анализа используют при рассмотрении структуры данных в классе (ERD), при изучении динамических аспектов функционирования системы применяют STD, при разработке архитектуры процессов - DFD. В этом случае диаграммы адаптированы к концепции ООП.

Виды диаграмм при ООП

  1. Диаграмма прецедентов (вариантов использования - Use case).

  2. Диаграмма классов – показывает статическое отношение между классами.

  3. Модель поведения – чаще всего показывают с помощью диаграммы состояний (автомат), диаграмма деятельности.

  4. Модель динамического взаимодействия между объектами. Показывается с помощью диаграммы последовательностей и диаграммы кооперации объектов.

  5. 5 Модель реализации системы – диаграмма распределения (узлов системы).

  6. Диаграмма компонентов, как физических программных единиц (элементов) системы.

Между объектами и структурным подходом есть различия и общее.

Структурный алгоритмический подход

  1. Каскадная модель ЖЦ сверху вниз

  2. Выделение (декомпозиция функций, процессов, алгоритмов).

  3. Внимание на порядок происходящих событий.

  4. Структура данных передаётся между процессами

ОО – подход

  1. ОО спиральная модель ЖЦ (итерации, направленность на модификацию, эволюцию).

  2. Выделение понятий (словарь предметной области, декомпозиция на объекты).

  3. Внимание на взаимодействие объектов.

  4. Функции – операции над объектами.

Преимущества ООП

  1. При ОО подходе для больших проектов объём года меньше. Таким образом отчасти решается проблема избыточности данных за счёт использования общих механизмов и классов.

  2. ОО системы более открыты (за счёт открытых классов), способны более к модернизации (кооперация наследование).

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

  4. ОО подход предполагает эволюционный путь развития, при этом уменьшается риск создания сверхсложных программных систем.

  5. Объектная декомпозиция на этапе анализа ПО позволяет сразу оценить сложность системы.

  6. Структурный подход не позволяет выделить абстракции в виде классов в ООП , для выделения абстракций служат классы.

  7. Структурный подход не обеспечит защиту данных (инкапсуляцию).

  8. Структурный подход представляет меньше средств для параллельной разработки.

  9. При ОО подходе упрощается модернизация за счёт классов.

Базовые понятия в ООП

Понятие объекта

Объект – это осязаемый (видимый) предмет, так кА он имеет физическую природу.

Объект – это нечто, воспринимаемое мышлением или на что направлена деятельность.

Объект – это нечто, имеющее чётко определённые границы по отношению к другим объектам.

Объект обладает состоянием.

Объект проявляет поведение.

Объект обладает индивидуальностью.

Совокупность состояний и поведения определяет общий для объектов класс, под определение которого подходят эти объекты.

Индивидуальность – контрольный набор значений атрибутов, определяющий состояние объекта.

Атрибуты – свойства, характеристики объектов.

Состояние объекта характеризуется перечнем всех возможных свойств объекта.

Перечень свойств:

  1. Статическая составляющая

  2. Динамическая составляющая значения каждой составляющей.

Значение свойств меняется намного быстрее, чем качество свойств.

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

Индивидуальность определяется именем объекта, местом в памяти, значением атрибутов.

Индивидуальность определяется именем объекта, местом в памяти, значением атрибутов.

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

Операция – определённое воздействие одного объекта на другой.

Понятие «Операция» и «Сообщение» в большинстве случаев совпадают.

Операции реализуются методами классов.

Виды операций:

1. конструктор;

2. деструктор;

3. функция типа Get (селектор) – возвращает;

4. функция типа Set (модификатор) – меняет состояние объекта;

5. функция итератор – функция, которая обеспечивает доступ к элементам объекта по частям, в определённой последовательности.

Общедоступные функции, размещённые вне классов, для работы с ними называются утилитой.

Методы и утилиты определяют оболочку поведения объекта, так как охватывают и внутреннее состояние внешнее поведение объекта. Их совокупность называют протоколом объекта.

В зависимости от реализуемого поведения объекты могут быть активными (автономные - обладают собственным автоматом), пассивными (реактивными) могут быть актёрами (выполняют функции активного и пассивного объекта).

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