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

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

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

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

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

1) На каждом уровне абстракций абсолютно ничего не известно о уровнях абстракций более высокой иерархии.

2) На  каждом уровне абстракций ничего не известно о других уровнях абстракций и также ничего ни известно о внутреннем устройстве других уровней абстракций.

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

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

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

6) Связи между уровнями абстракции ограничены аргументами, передаваемыми программами с уровня все уровни.

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

Метод портов

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

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

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

1) Модули выполняют слишком много функций что приводит к запутанным и сложным программам.

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

3)Не учтены все взаимодействия модулей, использующие общие данные.

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

Прочность модуля  - мера его внутренних связей.

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

1) Прочность модуля по совпадениям – модуль с неявно выраженными связями. Такие модули могут появляться тогда, когда в написанной программе обнаружены одинаковые последовательности части программ и которые объединены в 1 модуль. Данному модулю присуща сильная зависимость от вызываемого модуля и чувствительность к внесению изменений в данный модуль.

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

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

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

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

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

7) Функциональная прочность – это информационно прочный модуль выполняющий одну функцию.

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

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

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

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

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

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

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

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

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

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

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

Структурный подход

Структурная организация модулей.

Основными объектами структуризации обычно выступает поток передач управления в программе. Именно это определяет структуру.

Что касается потока управления, то сложность программирования возникает в программе, тогда когда используется оператор goto который нарушает структуризацию любой программы. Такие языки как Фортран, Бэйсик используют данный оператор, что говорит о его главной структурированности.

Лекция 8

Технология прогр.

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

1) Последовательный оператор.

2) Условный оператор.

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

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

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

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

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

1) Какие объекты требуют описания.

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

3) Кто будет воспринимать данное описание.

4) Какова технологическая роль представления.

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

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

1) Описание характеристик и параметров внешней среды как некоторой системы обработки данных, в рамках которой и должно функционировать данное ПО.

2) Параметры самого ПО.

3) Процессы взаимодействия внешней среды и ПО.

4) Функции ПО. определяемые данными процессами или поддерживающие данные процессы.

5) Критериев и показателей эффективности выполнения той или иной функции при разработке ПО.

Морфологическое описание объекта должно дать представление о строении ПО как некоторой системы.

1) Описание состава функций компонент ПО.

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

1) Законы изменения параметров внешней среды ПО.

2)Диапазоны изменения этих пар-ров.

3) Способы представления их в вычислительной системе (форматы).

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

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

Пользователи проектной информации. – т.е. кто будет воспринимать эту информацию на каждом этапе:

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

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

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

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

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

2) Содержание проектной информации.

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

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

Средства представления проектной информации на каждом этапе разработки ПО будем отмечать следующие:

1) Каким объектом мы будем заниматься на данном этапе.

2) На каждом этапе мы будем оценивать кому адресована информация.

На этапе формирования требовании к будущему ПО .

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

 2) Влияние функции создаваемого ПО. т.е. оценке эффективности будущего ПО производится с внешней стороны.

3) Используемыми данными, которыми будет наполняться будущее ПО.

4) Требованиями к ограничениям, касающихся количественной части будущего проекта, т.е. количественной части параметров, если не удается описать объект с его предметной стороны, т.е. достаточно формально, то принимают подход из вне, определяются границы, цели. В известных технологиях разработки ПО этап формирования требований разрабатывается различными средствами, использующие различные языки описания. Языки описания – это языки RSL и PSL, язык АКТ, язык суперформат,HIPO- диаграммы, диаграммы SAMM, а также взаимосвязный набор шаблонов и бланков, которые. обычно используются в таких системах как ARGUS, TRIAT, SOFTING, суперформат.

Наиболее полное представление разнообразных объектов описания, которые позволяют в полной форме интерпретировать требования это язык АКТ, а также языки RSL и PSL, построенные на концепции структуризации информации, т.е. на технологии ERA( объект- связь- атрибут. Эти языки позволяют представить практически все компоненты описания требований, т.е. на них можно описать:

1)цели разработки.

2) описание функции и данных.

3) Описание характеристик

4) Описание ограничений.

На этапе разработки архитектуры (проектирования) ПО , где основными объектами анализа являются внутренняя. структура объекта

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

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

3) Описание функций каждой из подсистем.

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

Способы реализации подразделяются:

1) Каким образом будет передаваться данные (через программы, вызовы, сообщения, через общие области и т.д.).

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

Описание архитектуры: при описании архитектуры разрабатываемой специалистами, в области ПО предназначена для использования разработчиками детального проекта системы, т.е. предназначено для программистов профессионалов и поэтому средства разработки проектной информации должны быть ориентированы на них. Предоставление архитектуры сложных систем ПО, состоящих из большого числа моделей, осуществляется специальными средствами или специальными языкам проектирование архитектуры системы. На этапе детального проектирования основными объектами анализа являются алгоритмы и структуры данных, разрабатываемых модулей поскольку они используются самими разработчиками ПО. то и представляются они в тех терминах, которые понимают программисты, т.е. алгоритмы представляются в виде блок-схем, а также в виде диаграмм, таких как HIPO; SAD; SAM – диаграммы.

В этих комплексах используется язык псевдокодов.

Лекция 9

Этап детального проектирования

Основным представлением объектов на этом этапе являются алгоритмы и структура данных, разрабатываемых модулей, поскольку они используются самими разработчиками программного обеспечения, то они представляются в форме, ориентированной на программистов профессионалов. Алгоритмы, как правило, описываются блок-схемами, диаграммами HIPO; SAD; SAM, диаграммы – Шнайдера.

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

 Понять с какого уровня начать, чтобы не потерять прибыль.

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

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

Проблемы, которые возникают при модификации проектной информации.

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

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

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

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

Модификация ПО как улучшение эксплуатационных характеристик

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

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

В этом направлении есть 2 течения:

1) оптимизация

2) Примайзер в программ. всю программу оптимизируют процесс глобальной. оптимизации. пока не доступен.

CDL2LAB - в которой реализуется процедура глобальной оптимизации. Работает по следующим принципам: цель расширить узкие места.

Проблема применения готовой проектной информации.

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

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

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

1)что для разработки сложного объекта сложно найти подходящие модули среди ограниченного числа модулей.

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

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

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

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

1) АСУ - линейное программирование.

2) Линейные и нелинейные .

3) Расчет упругости.

Эта прибыль была достигнута за счет

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

2) Однотипная организация задач.

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

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

Это явление объясняется:

1) Стремлением к минимизации размера каждого модуля.

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

Основные принципы подхода разработчиков к системе …..

1) Надо создавать программу, выполняющую единственное дело, т.е. лучше написать новую программу, чем добавлять существующую процедуру, оператора.

2) Следует предполагать, что выходные данные каждой программы могут поступать на вход другой программы.

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

В системе UNIX существует язык ШЭЛ, который управляет заданиями системы (диспетчер), который предоставляет простые и мощные средства комплексирования, независимо от разработанных модулей.

Комплексирование позволило:

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

2) Все программы объединится в данные только через последовательные файлы. Унификация структуры позволяет уменьшить вероятность того, что различные программы не будут стыковаться. Единообразный вызов программ и командных файлов на языке ШЭЛ упрощает объединение программ, выстраивается конвейер. Примерами команд обычно не встречающихся в других операционных системах является сортировка файлов, форматизация и вывод текстовых файлов, сравнение текстовых файлов и многое др, в системе форд.

Лекция 10

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

Распространенные методы и средства разработки ПО

Вариантные сети, операционные маршруты и вертикальные слои.

 1)Вариантные сети.

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

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

Среди полезных средств документальных фиксации выбранных решений отмечают следующие:

1) Возможность проверки руководителем или специалистом правильность выбранного решения.

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

3) Фиксация обоснований позволяет использовать принятое решение в других аналогичных проектах, т.е. позволяет  накапливать данные о проектах.

Фиксация представляется в виде вариантного сектора, который включает в себя:

1) Четкая постановка вопроса, требующего решения.

2) возможные варианты решения поставленного вопроса.

3) Свойства, по которым производится сравнение вариантов.

4) Матрица оценок вариантов.

5) Аргументация этих оценок, т.е. обоснование их.

6) Выбранный на основе этих оценок вариант.

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

Зависимый вариантный сектор граф вариантной сети вар-ая сеть

…….

Среди функций программной поддержки или вариантных сетей выделяют следующее:

1) ввод информации.

2) Хранение и пополнение сети.

3) Контроль правильности и полноты сети.

4) Различного рода визуализации сети, т.е. ориентация проблемы с точки зрения определенных критериев, ориентаций проблемы. Например, с точки зрения пользовате…., заказчика….

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

Операционные маршруты пишутся на языке АКТ в одноименном технологическом комплексе АКТ.

2.Вертикальное слоение программ

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

 Для начальной систематизации используются следующие принципы:

1) это членение или разделение проекта на составные части.

2) Обеспечение функциональности и независимости этих частей.

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

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

Горизонтальный слой, обеспечивает определенный уровень, реализующих функций.

График…..

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

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

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

Основа:

Задача:

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

Необходимо ввести расширяющие функции:

1) Учет и печать полного набора сведений о сотрудниках.

2) Частота изменение требований к сотрудникам,

3) отбор анкет по значению атрибутов.

4) Печать части требования от сотрудниках.

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

6) Контроль ошибок входной информации.

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

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

2) Для печати.

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

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

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

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

2) Легкость освоения системы, которая может производиться в той же последовательности в которой происходит разработка программной системы.

3) Легкость модернизации системы, которая вытекает из того, что модернизации подвергается только удалением и восстановление функций.

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

Лекция 11

Технология вертикального слоения имеет ряд недостатков:

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

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

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

Технология низвосходящего проектирования состоит в следующем:

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

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

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

Технология низходящего проектирования лишена недостатков.

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

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

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

3) Фиксация версии, создаваемой системы, т.е. передача ее в эксплуатацию.

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

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

Инструментальный  комплекс позволяет разрабатывать параллельно ряд слоев независимыми разработчиками. Экспериментальная версия данного подхода была разработана в 60 –х годах для ES ЭВМ. В последнее время разработка больших машин возвращается.

SADT  диаграммы.

Методы структурного анализа и технологии.

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

SADT-диаграммы были разработаны Россом, и являются собственностью sotteach.

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

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

1) Язык включает в себя любой другой язык, а его область представления универсальная и неограниченна.

 2) Его единственной задачей является упорядоченная организация (хорошо структурированная декомпозиция описываемого предмета.

3) Размеры единиц декомпозиции выбираются в соответствии с пониманием и характером мышления пользователя в этой предметной области, т.е. использование языка пользователя.

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

5) Такую структурную декомпозицию можно проверить до любой степени глубины.

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

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

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

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

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

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

Графические элементы

…..График …

Стрелки и блок поддерживаются названиями, поясняющими смысл действия.

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

Механизм поддержки -   устройство, которое поддерживает механизм поддержки

Языки описания требований PSL и RSL.

Эти языки оказались производными и стали независимыми – на основе ряда технологического комплекса.

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

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

1) Описать потоки входных и выходных данных системы.

2) Описать структуру системы, т.е. описать иерархию объектов системы.

3) Описать структуру данных и связи между данными.

4) Преобразование данных, т.е. определить какие данные участвуют в процессе обработки данных.

5) размеры и объем системы (конкретные значения).

6) Выявить динамику системы, т.е. оценить как поведет себя система во времени.

7) Свойства системы (оценить каждый атрибут системы.)

8) Управление проектом. (Он позволяет определить конкретные сроки и контрольные точки разработки системы.)

Язык RSL, также как и язык PSL содержит некоторый набор определенных типов объектов. В RSL их обычно называют элементами: типов объектов и атрибутов, однако в отличие от языка PSL,  язык RSL является расширяющим и допускает определение новых типов объектов отношений и атрибутов, и последующее использование их как новых объектов или базисных объектов. Описание новых типов объектов отношений и атрибутов выполняется точно также как например в Паскале, СИ, Бейсике. Разница состоит лишь в том, что в системе RSL информация о вновь созданных типах объектов отношений и атрибутов сохраняется в базе данных системы.