Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Анализ правильности проектной информации 1 страница




Виды деятельности при разработки программного изделия.

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

 

Определение видов деятельности.

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

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

В состав этой информации входят:

1) описание требований к ПО.

2) описание проекта ПО.

3) Тексты и загрузочные модули программ.

4) Описание используемых текстов и тестовые данные.

5) Технологическая, техническая и пользовательской документация.

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

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

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

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

 

Лекция 4

-это деятельность пронизывает все этапы жизненного цикла и выливается в этапы: тестирования и верификации программного обеспечения.

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

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

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

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

Задачи анализа, которые состоят в верификации, тестировании, локализации ошибок. Задача верификации является доказательство отсутствия ошибок.

Задачи тестирования – обнаружение возможного максимального числа ошибок.

Задачи локализации ошибки – обеспечивать как правило специфическими методами анализа, применяемыми в процессе отладки.

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

Анализ качества разработки ПО

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

Единых методов оценки этих показателей также не существует

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

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

1) Определение необходимых потребностей в выполнении данной работы в части ресурсов.

2) Способы организации коллектива разработчиков и распределение работ между ними. 3) Методы объективной оценки разрабатываемого ПО.

4) Учет индивидуального вклада каждого разработчики.

В этом контексте наиболее важное значение принимает - эффективность разработки ПО, которая определяется временем, трудозатратами, денежными ресурсами.

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

Документируются как конечные результаты, так и промежуточные разработки.

Выделяется 2 аспекта в этой деятельности:

1) накопление всей информации о разработке, необходимой для его последующей модификации и эксплуатации.

2) Оформление всей документации в соответствии с требуемыми стандартами. Накопление информации в течении всего времени разработки определяется:

1) фиксация результатов.

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

3) Создание компонент проектной информации и технология их связи

Важным аспектом данной деятельности является модификация будущего ПО и всей сопутствующей ему документации.

 

Проблема автоматизации разработки

Проблема: важным аспектом разработки ПО в части автоматизации разработки являются работы в области декомпозиции или автоматического синтеза программ по их спецификациям, т.е по некоторым видам шаблонов.

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

Причины создания автоматиз систем

к таким работам относятся виды работ, носящие рутинный характер.

1) ведение проектной и программной документации в ходе разработки ПО, введение согласованности проектной документации и программ на всем протяжении разработки.

2) Проверка совместимости интерфейсов программных модулей.

3) Подготовка исходных данных для тестирования. Организация работы тестов. и анализ результатов.

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

В США разработка таких программных инструментов более 600, которые отличаются своими методиками, реализованными методами, языками кодирования, средствами описания. более того даже для 1 класса задач данное ПО резко отличалось по способам реализации, ПО не позволяло оценить качество разработки, а одну и ту же задачу надо было решать 1 или 2-мя способами.

Причины обилия такого многообразия числа автоматизированных систем ПО состоят в следующем:

1) технология программирования отсутствовала как научная дисциплина.

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

3) Ориентация большинства таких инструментальных систем на отдельные этапы жизненного цикла ПО или на отдельные виды деятельности. Например, тестирование или документация.

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

Поэтому автоматизированная разработка сложных систем ПО как правило обеспечивается большими технологическими комплексами по разработке ПО или системами поддержки разработки ПО. Такие технологические комплексы позволяют автоматизировать выполнение различных видов деятельности разработки на всех этапах жизненного цикла или их части. Такие как RТS, SDS, SOFTING, суперформат, ритм и т.д.

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

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

1) Создание проектной информации и ввод ее в централизованную базу данных на различных этапах разработки жизненного цикла ПО.

2) Автоматическая генерация некоторых компонентов ПО или проекта.

3) Анализ правильности и согласованности проектной информации и ее замкнутости и полнота информации.

4) Оценка текущего состояния разработки и качества выполнения работ.

5) Планирование хода разработки и контроль за выполнением плана.

6) Общая организация работ в соответствии с некоторой технической схемой.

7) Подготовка и выдача результатов разработки. разработчиком ПО и руководителям разработки. Определение информ. …. разработок.

8) Оформление всей документации в наглядном виде, оформленной в соответствии. со стандартами.

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

1) Разнообразные процедуры статического анализа полноты, замкнутости и согласованности информации

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

3)Символьное исполнение программ.

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

5) Разнообразные способы пошагового прохождения программы и выдачи информации о всех промежуточных результатах.

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

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

 

Лекция 5

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

В некоторых технологических комплексах предусмотрены средства генерации кода в виде тестов, по соответствующим спецификациям.

Под спецификацией будем понимать документ определенной структуры данных.

Среди других средств автоматизации тестирования следует выделить средства моделирования среды тестирования. Такие подходы нужны для выполнения комплексного тестирования сложных объектов, такие средства ориентированы на тестирование объектов в узкой области. Моделирование среды функционирования программного обеспечения, необходимо тогда, когда работа не отлаженного ПО в реальном масштабе времени, может вылиться серьезной материальной затратой (авария в управлении, управление мартеновскими печами, процессы тяжелого машиностроения).

 

Анализ проектирования информации с целью ее правильности связан с анализом текущего состояния разработки (объем работы и время выполнения его с анализом качества разработки при выполнении, управления этой разработкой). Оценка качества может быть вычислена выполнена автоматически на основе некоторых метрик.

Известны 2 технологических комплекса ARGUS и РИТМ, в которых оценки качества разработки основана на простейшем математическом аппарате. В ряде технологических комплексов есть технологические средства персонального контроля сроков работы(1) планирование сроков выполнения работы конкретными исполнителями. 2) Контроль за соблюдением сроков выполнения работы). Такие процедуры как правило имеются в большинстве технологических комплексах, в некоторых технологических комплексах в частности ARGUS и РТК имеются средства автоматизации и построения сетевых графиков, всех этапов выполнения разработки.

Разработка и модификация проектной информации

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

 

Общие приемы разработки проектной инфы

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

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

Методы разработки в широком смысле слова включают:

1) Процедура выполнения соответственного этапа (метод разработки).

2)Требуемые характеристики и структура результата разработки.

3) Средства представления результата разработки.

 

Структуру результата разработки можно представить в 2-х аспектах

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

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

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

Основная проблема, которая возникает в процессе модификаций:

1) адекватность модификаций с ее применением.

2) с естественным стремлением к минимизации изменений

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

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

Классификация методов разработки ПО

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

Аспекты отличий методов разработки ПО:

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

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

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

Среди характеристик методов разработки наиболее важными являются:

1) Стратегическое направление разработки, т.е. подходы систематизации предметной области на структурном уровне.

2)Вид основных объектов разработки (функции и данные).

3) Способы разбиения исходной задачи на несколько менее сложных задач или на более простые.

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

1) Разработка сверху вниз (аналитический подход или снисходящий).

2) Снизу вверх (синтетический подход – метод восходящей разработки.

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

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

 

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

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

1) Когда задача носит чисто формальный характер и решение ее можно получить программным путем.

2) Когда задача формализована на повторное построение с использованием дополнительных понятий и понятий языка программирования.

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

Метод снизу вверх. Метод синтезирования

 

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

 

Лекция № 6 Продолжение

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

При проектировании сверху вниз исходная задача и каждая из вверенных в него понятий может быть решена на более низком уровне из понятий другого уровня. Недостатки метода снизу вверх – в действительности реальная разработка, как правило, использует баланс 2-х стратегий. Однако, как правило, в большинстве разработок используется метод снизу вверх. ОС ЧИ была разработана чисто.

Область применения обоих стратегий

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

Снизу вверх – формализация по порядку.

 

Анализ различий методов создания ПО по типу основных объектов разработки

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

2) Функции, составляющие систему моделей, т.е. функции отражающие структуру проекта ПО.

3) Функции некоторых фрагментов программ, когда выделяются функции используемые во всех фрагментах программы (в любом фрагм.). Как правило в этих методах данные (информ. основа) выступают вторично, однако, они являются неотъемлемой частью всех этих методов (программ, алгоритмов, описаний ит.д.).

 

Методы разработки программ от данных

Существует 2 подхода: 1) R – технология. 2) Метод Джексона.

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

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

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

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

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

В некоторых методах разработки от данных, структура данных описывается виде гамматик (разновидность описания данных). Основная идея всех этих методов одна и та же: структура данных описывается явно, а не в виде алгоритма их обработки. Пример: были разработаны языки прогр.- идеология снизу вверх.

2 подхода разбиения исходной задачи

Два подхода решения разбиения проблемы ПО:

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

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

2)Разбивается на части не решение задачи, а непосредственно ее исходная постановка, формулируется рад более простых задач и затем каждая из них решается независимо друг от друга. К таким методам относится метод Фуксмана (метод расслоенного программирования). И носит название RD - технология программирования. Основной идеей данного подхода (м. Фуксмана) является выделение всех функций системного п.о. таких, удаление которых не делает систему П,О. неработоспособной, а лишь уменьшает его область применения и удобство использования. Такие функции называются расширяющими функциями. Часть системы, из которых удалены все расширяющие функции носит название основы. При использовании указанного метода реализации системы ПО начинают с разработки и отладки основы, после чего последовательно добавляются шаг за шагом расширяющие функции до тех пор, пока не возникает система ПО, удовлетворяющая заказчика.

Таким образом возникает версия ПО. Это позволяет начать опытную эксплуатацию намного раньше, чем эксплуатацию всего ПО.

 

Структурная организация ПО

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

Внешне существуют 2 вида структур: внешняя и внутренняя.

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

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

 

Способы структурной организации программы

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

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

 

Детальное проектир-е…. поддерж. базой

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

1) Метод уровней абстракций

2) Метод портов.

 

Лекция 7

 

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




Поделиться с друзьями:


Дата добавления: 2015-07-02; Просмотров: 514; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.009 сек.