Разработка программного обеспечения (Software Engineering)

Содержание

Слайд 2

Архитектура – это базовая организация системы, которая описывает связи между компонентами

Архитектура – это базовая организация системы, которая описывает связи между компонентами

этой системы (и внешней средой), а также определяет принципы её проектирования и развития». 
Архитектурным проектированием называют первый этап процесса проектирования, на котором определяются подсистемы, а также структура управления и взаимодействия подсистем.
Слайд 3

Архитектурное проектирование Подсистема — это система, операции (методы) которой не зависят

Архитектурное проектирование

Подсистема — это система, операции (методы) которой не зависят

от сервисов, предоставляемых другими подсистемами. Подсистемы состоят из модулей и имеют определенные интерфейсы, с помощью которых взаимодействуют с другими подсистемами. Подсистема может разрабатываться независимо от остальных подсистем.
Модуль — это обычно компонент системы, который предоставляет один или несколько сервисов для других модулей. Модуль может использовать сервисы, поддерживаемые другими модулями. Как правило, модуль никогда не рассматривается как независимая система. Модули обычно состоят из ряда других, более простых компонентов.
Слайд 4

Архитектурное проектирование Этапы, общие для всех процессов архитектурного проектирования: Структурирование системы.

Архитектурное проектирование

Этапы, общие для всех процессов архитектурного проектирования:
Структурирование системы. Программная система

структурируется в виде совокупности относительно независимых подсистем, определяются взаимодействия между подсистемами.
Моделирование управления. Разрабатывается базовая модель управления взаимоотношениями между частями системы.
Модульная декомпозиция. Каждая определенная на первом этапе подсистема разбивается на отдельные модули. Здесь определяются типы модулей и типы их взаимосвязей.
Слайд 5

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

Архитектурное проектирование

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

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

Архитектурное проектирование Как правило, разрабатывается четыре архитектурные модели: Статическая структурная модель,

Архитектурное проектирование

Как правило, разрабатывается четыре архитектурные модели:
Статическая структурная модель, в

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

Архитектура программной системы охватывает не только ее структурные и поведенческие аспекты,

Архитектура программной системы охватывает не только ее структурные и поведенческие аспекты,

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

Архитектурное проектирование Модели архитектуры могут зависеть от нефункциональных системных требований: Производительность.

Архитектурное проектирование

Модели архитектуры могут зависеть от нефункциональных системных требований:
Производительность. Если

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

Архитектурное проектирование Надежность. В этом случае следует разработать архитектуру с включением

Архитектурное проектирование

Надежность. В этом случае следует разработать архитектуру с включением

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

Архитектурное проектирование На первом этапе процесса проектирования архитектуры система разбивается на

Архитектурное проектирование

На первом этапе процесса проектирования архитектуры система разбивается на несколько

взаимодействующих подсистем. На самом абстрактном уровне архитектуру системы можно изобразить графически с помощью схемы, в которой отдельные подсистемы представлены отдельными блоками. Если подсистему также можно разбить на несколько частей, на диаграмме эти части изображаются прямоугольниками внутри больших блоков. Потоки данных и/или потоки управления между подсистемами обозначается стрелками. Такая блок-схема дает общее представление о структуре системы.

схема системы управления автоматической упаковкой.

Слайд 11

Структурная схема системы защиты сайта

Структурная схема системы защиты сайта

Слайд 12

Архитектурное проектирование: структурирование системы Для того чтобы подсистемы, составляющие систему, работали

Архитектурное проектирование: структурирование системы

Для того чтобы подсистемы, составляющие систему, работали

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

Совместное использование больших объемов данных эффективно, поскольку не требуется передавать данные

Совместное использование больших объемов данных эффективно, поскольку не требуется передавать

данные из одной подсистемы в другие.
Подсистемы должны быть согласованы с моделью репозитория данных. Это всегда приводит к необходимости компромисса между требованиями, предъявляемыми к каждой подсистеме. Компромиссное решение может понизить их производительность. Если форматы данных новых подсистем не подходят под согласованную модель представления данных, интегрировать такие подсистемы сложно или невозможно.
Подсистемам, в которых создаются данные, не нужно знать, как эти данные используются в других подсистемах.

Модель репозитория

Архитектурное проектирование: структурирование системы

Слайд 14

Поскольку в соответствии с согласованной моделью данных генерируются большие объемы информации,

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

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

Архитектурное проектирование: структурирование системы

Слайд 15

Модель совместного использования репозитория прозрачна: если новые подсистемы совместимы с согласованной

Модель совместного использования репозитория прозрачна: если новые подсистемы совместимы с

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

Архитектурное проектирование: структурирование системы

Архитектура интегрированного набора CASE-средcmв

Слайд 16

Модель клиент/сервер Модель архитектуры клиент/сервер — это модель распределенной системы, в

Модель клиент/сервер

Модель архитектуры клиент/сервер — это модель распределенной системы, в

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

Архитектурное проектирование: структурирование системы

Слайд 17

Архитектурное проектирование: структурирование системы Архитектура библиотечной системы фильмов и фотографий Наиболее

Архитектурное проектирование: структурирование системы

Архитектура библиотечной системы фильмов и фотографий

Наиболее

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

С использованием клиент-серверной модели созданы многие приложения для работы с базами

С использованием клиент-серверной модели созданы многие приложения для работы с базами

данных, электронной почтой и для доступа к веб-ресурсам.
Особенности:
– Высокая безопасность. Все данные хранятся на сервере, обеспечивающем больший уровень безопасности, нежели отдельный клиент.
– Централизованный доступ к данным. Так как данные хранятся только на сервере, ими легко управлять (например, обеспечить обновление).
– Устойчивость и лёгкость сопровождения. Роль сервера могут выполнять несколько физических компьютеров, объединённых в сеть. Благодаря этому клиент не замечает сбоев или замены отдельного серверного компьютера.
варианты клиент-серверной модели: Клиент-очередь-клиент (client-queue-client или passive queue) сервер исполняет роль очереди для данных клиентов. То есть, клиенты использую сервер только для обмена данными между собой. Пиринговые приложения (peer-to-peer applica-tion) – это вариация системы клиент-очередь-клиент, в которой любой клиент может играть роль сервера. Сервера приложений (application server) служат для размещения и выполнения программ, которыми управляет клиент.
Слайд 19

Модель архитектуры абстрактной машины (иногда называемая многоуровневой моделью) моделирует взаимодействие подсистем.

Модель архитектуры абстрактной машины (иногда называемая многоуровневой моделью) моделирует взаимодействие подсистем.

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

Архитектурное проектирование: структурирование системы

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

Слайд 20

основные принципы 1. Проектирование чётко устанавливает разграничение функций между уровнями. 2.

основные принципы
1. Проектирование чётко устанавливает разграничение функций между уровнями.
2. Нижние

уровни независимы от верхних уровней.
3. Верхние уровни вызывают функции нижних уровней, но при этом взаи-модействуют только соседние уровни иерархии.
преимущества:
– Изоляция. Разработка и обновление ПО могут быть изолированы рамками одного уровня.
– Производительность. Распределение уровней на отдельные физические компьютеры повышает производительность и отказоустойчивость.
– Тестируемость. Уровни допускают независимое тестирование
Слайд 21

Уровень представления (presentation layer) ответственен за взаимодействие с пользователем, ввод и

Уровень представления (presentation layer) ответственен за взаимодействие с пользователем, ввод и

вывод информации.
Бизнес-уровень или уровень бизнес-логики (business logic layer) обрабатывает информацию, реализуя конкретные бизнес-правила.
Уровень доступа к данным (data access layer) обеспечивает загрузку и со-хранение информации, используя источник данных (файл, база данных) или внешний сервис.

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

Слайд 22

Компонентная архитектура компонент (component) - программный объект, спроектированный так, чтобы удовлетворять

Компонентная архитектура
компонент (component) - программный объект, спроектированный так, чтобы удовлетворять

следующим требованиям:
1. Компонент допускает повторное использование в различных системах.
2. Компонент не хранит информации, специфичной для конкретного ПО, в котором он используется.
3. Допускается создание новых компонентов на основе существующих.
4. Компонент имеет известный интерфейс для взаимодействия, но скрывает детали своей внутренней реализации.
5. Компоненты проектируются так, чтобы иметь минимальные зависимости от других компонентов.
Типичным примером компонентов являются элементы пользовательского интерфейса (элементы управления).
Слайд 23

преимущества: – Лёгкость развёртывания. Когда для компонента доступна новая версия, старая

преимущества:
– Лёгкость развёртывания. Когда для компонента доступна новая версия, старая

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

Архитектурное проектирование: модели управления В структурных моделях нет (и не должно

Архитектурное проектирование: модели управления

В структурных моделях нет (и не должно быть)

никакой информации по управлению. Однако разработчик архитектуры должен организовать подсистемы согласно некоторой модели управления, которая дополняла бы имеющуюся модель структуры. В моделях управления на уровне архитектуры проектируется поток управления между подсистемами.
Можно выделить два основных типа управления:
Централизованное управление. Одна из подсистем полностью отвечает за управление, запускает и завершает работу остальных подсистем.
Управление, основанное на событиях. Здесь вместо одной подсистемы, ответственной за управление, на внешние события может отвечать любая подсистема. События, на которые реагирует система, могут происходить либо в других подсистемах, либо во внешнем окружении системы.
Слайд 25

Архитектурное проектирование: модели управления Централизованное управление В модели централизованного управления одна

Архитектурное проектирование: модели управления

Централизованное управление

В модели централизованного управления одна из

систем назначается главной и управляет работой других подсистем. Такие модели можно разбить на два класса:
Модель вызова-возврата. Это известная модель организации вызова программных процедур "сверху вниз", в которой управление начинается на вершине иерархии процедур и через вызовы передается на более нижние уровни иерархии. Данная модель применима только в последовательных системах.
Модель диспетчера. Применяется в параллельных системах. Один системный компонент назначается диспетчером и управляет запуском, завершением и координированием других процессов системы. Процесс может протекать параллельно с другими процессами. Модель такого типа применима также в последовательных системах, где управляющая программа вызывает отдельные подсистемы в зависимости от значений некоторых переменных состояния.
Слайд 26

Архитектурное проектирование: модели управления Централизованное управление Модель вызова-возврата

Архитектурное проектирование: модели управления

Централизованное управление

Модель вызова-возврата

Слайд 27

Архитектурное проектирование: модели управления Централизованное управление (продолжение) Модель диспетчера для системы реального времени

Архитектурное проектирование: модели управления

Централизованное управление (продолжение)

Модель диспетчера для системы реального

времени
Слайд 28

Архитектурное проектирование: модели управления Управление, основанное на событиях В моделях централизованного

Архитектурное проектирование: модели управления

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

В моделях централизованного управления,

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

Архитектурное проектирование: модели управления Модели передачи сообщений. В этих моделях событие

Архитектурное проектирование: модели управления

Модели передачи сообщений. В этих моделях событие представляет

собой передачу сообщения всем подсистемам. Любая подсистема, которая обрабатывает данное событие, отвечает на него.
)

Модель управления, основанная на передаче сообщений

Слайд 30

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

Архитектурное проектирование: модели управления

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

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

Модель управления, основанная на прерываниях

Слайд 31

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

Архитектурное проектирование: модульная декомпозиция

После этапа разработки системной структуры в процессе проектирования

следует этап декомпозиции подсистем на модули.
Распространены две модели, используемые на этапе модульной декомпозиции подсистем:
Объектно-ориентированная модель. Система состоит из набора взаимодействующих объектов.
Модель потоков данных. Система состоит из функциональных модулей, которые получают на входе данные и преобразуют их некоторым образом в выходные данные. Такой подход часто называется конвейерным.
В объектно-ориентированной модели модули представляют собой объекты с собственными состояниями и определенными операциями над этими состояниями. В модели потоков данных модули выполняют функциональные преобразования.
Слайд 32

Архитектурное проектирование: модульная декомпозиция Объектные модели Объектно-ориентированная архитектурная модель структурирует систему

Архитектурное проектирование: модульная декомпозиция

Объектные модели

Объектно-ориентированная архитектурная модель структурирует систему в

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

Объектная модель системы обработки счетов

Слайд 33

Главные принципы объектно-ориентированной архитектуры, в целом, соответствуют принципам ООП: 1. Использование

Главные принципы объектно-ориентированной архитектуры, в целом, соответствуют принципам ООП:
1. Использование

абстракций (базовые классы, интерфейсы) для сокрытия деталей конкретных реализаций.
2. Использование агрегирования – построение сложных объектов, включа-ющих простые объекты.
3. Инкапсуляция, Наследование, Полиморфизм.
4. Уменьшение связанности объектов друг с другом благодаря применению интерфейсов и объектных фабрик.
Преимуществами объектно-ориентированной архитектуры являются высо-кая тестируемость систем, расширяемость, способность к повторному использованию.
Слайд 34

Вариация объектно-ориентированной архитектуры - проектирование, основывающееся на домене1 (domain-driven design, DDDПри

Вариация объектно-ориентированной архитектуры - проектирование, основывающееся на домене1 (domain-driven design, DDDПри

создании уровня домена DDD сосредотачивается на следующих объектах:
1. Сущности (entities). Основные объекты модели, обладающие уникальным идентификатором. Например, при разработке системы интернет-магазина сущ-ностями могут быть покупатель, заказ, товар.
2. Объекты-значения (value objects). Объекты, которые представляют сгруп-пированный набор атрибутов. Например, адрес, состоящий из города, улицы, но-мера дома. Объекты-значения используются как части сущностей и не обладают уникальным идентификатором.
3. Агрегаторы (aggregates). Это особый вид сущностей, содержащий вложенные сущности. Например, заказ может содержать список заказываемых товаров. Агрегируемые сущности не имеют самостоятельного значения и должны быть доступны только через агрегатор.
4. Хранилища (repositories). Методы или классы, используемые для сохранения сущностей во внешних источниках данных и для получения сущностей из источников.
5. Фабрики (factories). Методы или классы, используемые для создания но-вых сущностей и агрегаторов.
Слайд 35

Архитектурное проектирование: модульная декомпозиция Модели потоков данных Данные проходят через последовательность

Архитектурное проектирование: модульная декомпозиция

Модели потоков данных

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

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

Модель потоков данных для системы обработки счетов

Слайд 36

В основе модели лежат понятия внешней сущности, процесса, хранилища (накопителя) данных

В основе модели лежат понятия внешней сущности, процесса, хранилища (накопителя) данных

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

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

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

способы помещения, извлечения и хранения для такого устройства не детализируют. Физически это может быть база данных, файл, таблица в оперативной памяти, картотека на бумаге и т. п.
Поток данных — процесс передачи некоторой информации от источника к приемнику.
сетевая модель хранения/обработки информации
Слайд 38

Для изображения диаграмм потоков данных традиционно используют два вида нотаций: нотации Йордана и Гейна-Сарсона

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

Йордана и Гейна-Сарсона
Слайд 39

Пример потока данных (нотация Гейна-Сарсона) Над линией потока, направление которого обозначают

Пример потока данных (нотация Гейна-Сарсона)

Над линией потока, направление которого обозначают стрелкой,

указывают, какая конкретно информация в данном случае передается
Слайд 40

Построение иерархии диаграмм потоков данных начинают с диаграммы особого вида -

Построение иерархии диаграмм потоков данных начинают с диаграммы особого вида -

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

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

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

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

Решение о завершении детализации процесса принимают в следующих случаях: процесс взаимодействует

Решение о завершении детализации процесса принимают в следующих случаях:
процесс взаимодействует с

2-3-мя потоками данных;
возможно описание процесса последовательным алгоритмом;
процесс выполняет единственную логическую функцию преобразования входной информации в выходную.
На недетализируемые процессы составляют спецификации, которые должны содержать описание логики (функций) данного процесса.
Такое описание может, выполняться: на естественном языке, с применением структурированного естественного языка (псевдокодов), с применением таблиц и деревьев решений, в виде схем алгоритмов, и т.д.
Слайд 43

Полная спецификация процессов включает описание структур данных, используемых как при передаче

Полная спецификация процессов включает описание структур данных, используемых как при передаче

информации в потоке, так и при хранении в накопителе.
Описываемые структуры данных могут содержать альтернативы, условные вхождения и итерации.
Условное вхождение означает, что соответствующие элементы данных в структуре могут отсутствовать.
Альтернатива означает, что в структуру может входить один из перечисленных элементов.
Итерация означает, что элемент может повторяться некоторое количество раз
Под согласованностью модели в данном случае понимают выполнение для всех потоков данных правила сохранения информации: все поступающие куда-либо данные должны быть считаны и записаны
Слайд 44

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

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

Слайд 45

Слайд 46

Архитектурное проектирование: проблемно-зависимые архитектуры Наряду с основными моделями, используются архитектурные модели,

Архитектурное проектирование: проблемно-зависимые архитектуры

Наряду с основными моделями, используются архитектурные модели,

характерные для конкретной предметной области приложения. Эти модели называются проблемно-зависимыми архитектурами.
Можно выделить два типа проблемно-зависимых архитектурных моделей:
Модели классов систем. Отображают классы реальных систем, вобрав в себя основные характеристики этих классов. Как правило, архитектурные модели классов встречаются в системах реального времени, например в системах сбора данных, мониторинга и т.д.
Базовые модели. Более абстрактны и предоставляют разработчикам информацию по общей структуре какого-либо типа систем.
Слайд 47

Архитектурное проектирование: проблемно-зависимые архитектуры Модели классов систем Модель компилятора наиболее известный

Архитектурное проектирование: проблемно-зависимые архитектуры

Модели классов систем

Модель компилятора наиболее известный

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

Архитектурное проектирование: проблемно-зависимые архитектуры Модели классов систем (продолжение) Однако такие модели

Архитектурное проектирование: проблемно-зависимые архитектуры

Модели классов систем (продолжение)

Однако такие модели оказываются

менее эффективными, если компилятор интегрирован с другими языковыми средствами, например системой редактирования структур, интерактивным отладчиком, программой подготовки печатных документов и т.п. В этом случае компоненты системы можно организовать в соответствии с моделью репозитория.
- Предыдущая
Angry birds. Mystery box
Следующая -
Ребусы по сказкам. Попробуем отгадать сказочного героя

Похожие презентации

История вычислительной техники
Организация ввода и вывода данных при разработке программ в языке Паскаль
Создание архивов с помощью программы WinRAR
Автоматизация компрессорной станции
Коды и кодирование
Аппаратное обеспечение ПК (Hardware)
Объектные привилегии
Исключительные ситуации
Разбор задач 3-го этапа республиканской олимпиады по информатике 2018 года
C# Start
Формирование бюджетных заявок с применением нормативного метода расчета расходов
Презентация на тему Основная позиция пальцев на клавиатуре
Персональные данные
Процессы программной инженерии Реализация и изменение процессов (Часть 2)
1С:Управление автотранспортом Проф. Презентация отраслевого решения
Двоичное кодирование звука. Представление видеоинформации
Внешняя память
Формально об инъекциях. Модель инъекции. Критерий защищённости от атак инъекций
Кодування і декодування повідомлень. (Урок 6)
Беспроводные сети
Информатика в системе образования. Человек осваивал вещество, чтобы жить, осваивал энергию, чтобы жить цивилизованно, осваивает и
Автоматизация информационно-библиотечной деятельности
Учитель информатики Трифонова Татьяна Викторовна г.Октябрьск ТЕКСТОВЫЕ РЕДАКТОРЫ И ПРОЦЕССОРЫ 10-11 кл
Программирование на языке Паскаль
Огляд середовища VISUAL STUDIO та способи створення проектів
Электронные таблицы
Регистрации в программе Основы здорового питания
Программная модель микропроцессора INTEL 8080, регистры, форматы и системы команд, методы адресации
Вы можете прислать нам Вашу презентацию и мы опубликуем ее на сайте.
Обратная связь
Для правообладателей
Email: Нажмите что бы посмотреть