Методы системного проектирования

Циклы повышения продуктивности

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

Повышение продуктивности программирования возможно за счет факторов:

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

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

Внеплановые изменения кода — это изменения, производимые для исправления выявленных ошибок.

Классификации ошибок:

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

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

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

13.   Дисциплина программирования. Проектирование программ. Кодирование. Тестирование  и отладка 

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

Виды  проектирования:

• концептуальное проектирование;

• логическое проектирование;

• детальное проектирование.

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

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

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

Логическое  проектирование

Логическое  проектирование - построение модели будущей программы.

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

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

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

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

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

Детальное проектирование

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

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

• распределение компонентов;
• скелет кода;
• схема базы данных;
• прототип интерфейса.

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

Распределение компонентов

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

 Проектирование  компонентов требует решения  двух вопросов:

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

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

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

Три стандартных  модели распределения компонент  для приложения трехслойной архитектуры  и монолитными слоями:

Скелет  кода

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

Схема базы данных

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

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

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

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

Прототип  интерфейса

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

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

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

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

Кодирование

Кодирование - составление и ввод текста программы на языке программирования, выполняется на фазе реализации.

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

1. Программирование по образцу

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

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