2.6. Рабочие тетради

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

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

2.6.1. Порядок ведения записей

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

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

2. Все записи должны делаться последовательно несмываемыми чернилами.

3. Страницы тетради должны быть последовательно пронумерованы.

4. Каждая запись должна сопровождаться датой. При этом дата не должна быть двояко трактуемой. Запись «09 мая 2004 г.» лучше, чем «9/5/2004».

5. Если в предшествующие записи вносятся изменения, то эти изменения должны сопровождаться простановкой даты.

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

7. Законченный материал должен быть помечен символами «X» или «Z» для уверенности, что ничего не было добавлено позже.

2.6.2. Содержание записей

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

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

2.7. Блок схемы алгоритмов

Теория.  Универсальный язык моделирования (Unified Modeling Language — UML) — это язык для определения, представления, проектирования и документирования программных систем. Основными составляющими языка UML являются элементы, связи, механизмы расширения и диаграммы. Универсальный язык моделирования предоставляет разработчику метод графической иллюстрации и имитационного моделирования системы, которая основана на программном принципе управления. Этот язык позволяет стандартизировать графическое изображение операций в системе с целью моделирования ее алгоритма работы в общем виде, без составления исходного текста управляющей программы. Универсальному языку моделирования посвящены более 100 научных монографий. Мы рассмотрим лишь малую часть сведений об этом языке, которые будут использованы нами для проектирования встраиваемых систем на протяжении всей этой книги. Если Вас будет интересовать получение более широких сведений по этой теме, обратитесь к литературе, рекомендованной в конце главы.

Свою историю универсальный язык моделирования ведет с начала 90х годов. В 1994 году Грэйди Буч (Grady Booch), Джеймс Рэмбо (James Rambaugh) и Ивар Якобсон (Ivar Jacobson) начали объединять несколько методов объектно ориентированного моделирования в фирме Rational Software. Их целью была разработка методов сокращения времени реализации программных продуктов для промышленности. И уже в 1995 году была представлена спецификация метода, названного «Unified Method». Первая версия универсального языка моделирования была принята консорциумом OMG (Object Management Group) в январе 1997 года. Утвержденная же в сентябре того же года версия UML 1.1 была принята на вооружение основными компаниями — производителями программного обеспечения, такими, как Microsoft, IBM, Hewlett Packard.

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

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

Основные типы операторов представлены на рис. 2.6. Программа начинается с оператора начального запуска и заканчивается оператором останова. Множество различных действий совершается под управлением программы в процессе ее выполнения. Каждое действие отображается оператором процесса, который производит изменение значения, формы представления или расположения данных. Оператор процесса может иметь любое количество входов, но только один выход. Переход от одного оператора к другому обозначается стрелкой. Если в процессе выполнения очередного действия производится анализ некоторого внешнего сигнала или внутреннего состояния программы с последующим выбором, по какому пути продолжить исполнения программы, то такое действие отображается условным оператором (другое название — оператор решения). Условный оператор имеет один вход и несколько выходов. После выполнения действий условного оператора программа может «избрать» только один путь. Поэтому условия, по которым определяется направление выхода из оператора решения, должны быть взаимоисключающими. Оператор слияния (поглощения), в соответствие со своим названием, позволяет соединить несколько отдельных ветвей алгоритма в одну. В завершение мы включили два оператора, которые характерны для структурного программирования. Это операторы ветвления и объединения, которые предназначены для отображения работы систем с параллельными вычислителями [2,3]. В качестве первого примера использования условных графических обозначений UML мы представили средствами универсального языка моделирования процесс структурного проектирования, блок схема алгоритма которого приведена на рис. 2.7. На рис. 2.8 тот же процесс представлен с большей степенью подробности, что немедленно привело к усложнению блок схемы алгоритма.

Рис. 2.6. Условные графические обозначения операторов универсального языка моделирования UML

Рис. 2.7. Блок схема алгоритма структурного проектирования

Рис. 2.8. Блок схема алгоритма разработки и тестирования программного обеспечения встраиваемой системы