Процедурная модель проектирования

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

Процедура – определённая совокупность элементарных операций по обработке информации, приводящая к изменению ее состава или места расположения, например, поиска, размножения информации ЕСТПП (ГОСТ 14.104).

Качество проектирования зависит от умения использовать знания, достигнутые целым рядом разделов науки, которые нашли отражение в дисциплинах: «Теория механизмов и машин», «Взаимозаменяемость, стандартизация и технические измерения», «Надёжность машин», «Эргономика» - теоретические основы оценки качества продукции и другие.

Модель даёт представление об основных процедурах и операциях проектирования, задачах и методах их решения, указывает на источник информации. Модель согласуется со стадиями ЕСКД.

ЕСКД регламентирует стадии разработки конструкторских документов, структурная схема приведена на рис

Для рабочей документации установочной серии изделий присваивается литера «А», в массовом (или серийном) производстве - литера «Б».

Рисунок - Стадии разработки изделий

Таблица - Процедурная модель моделирования

Стадии разработки	Процедуры проектирования	Методы решения задач	Источники информации

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

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

Таблица - Номенклатура документов при разработке изделий машиностроения

Вид документа	Содержание документа
Чертёж детали	Определяет изображение детали
Сборочный чертёж (СБ)	Определяет изображение сборочной единицы
Чертёж общего вида (ВО)	Определяет конструкцию изделия, принцип его работы
Теоретический чертёж (ТЧ)	Определяет геометрическую форму, обводы и координаты составных частей
Габаритный чертёж (ГЧ)	Контурное, упрощённое изображение с габаритными и присоединительными размерами
Монтажный чертёж (МЧ)	Контурное, упрощённое изображение с размерами для установки, может быть фундамент
Схема	Показывает составные части изделия и связи между ними
Спецификация	Определяет состав сборочной единицы, комплекса или комплекта
Ведомость спецификаций (ВС)	Перечень спецификаций составных частей
Ведомость ссылочных документов (ВД)	Документы, на которые делаются ссылки
Ведомость покупных изделий (ВП)	Перечень покупных изделий
Ведомость согласования покупных изделий (ВИ)	Перечень покупных изделий, согласованных с поставщиками
Ведомость держателей подлинников (ДП)	Перечень предприятий, организаций - разработчиков, у которых хранятся документы
Ведомость технического предложения (ПТ)	Перечень документов, вошедших в техническое предложение
Ведомость эскизного проекта (ЭП)	Перечень документов, вошедших в эскизный проект
Ведомость технического проекта (ТП)	Перечень документов, вошедших в технический проект
Пояснительная записка (ПЗ)	Описание, принципы действия, обоснование технических решений
Технические условия (ТУ)	Требования к изделию и его изготовлению, контролю, поставке и т.д.
Программа и методика испытаний (ПМ)	Технические данные, подлежащие проверке, порядок и методы испытаний
Таблица (ТБ)	Данные, сведенные в таблицу
Расчёт (РР)	Расчёты параметров, величин на прочность, размерные цепи и др.
Эксплуатационные документы	Например, инструкция по эксплуатации и ремонту
Ремонтные документы	Данные по ремонту на специализированных предприятиях
Патентный формуляр (ПФ)	Данные о патентной чистоте изделия (продукции)
Карта технического уровня и качества продукции (КУ)	Технические и экономические показатели качества продукции

Структура и виды изделий

Изделие – предмет или совокупность предметов производства (рис. ), подлежащих изготовлению на предприятии (гайка, вал, подшипник, самолёт).

Рисунок - Декомпозиция и виды изделий

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

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

Комплекс – два и более изделий, которые функционально связаны, но не соединёны сборочными операциями на заводе - изготовителе, предназначенные для выполнения взаимосвязанных функций (посадочный комплекс для самолётов, ЭВМ как совокупность блоков, цех-автомат, ракета и пусковая установка со средствами управления).

Комплект – комплекс эксплутационного назначения (комплект запчастей, инструментов).

Целевое проектирование. Компоненты проектирования

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

Обозначим компоненты проектирования: А={a₁,....,a_m} - множество целей проектирования; P={p₁,...,p_n} - множество признаков, характеризующих цели (численные показатели достижения целей); X={x₁,...,x_k} - множество технических решений, которые выполняют требуемые функции и характеризуются значениями признаков; V={₁,....,_l} - множество оценок; m, n, k, l - мощности множеств.

Вставка Проектирование (рис. ).

Четыре компонента проектирования образуют граф: вершины - это элементы этих множеств, расположенные на четырёх уровнях; ребра- отношения, связи между ними.

Проектирование технической системы рассматривается как отображение на множество оценок среза произведения бинарных отношений двух видов:

- множество целей и множество признаков;

- множество признаков и множество конструктивных решений.

F: ( *  (A₀))  V,

где  - бинарное отношение между множествами А и Р (целями и признаками):

  (А * Р) при А₀  А ;

 - бинарное отношение между элементами множеств Р и Х (признаками и решениями):

  (Р * Х) при А₀  А.

Множества обычно ранжируют . Запись

означает, что функция F устанавливает соответствие между скобкой и отношением.

 (А₀) = ((р) (а)) [аА₀ и (а, р)  ] .

 (А₀) = ((х) (р)) [рР₀ и (р, х) ] .

где Р₀ - это срез множества Р по подмножеству А₀.

Произведение бинарных отношений  х  равно:

 х  = ((а,х) (р)) [(а,р)  и (р,х) ]

представляет собой множество упорядоченных пар (а, х) таких, что для них существует элемент р множества Р с которым он вступает в отношение  с элементом х. В этом случае срез по подмножеству А₀ будет:

 х  (А₀) = ((а,х) (р)) [(а,р)  и (р,х)  и аА₀].

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

(F: ( x (A₀))  V)  opt.

Понятие цели проектирования. Иерархия целей

Цели как любые объекты могут быть разделены по важности или по другим признакам, т.е. цели можно классифицировать. Цели могут противоречить друг другу, например: производительность и универсальность, качество и стоимость. Попытки достичь одних целей в ряде случаев приводят к ухудшению других показателей. Цель может быть представлена в виде иерархии целей (графов), где цели и подцели связаны между собой. На 0 уровне абстракции находятся интересы всего человечества; на 1-м уровне- государственные интересы; на 2-м уровне - интересы отрасли; на 3-м уровне - интересы предприятия; на 4-м уровне - интересы проектировщика; на 5-м уровне – интересы подразделения, организации; на 6-м уровне - личные цели.

Оценка целей проектирования. Матрица смежности для орграфа целей

Для выделения более важных целей определяют вес цели как правило в долях единицы и на основании экспертных оценок:

а) ранжируют цели на каждом подуровне;

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

i- номер уровня; j-номер цели на i-ом уровне (номер после ранжирования) i{0,I,II,….}; j{0,1,2,….};

r _i-j – оценка веса цели на i-ом уровне без учета связей (относительный вес), сумма весов на уровне равна 1;

R_i-j – абсолютная оценка веса цели с учетом связей;

 - место цели на данном уровне (места могут быть одинаковыми).

Структуру связей представляют в виде матрицы смежности или инцидентности. В матрице смежности строки – узлы предшественники; столбцы- узлы последователи. Если одна вершина связана с другой, то на пересечении соответствующей строки и столбца ставится 1, если нет- 0.

Таблица - Матрица инцидентности

i-j \ k-m	1-1	2-1	…
1-1	0	1
2-1		0	…
…		…	…

При построении графа целей используют понятие относительного веса вершины и коэффициента связи. Коэффициент связи обозначается С_{ij, km} , и при построении графа ставится над стрелкой, обозначающей связь (рис. ).

Коэффициент связи определяется по формуле

С_{ij, km}= r _{ij *} r _km ,

где – коэффициент связи по заходящим связям (i, m – номера связанных уровней вершин; j, k – номера связанных вершин соответственно на уровнях i и m).

Определение абсолютного веса вершины при оценке целей проектирования

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

, (1)

где R_ij – абсолютная оценка веса цели с учетом связей; i – номер уровня абстракции; j – номер цели на i-м уровне; r_ij‑экспертная оценка веса j-й цели на i-м уровне без учета связей, выраженная в долях единицы (относительный вес);

Модель технической оценки варианта решения

Экспертные оценки возможных вариантов технических решений применяют, например, в виде матриц, в которых указываются преимущества и недостатки выделенных технических решений [6]. В качестве критериев можно использовать также показатели качества, рекомендованные ГОСТ 14.202. Модель технической оценки варианта решения рассматривается в виде суммы оценок по каждой цели для каждого элемента системы [2]:

, (2)

где Q – оценка реализации целей конкретным вариантом исполнения системы; _j - коэффициент значимости j-й цели, в качестве которого могут быть использованы абсолютные веса целей; k_ij – экспертная или другая (экономическая) оценка i-го варианта элемента системы с точки зрения удовлетворения j-й цели.

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

Другой подход для выбора технического решения основан на выделении функций и использовании стоимостных показателей для их реализации – функционально-стоимостной анализ и его разновидности [6]. Окончательная оценка варианта технического решения системы при таком подходе может быть дана на основе сопоставления его качественных показателей с затратами на изготовление:

, (3)

где k_эф. – коэффициент эффективности варианта; n – число основных функций системы; m‑количество вспомогательных функций, обеспечивающих i-ю основную функцию; S_i,j ‑ расходы на реализацию j-й вспомогательной функции, обеспечивающей i-ю основную; β_j ‑ коэффициент значимости j-й функции; k_ij – оценка варианта j-й вспомогательной функции, обеспечивающей i-ю основную.

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

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

1. декомпозиция системы, выделение функций, составление И-ИЛИ-дерева;

2. на основе целевой оценки выбор на И-ИЛИ-дереве вариантов решений (узлов) для всех функций (построение И-дерева);

3. выбор конструктивных решений-аналогов для элементов и системы в целом;

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

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

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

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

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

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

2. составление сценария развития сфер окружения на каждом уровне абстракции: - история развития; - направление развития; - прогноз; - создание прототипа;

3. выделение целей и построение графа целей;

4. экспертная оценка относительных весов;

5. расчет абсолютных весов.

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

Технологический процесс разработки автоматизированных систем

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

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

Рисунок - Жизненный цикл автоматизированной системы

Проблемы, возникающие при разработке АС:

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

2. Ограниченность вычислительных ресурсов.

3. Сложность технологии испытания систем.

Существуют различные технологии разработки АС, которые регламентируются ГОСТ 34.601 или другими стандартами, в частности технологией SSADM (Structured Systems Analysis and Design Method), которая является государственным стандартом Великобритании и получила широкое распространение в Европе [15].

Принципы технологии SSADM и ее место в жизненном цикле АС

При разработке программного обеспечения применяют ряд моделей ЖЦ на основе процедурного или ОО подхода к проектированию. Различают также два вида реализации технологического процесса: каскадный и итерационный. Каскадная модель регламентирует строгую последовательность этапов. Спиральная модель предусматривает несколько итераций до стадии внедрения. SSADM является компромиссом между этими классическими подходами. АС разрабатывается в целом по каскадной модели, но с проведением исследований, циклами на первоначальных этапах проектирования. Технология SSADM осуществляется в соответствии со следующими принципами:

1. Постоянное вовлечение пользователей в процесс выработки, принятия решений на протяжении всего цикла.

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

3. Контроль каждого этапа технологического процесса со стороны руководства:

   • встроенный контроль качества (тесты);

   • выделение формализованных критериев качества.

4. Использование по возможности CASE – средств.

5. Стыковка с существующими для принятых систем проектирования, технологиями и управлением базами данных.

6. Формализация средства разработки в виде различных методологий, алгоритмов, таблиц, форм.

Типовой технологический процесс создания АС

Типовой ТП включает семь стадий, каждая стадия состоит из этапов, этапы делятся на операции

Таблица Стадии и этапы технологического процесса создания АС по технологии SSADM и в соответствии с ГОСТ 34.601

Стадии и этапы SSADM

ГОСТ 34.601 на создание АС

Стадия 0 Оценивание реализуемости (необязательная). 01 Определить рамки, составить план разработки. 02 Определить первоначальный вариант требований к АС. 03 Выбрать вариант оценивания реализуемости (технико-экономическое обоснование). 04 Оформить отчёт о возможности создания АС. Стадия 1 Предпроектное обследование. Определить рамки предпроектного обследования. Определить основные требования к АС. Изучить процессы обработки информации в существующей системе. Изучить данные, которые обрабатываются. Разработать логическое описание существующей системы. Обобщить результаты обследования. Стадия 2 Выбор варианта автоматизации. Стадия 3 Разработка ТЗ. Разработать общие требования к АС. Разработать требуемую логическую модель (ЛМ) данных. Уточнить требования к функциям и задачам. Уточнить ЛМ данных. Разработать демонстрационный прототип. Разработать требования к обработке данных. Уточнить цели разработки АС. Оформить ТЗ на создание АС. Стадия 4 Выбор варианта технической реализации. 4.1 Разработать варианты технической реализации. 4.2 Выбрать вариант технической реализации. Стадия 5 Разработка логического проекта. 5.1 Определить порядок диалогового взаимодействия. 5.2 Разработать постановки задач модификации БД. 5.3 Разработать постановки информационных задач. 5.4 Завершить разработку лог- проекта. Стадия 6 Физическое проектирование Разработать план физического проектирования. Подготовить физическую организацию БД. Разработать спецификации требований к программным компонентам. Оптимизировать физическую структуру БД. Уточнить спецификации требований к программным компонентам Согласовать интерфейс между задачами и БД. Оформить физический проект

Стадия 1 Формирование требований к АС. Обследование объекта и обоснование необходимости создания АС: изучение объекта, видов его деятельности, режимов, оценка качества функционирования, выявление проблем для решения с помощью АС. Формирование требований пользователя к АС. 1.3 Оформление отчёта и заявки на разработку АС. Стадия 2 Выработка концепции АС. 2.1 Изучение объекта. 2.2 Проведение необходимых НИР. 2.3 Разработка вариантов концепции и выбор варианта, соответствующего требованиям пользователя (разработка альтернативных вариантов, оценка их преимуществ и недостатков, необходимых ресурсов на реализацию, выбор оптимального варианта на основании сопоставления требований пользователя и возможностей АС). Стадия 3 Техническое задание (ТЗ). 3.1 Разработка и утверждение ТЗ. Стадия 4 Эскизный проект (необязательная). 4.1 Разработка предварительных проектных решений по АС и подсистемам: состав задач, концепция и структура информационной базы, функции СУБД, состав вычислительной системы, функции и параметры основных программных средств. 4.2 Разработка документации на АС и её части. Стадия 5 Технический проект 5.1 Разработка проектных решений по системе и её частям: по функционально - алгоритмической, и оргструктуре АС, технических средств, по ведению БД, классификации и кодированию информации, алгоритмам решения задач, по применяемым языкам и ПО. 5.2 Разработка документации на АС. 5.3 Разработка и оформление документов на поставку или ТЗ на разработку комплектующих. 5.4 Разработка заданий на проектирование в смежных частях проекта объекта автоматизации. Стадия 6 Рабочая документация. Разработка рабочей документации на АС и ее части. 6.2 Разработка или адаптация программ. Стадия 7 Ввод в действие. Стадия 8 Сопровождение АС.

Для поддержки проектирования технология SSADM содержит порядка 50 документов, включающих методики реализации стадий создания АС.

До сих пор сверху

Характеристика методики определения требований к АС

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

При выполнении стадий 0 - 3 требования итерационно рассматривают и уточняют, после чего изменение требований запрещено.

На СТ.4 незначительно количество требований уточняются, в том числе требования к диалоговому взаимодействию.

Решение поставленных задач решается на этапе 5

На этапе 6 физ. Проектирования контролируют степень выполнения указанных требований.

В методике выделяют следующие положения:

1. Функции разработчиков при формировании требований (роли).

2. Осуществляют сбор первичной информации и требований к обработке.

3. Постоянное ведение каталога требований.

4. Выделяются виды требований (группы).

5. Формирование характеристик требований (формирование).

В формировании требований участвуют и специалисты пользователи

Параллельно с требованиями форм – ся и результаты работы системы.

Сбор первичных требований

Методы сбора:

1. интервью;

2. изучение документации;

3. анкетирование пользователей и протоколирование их деятельности;

4. стажировка на рабочем месте;

5. наблюдение;

6. мозговой штурм;

7. прототипирование;

8. использование собственных знаний и опыта;

Независимо от метода полезны ответы на следующие вопросы:

1. Что требуется от системы?

2. Зачем вам это нужно?

3. Кому это нужно?

4. Насколько это важно?

5. Чем можно измерить степень соблюдения требований?

Виды требований:

1. функциональные;

2. нефункциональные.

Функциональные требования отвечают на вопрос «Что должна делать система?», нефункциональные «С каким уровнем качества должна делать система?»

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

Определение нефункциональных требований

1. Требования к качеству выполнения функций.

2. Ограничение доступа

3. Обеспечение требований к безопасности

4. Обеспечение мониторинга и контролируемости и др.

1. Например, Требование к качеству

– часы работы (время суток, дни недели, особенности для выходных и праздничных дней);

- доступность – доля времени в % выполнения функций;

- оперативность – время функции для систем реального времени или продолжительность решения задачи;

-частота заявок – количество заявок на решение задач в единицу времени;

- производительность – суммарный объём работы в единицу времени (количество считываемых данных Мбит/с);

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

- надёжность – среднее время наработки на отказ;

- среднее и максимальное время на выполнение;

3. Ограничение доступа:

- Каким данным нужна защита?

- Следует ли ограничить доступ для конкретного пользователя; да – определить вид ограничения?

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

4. Требования к безопасности:

- изготовление страховочных копий (архивирование)4

- резервирование;

- восстановление работоспособности при отказах.

5. Обеспечение мониторинга и контролируемости: особое значение имеет для финансовых систем (ревизия деятельности).

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

Прочие ограничения:

1. требования к работе при переходе на новую систему:

2. требования к работе по сопряжению с другими системами;

3. построение человеко-машинного интерфейса;

4. архивирование и уничтожение данных.

МОДЕЛИ Жизненного цикла и ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ СИСТЕМ

Принципы инженерии программного обеспечения

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

Следующий этап развития технологий разработки программных продуктов связан с появлением объектно-ориентированного (ООП) подхода к проектированию и программированию. Архитектура языков объектного и объектно-ориентированного программирования позволяет описывать абстрактные объекты. Теория типирования, воплощенная в языках типа Pasсal, дает возможность осуществить контроль правильности использования абстрактных типов при программировании. В языках, поддерживающих ООП, основным элементом является модуль, состоящий из логически связанных классов и объектов, а не процедур [1]. Инкапсуляция данных, размещенных в классах и объектах, существенно повысилась, а доступ к ним четко ограничивается интерфейсом класса. Область глобальных данных сведена до минимума или исчезла вообще, что упрощает контроль за работой программного продукта, существенно облегчает его модификацию.

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

Структура ЖЦ и её отображение в документации.

Разработка ПО осуществляется в рамках области знаний, которая называется «Программная инженерия» - это инженерная дисциплина, которая является ПО, а предметом – создание, различные аспекты создания ПО и эксплуатация на всех этапах ЖЦ.

Программная инженерия улучшила следующие характеристики программ:

1. читаемость и понятность (за счёт структурирования и документирования).

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

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

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

Кроме двух базовых принципов:

• «разделяй и властвуй» (декомпозиция);

• иерархическое упорядочивание

Существует ряд принципов не менее важных:

1. Принцип абстрагирования – выделяются только существенные свойства системы в соответствии с аспектом моделирования.

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

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

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

5. Принцип непротиворечивости – обоснованность и согласованность работы элементов системы.

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

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

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

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

Жизненный цикл программного продукта и его этапы

В основе деятельности по созданию и использованию программного обеспечения (ПО) лежит понятие его жизненного цикла (ЖЦ).

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

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

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

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

Характеристика этапов

1. Этап концептуального проектирования - разрабатывается обобщённая модель системы (организации) для последующей автоматизации её деятельности. Планируется распределение всех видов ресурсов.

2. Этап анализа - начинается с детализации концептуальной модели. Выделяются основные функции системы, процессы и потоки информации, протекающие между ними (DFD); осуществляется декомпозиция данных; выделяются состояния системы и возможности их изменения (STD) – логический уровень проектирования. Кроме построения диаграмм строится их текстовое описание.

3. Этап общего проектирования - строят и представляют архитектуру системы в виде структурной схемы (ЗС) – это физический уровень, который показывает взаимодействие модема системы. При физическом проектировании разрабатывают более детальный проект базы данных, интерфейс пользователя и тесты.

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

5. Производится кодирование (CASE- средства).

Резюме.

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

- модель;

- архитектура;

- алгоритмы;

- код.

Таблица - Этапы проектирования и модели программных систем при структурном подходе

Концептуальное моделирование	Логическое моделирование		Логическое и физическое моделирование				Кодирование, отладка, тестирование		Эксплуатация и развитие
Стратегическое планирование -концептуаль-ная модель; -план разработки	Общее проектирование -модель системы; -словарь данных; -разработка спецификаций (мини-спецификации); -последователь-ная архитектура ПО; -план тестирования		Детальное проектирование -окончательная архитектура изделий; -спецификация модулей; -проект архитектурных тестов (тесты сборки); -уточнённые мини-спецификации		-алгоритмы модулей; -проект тестов модулей		Реализация - код модулей; -код тестов; -протоколы тестирования; -протоколы сборки; -протокол испытаний		Сопровождение -протокол сопровождения; -предложение по развитию
-диаграммы, таблицы основных функций; -диаграммы, таблицы информационных потребностей		-диаграммы потоков данных (DFD); -диаграммы типа «сущность–связь» (ERD); -диаграммы переходов состояний (STD)		-структурные схемы; -иерархические схемы вызовов (SC)		-R – схемы; -диаграммы действий; -языки программирования; Flow ( )		-журналы регистрации сбоев; -предложения клиентов

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

1. Каскадная модель (70-80гг.) предполагает переход на следующий этап после полного окончания работ по предыдущему этапу. (Т.е. план – закон!). Такая модель в значительной степени является идеализацией и пригодна тогда, когда можно заранее спланировать все этапы. Например, надо быстро, жёстко что-нибудь поставить на рынок. Главным недостатком является то, что заказчики недостаточно понимают что же они хотят от автоматической системы.

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

3. Спиральная модель (86 90 гг.) делает упор на начальные стадии ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. Производится последовательное циклическое повторение этапов ЖЦ.

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

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

• Накопление и повторное использование программных средств, моделей, прототипов (интерфейсные модули, форматы файлов…)

• Ориентация на развитие и модификацию ПО в процессе проектирования (версии обновляются часто 2 раза в год.- Рro/Enginttr)$

• Анализ риска и издержек в процессе проектирования;

• Благодаря прототипированию разработчики добиваются уточнения требований от заказчиков.

В чистом виде спиральная модель пригодна в большей степени для сравнительно небольших проектов (Всё меняется.

Оптимум по мнению создателей промышленной информационной технологии Великобритании SSADM (Structured Systems Analiysis and Desing Metod ) лежат в области каскадной модели с итерационными циклами, аналогичными спиральной модели. (посередине, как и всякая истина).

Применение определённой последовательности этапов позволяет использовать такие технологии в качестве стандартов (ГОСТ 34.601-90 и др. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. (ГОСТ 34.201-89, 34.602-89,РД-50-698-90, ГОСТ 34.003-90, РД-50-34.119-90). –М.: Госстандарт СССР, 1991 – 143с.)

С другой стороны, стандартизация подходов к проектированию позволяет интенсифицировать создание АС. Возникает база для применения инструментальных программных средств проектирования АС. (CASE – Computer- Aided Software Engineering).

В Англии SSADM развивалась сначала в государственном секторе, затем принята как государственный отраслевой стандарт (1993 г.). Сейчас существует Ассоциация пользователей (International SSADM Users Group) – более 3000 индустриальных членов и более 300 организаций в Западной Европе и Японии.

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

Гордон Мур – один из основателей фирмы Intel вывел закон, по которому количество транзисторов, умещаемых на кристалле, удваивается каждые 18 месяцев: каждые 1,5 – 2 года появляется качественно новое поколение ЭВМ. Таким образом время жизни ЭВМ составляет примерно 2 года.

Функции CASE - средств при автоматизации ЖЦ ПО

1. Поддержка всех этапов ЖЦ.

2. Координация работ.

3. Поддержка качества ПО.

4. Контроль обеспечения функций к ПО.

5. Возможность создания прототипов с последующим наполнением.

6. Организация работы большого количества программистов.

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

8. CASE- средства обеспечивают интеграцию:

– данных

– контроля;

– представления.

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

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

- интеграция данных обеспечивается наличием депозитария (служебная БД, где хранятся данные по проекту);

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

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

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

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

В целом использование CASE- средств позволяет повышать предсказуемость работы по качеству, сроку, стоимости. Например, применение языков визуального проектирования и прототипирование позволяют ускорить процесс разработки в 10-20 раз.

Рисунок

Проблемы внедрения CASE- систем

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

1. Стратегическая информация слабо структурирована, она нечёткая и фрагментарная.

2. CASE- средства слабо напоминают такую информацию, нужна коллективная работа экспертов.

3. Использование CASE- средств требует знания разработчиков в области принятой методологии проектирования, то есть требуется более высокая культура разработки программного обеспечения. Для этого нужно затратить определённые усилия по изучению CASE- средства, усилия по более чёткому использованию методологии.

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

Сравнение традиционной разработки и CASE технологии

Сравнение каскадной и итерационной моделей

Рисунок - Традиционный лавинообразный цикл разработки (каскадная модель ЖЦ) и спиральная (CASE) модель создания программных изделий

Преимущества CASE – модели (спиральная)

1. Повышение доли интеллектуального труда при проектировании.

2. Уточнение требований за счёт прототипирования увеличивает качество работы.

3. Специализированная БД сохраняет накопленный опыт и способствует обучению программиста.

4. Направленность проекта на развитие, модификацию (этап стратегического планирования.)

	Традиционная разработка	CASE - технология
1	Основные усилия на кодирование и тестирование	Основные усилия на анализ и проектирование
2	«Бумажные» спецификации	Быстрое итеративное прототипирование
3	Ручное кодирование	Автоматическая кодогенерация
4	Ручное документирование	Автоматическая генерация документации
5	Тестирование кодов	Автоматический контроль проектов
6	Сопровождение кодов	Сопровождение спецификаций проектирования

CASE – модель жизненного цикла ПО

CASE средства и технологии предлагают новый, основанный на автоматизации подход к концепции жизненного цикла ПО.

При использовании CASE изменяются все фазы жизни ЖЦ, при этом наибольшие изменения касаются фаз анализа и проектирования.

В CASE – модели фаза прототипирования заменяет традиционную фазу системного анализа.

Наиболее автоматизированными являются фазы контроля проекта и кодогенерации ( хотя все остальные также поддерживаются CASE средствами)

Жизненный цикл разработки программного обеспечения при ООП проектировании

Разработка ПП до сих пор остаётся трудоёмким процессом и основано на ручных методах даже на заключительных этапах разработки.

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

• распределение ресурсов;

• установление промежуточных этапов;

• управление конфигурацией;

• проверка версий.

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

Каждая модель (лавинообразная) _ традиционная, имеет следующие недостатки:

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

• обязательное последовательное выполнение всех этапов разработки;

• несовмемтимость с эволюционным подходом, который внедряется благодаря прототипированию;

• несовместимость с возможностями автоматического программирования, трансформации программ, CASE технологий, вспомагательных средств, основанных на базе знаний;

• особо отметим. ООП представляет собой последовательный итеративный процесс, то есть подход эволюционный, естественный. Для ООП более подходит спиральная модель создания ПП.

Рисунок - Традиционный лавинообразный цикл разработки (каскадная модель ЖЦ) и спиральная (объектно - ориентированная) модель создания программных изделий

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

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

Характеристика этапов ЖЦ при ОО подходе

1. Целью анализа является описание задачи и требований к системе.

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

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

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