Educational Technology & Society 5(4) 2002
ISSN 1436-4522
pp. 189-213

Формализация проектирования программного обеспечения и ее использование в учебном процессе

Нуриев Н.К.
Казанский государственный технологический университет,
Казань, Россия
Nurievnk@mail.ru

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

Ключевые слова
объектно-ориентированное проектирование, формализация проектирования, UML, программирование, обучение проектированию, тестирование.

 

Введение

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

Формализованное определение модели

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

Таким образом, формируется дискретное пространство объектов, в которой существуют модели. Это пространство имеет иерархическую структуру от метоуровня до микроуровня. За нулевой уровень иерархии в этом пространстве взят уровень объектов из предметной области, в котором синтезируется модель.

Формализованное описание проектирования программного обеспечения

Рассмотрим предметную область с уровнем объект - компьютер. Рассмотрим реальный процесс этого же уровня, где компьютер играет определенную роль. Из (0) - модели выберем элемент, обозначим ее как .
В модели M1(0) локализуем участок семантической сети, семантически содержащий объект - компьютер вместе с другими объектами этого иерархического уровня объектов. Иными словами, выделим среду использования компьютера, обозначим ее через M2(0): . По своей сути модель M2(0) является проектом с интеграцией масштаба (0) или (0)-проектом (ноль-проектом) программного обеспечения компьютера, т. е. это участок семантической сети, содержащий объект компьютер.
Как известно, любой проект должен быть реализован, а чтобы он был реализован, он должен быть понят исполнителем. В этом случае в качестве исполнителя выступает компьютер. Поэтому на базе проекта M2(0) пройдет сложный путь декомпозиций до представления его на транслируемом языке. Этот процесс можно представить как итерационный процесс с синтезом элементов, т.е. M2(0), M2(1), M2(2), M2(3), ..., M2(k), ..., где проект на шаге номер i. На шаге номер k проект может быть реализован на компьютере. Весь процесс синтеза последовательности M 2(0), M2(1), ..., M2(k), ..., M2(n), называется проектированием. Таким образом, проектирование до шага номер k делается вручную, а с k -го шага транслируется компьютером до исполняемого кода. Следовательно, чем мощнее транслятор, тем меньше по значению будет величина k , и тем больше можно будет автоматизировать проектирование, т.е. тем меньше конкретизировать семантическую сеть. И на рис. 1 приводится нотация процесса проектирования.


Рис. 1.
Каждая декомпозиция уникальна в своем роде. Каждый раз на каждой иерархической ступени декомпозиции приходится снова решать задачу проектирования в новых условиях. Поэтому следует выработать некоторые общие принципы, которых будем придерживаться при декомпозиции. Эти принципы в дальнейшим будут определять методологию проектирования как процесса, т. е. какие будут заложены в проектирование принципы, такова будет его методология. Если несколько обобщить, взятая современная методология держится на принципе "копирования" закономерностей организации систем из реалии т.е. на принципе копирования закономерностей у естественных организаций. Очевидно, все закономерности естественных организаций скопировать невозможно, поэтому взяты только некоторые закономерности:
  1. Каждый объект имеет определенную интеграцию и в зависимости от степени интеграции занимает определенное место в предметной области, как показано на рис. 2.

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

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

Рассмотрим связи "связь" между объектами в семантической сети конкретной модели с позиции экземпляра объекта, например, на рис. 3. Связи имеются непосредственные с этим объектом и опосредованные. Выделим эти связи как показано на рис. 3 и назовем: 1) внутриобъектная связь; 2) внутриуровневая связь; 3) межуровневая связь.

Рис. 3.

На качественном уровне разделим типы связей на несложные и сложные:
  1. Несложные системы. Действие между двумя объектами назовем простым, если алгоритм его исполнения является несложным на иерархическом уровне этих объектов и не требует организации сложных алгоритмов на других, более низких иерархических уровнях. Если связи "связь" между объектами можно представить как тип простого действия, то семантическую связь "связь" назовем простой. Примерами могут служить связи типа "соответствует", "содержит" на иерархическом уровне объектов Microsoft Access при организации базы данных. Модели, содержащие связи не более чем простые назовем несложными информационными системами. Это исходит из того, что формализовать эту связь - процедуру, довольно просто.
  2. Сложные системы. Если тип связи между объектами в модели более чем простой, то такие модели назовем сложными информационными системами.

Примером моделей с простыми связями являются модели база данных. В моделях базы данных связи между объектами можно представить так:
  1. На одном иерархическом уровне связь вида
    По терминологии базы данных эту связь называют (1:1) - один к одному.
  2. На разных иерархических уровнях связь вида:

По терминологии в базах данных эту связь называют (1: )- один ко многим .
Все остальные связи в базах данных реализуются через эти связи, и других типов связей нет.
Таким образом, базы данных относятся к несложным информационным системам. В несложных информационных системах может быть более большой набор разновидностей связей типа "действия". Для конкретизации рассмотрим пример проектирования программного обеспечения (с комментариями по методике).
Рассмотрим предметную область педагогика. В этой предметной области объекты: студент, экзамен, билет, экзаменационная ведомость, зачетная книжка, оценка, вопрос, ответ, преподаватель. Кто работает (учится) в этой предметной области, знает семантическую сеть связей этих объектов и их содержание, т.е. у него имеется когнитивная карта предметной области [Кордуэлл М., 1999]. В этой предметной области рассмотрим реаль: процесс сдачи экзамена . Построим модель этого процесса. Модель представим в виде графической нотации рис. 4 типа объект-связь (инкапсулированная сущность - связь). Очевидно эту же модель можно описать и на русском языке (используя повествовательную форму).

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

Рис. 5.
Моделирование на языке "нотаций" требует постоянной детализации (объектно-ориентированной декомпозиции) модели, т.е. выделения и конкретизации отдельных эпизодов. Как, например, показано на рис 6.

Рис. 6.
Для детализации нотации необходимо рассматривать объекты из другой предметной области - информационные технологии: Microsoft Excel, Книга, Лист 1, Лист 2, Модуль 1, Модуль 2, Макрос, интерфейс, база данных, вопросы, VB проект. Эта нотация показана на рис. 7.

Рис. 7. Нотация связи объектов
И в этой нотации произведем дальнейшую детализацию объектов и их связей как показано на рис. 8.

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

Рис. 9.
Для описания структуры БД необходимы объекты другой предметной области - базы данных со своими объектами: таблица, поле, связь (1: ) и т.д. На рис. 10 показана нотация структуры базы данных масштаба 1.1.1. Начиная с этого уровня легче описать модель объектами предметной области объектно-ориентированного программирования, например, Microsoft Visual Basic.

Рис. 10.
Итак, вернемся к проектированию как процессу в целом. Как показано на рис. 1, проектирование в ручном варианте заканчивается на шаге номер k в итерационном процессе декомпозиций. Как вычислить это число k ? Рассмотрим три случая: первый случай. Допустим в нашем распоряжении CASE - средство Rational Rose [Трофимов С.А., 2001], и мы довели процесс декомпозиции до определенного числа k , где все записано и представлено на языке UML (стандартизованные формы семантической сети) [Буч Г., 1999]. В этом случае, начиная с шага k , проектирование как процесс полностью формализовано. Второй случай. У нас нет CASE - средств и в распоряжение Microsoft Visual Basic и Microsoft Office (VB +Office).
В этом случае придется делать больше шагов k1, где k1>k ручного проектирования т.к. объекты VB + Office обладают объектами с меньшей интеграцией и средствами их связывания (рис. 11).

Рис. 11.
Третий случай. У нас имеются CASE - средства, но в любой библиотеке объектов нет нам нужного инкапсулированного объекта, тогда придется решать дополнительную задачу создания инкапсулированного нового объекта из нового класса и заносить в библиотеку объектов, т.е. в этом случае, какие бы не были мощные средства, ассемблер тоже может понадобиться. Проектирование - сложный процесс, и на разных этапах приходится решать разные задачи, и для поиска решений в этих проектных задачах приходится организовывать побочные вспомогательные процессы (проектирование). Такие локальные процессы называются прототипными. Прототип проекта - это упрощенный проект (или особо выделенный эпизод проекта) с целью поиска оптимальных решений при проектировании. При построении прототипов обычно идут по двум путям, которые исследуют разные цели. Первый путь исследовательский, а второй - коммерческий. В исследовательских прототипах обычно обрабатывают ядро проекта (его основную идею) и мало обращают внимание на интерфейсную часть. При коммерческом подходе, наоборот, большее внимание обращают на развитие интерфейсной части в целях рекламы будущего программного продукта.
На рис. 12 приводится нотация зацикленного (итеративного) процесса проектирования программного обеспечения.

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

Рис. 13. Жизненный цикл информационной системы

Выводы

Проведен системный анализ проектирования как процесса. Сделаны следующие выводы:

  1. Проектирование программного обеспечения как процесс состоит из двух частей: проектирование среды использования программного обеспечения; проектирование самого программного обеспечения. И должен быть объектно-ориентированный переход, т.е. объектно-ориентированная связь между средой и программным обеспечением. Чтобы поддержать эту целостность, обязательно должно быть проведено проектирование среды использования с достаточным количеством декомпозиций (детализаций).
  2. Проектирование среды использования программного обеспечения останется прерогативой ручного проектирования (сугубо творческой работой). Проектирование самого программного обеспечения постепенно на себя возьмут CASE -средства.
  3. Процессы декомпозиции при проектировании и при обучении проектированию по сути разные. При обучении проектированию должна быть "прототипная" декомпозиция (в исследовательском смысле), внутри прототипной еще прототипная и т. д. Таким образом, в основу обучения объектно-ориентированному проектированию должен быть положен объектно-ориентированный подход. Только такая ориентация может сформировать объектно-ориентированный подход как "философию" проектирования. Суть объектно-ориентированного подхода в обучении - это обучать проектированию по схеме: "что надо делать", а "как надо делать"- во многом оставлять на самостоятельную работу.
  4. Проведенные эксперименты по обучению проектированию объектно-ориентированным подходом студентов по специальности "Информационные системы и технологии" показывают, что обучаемые должны иметь достаточный интеллектуальный уровень. В противном случае годится только структурный подход, при котором необходимо все время учить "что делать и как делать", но при этом подходе к обучению основное время уходит на то, чтобы научить "как делать". С точки зрения методики преподавания проектирования, важно найти эту грань - балансное состояние между тем, сколько давать "что делать" и сколько давать "как делать".
  5. Идеологи и проектировщики программного обеспечения больших и сложных систем (БСС) выработали и активно продолжают развивать методологию БСС. В учебном процессе доминирует эта идеология и остается в тени методология проектирования программного обеспечения уровня фирм, производств, бизнес - процессов, которая имеет свою специфику и свою востребованность.
Будущие специалисты по проектированию программного обеспечения будут "жить", как правило, в среде уровня фирм и решать задачи проектирования программного обеспечения, т.е. заниматься проектированием программного обеспечения несложных информационных систем (НИС), и им необходимо знать эту специфику.
Можно утверждать, что задача проектирования программного обеспечения в пространстве офиса является актуальной, т.е. специалисты из области информационных технологий - востребованы. Причин к этому много, во-первых, развитие самих бизнес - процессов, технологий, массовая информатизация и т. д. С другой стороны, у специалистов из других областей деятельности не хватит "компьютерной" культуры для синтеза дешевого, мобильного, легко-адаптируемого программного обеспечения, которого требуется с каждым днем больше и больше. Несмотря на старания создателей Microsoft Office сделать эту среду доступной для широкого круга пользователей, знаний инструментальных и пользовательских систем Microsoft WORD, Microsoft EXCEL, Microsoft ACCESS, ... явно недостаточно, т. е. все время возникает потребность знания основ моделирования, проектирования, программирования. Эту среду востребованной деятельности назвали прикладным проектированием программного обеспечения несложных информационных систем. При проектировании несложных систем, вырабатывается своя методика и технология, которая вообще-то отличается от технологии проектирования программного обеспечения больших и сложных систем. БСС создают группа специалистов разного уровня с использованием различных специализированных инструментальных средств проектирования (UML, CASE - средства). На рис. 14 (данные ЗАО "Ланит - Терком" 1999 г., http://www.terkom.ru/real) видно, хотя бы на качественном уровне, какие системы выгодно проектировать вручную, а какие - с использованием CASE - средств.

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

Приложение

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


Рис. 15.
Сделаем декомпозицию.

Рис. 16.
Для стимулирования самостоятельности работы обучаемого при проектировании программного обеспечения, вводится система дозированной выдачи информации (подсказок в виде прототипов к решению задач по проектированию на каждом шаге декомпозиции) с прогрессирующими штрафными баллами за каждый полученный дополнительный прототип (кроме нулевого прототипа). Сделанный проект оценивается на сто баллов за минусом всех штрафных баллов, которые получил обучаемый при проектировании. Конкретный вид прототипа приводится в примере.
Пример. Проектируется оболочка для организации тестового контроля знаний. Рассмотрим эпизод.
Задача: Из редактора Microsoft Word необходимо импортировать в систему Microsoft Access базу данных задач, содержащих OLE - объекты, как показано на рис. 17.

Рис. 17.
Для решения поставленной задачи обучаемый в качестве помощи получает прототип решения этой задачи преподавателем.

Прототип решения задачи преподавателя (прототип 0)

Задача. Содержимое файла WORD ("Файл WORD.Doc") необходимо поместить в ячейку таблицы Access.
Дано: Содержимое файла с именем "Файл WORD.Doc"
А1. Упростить и вычислить при
1) 0;      2) -10;      3) -20;      4) -30;      5) -40.

Решение:

  1. Создаем таблицу Access " ОбъектТабл " со следующей структурой:
  2. Создаем форму в режиме "Создание формы в режиме мастера"

    Результат:
  3. В режиме "Конструктор" в созданную форму помещаем "Кнопку4" с надписью "Загрузка"
    В свойстве кнопки установим событие:
  4. Факт нажатия кнопки поддерживается процедурой обработки события:

    Private Sub Кнопка4_Click()
         Call Переход
    End Sub

    "Переход" название процедуры в модуле "Module1" со следующим содержимым:
    Результат:
    Результат: отчет созданный в режиме "Автоотчет: в столбец" выглядит следующем образом:

Прототип решения задачи преподавателя (прототип 0.1)

Комментарий. Этот прототип, обучаемый получает со штрафными баллами.
Задача: Имеется база данных задач (два файла: Мат_А1.doc, Мат_А2.doc ) в Microsoft Word следующей структурой:
Мат_А1.doc
А1. Упростить и вычислить:
1) 20,5 ;      2) 5,25 ;      3) 10,5 ;      4) 7 ;      5) 21.
А1. Упростить и вычислить при
1) 0 ;      2) -10 ;      3) -20 ;      4) -30 ;      5) -40.
Мат_А2.doc
А2. Решить неравенство:
1) -1 ;      2) 0 ;      3) 1 ;      4) -2 ;      5) -3.
А2. Найти наименьшее целое положительное решение неравенства: 1) 4 ;      2) 8 ;      3) 6 ;      4) 5 ;      5) 3.
В каждом файле содержится задачи только по одной теме.

Требуется : Импортировать этих задачи в реляционную базу задач Microsoft Access со следующей структурой и содержанием:






Решение:
Организуем форму с подчиненной формой для таблиц "Темы" и "Задачи" с помощью мастера (эту задачу можно решить только через форму).

Функционирование кнопок поддерживаются соответствующими процедурами:

Private Sub Загрузить_Click()
    Call ЗагрузкаЗадачСФайлаWORD
End Sub

Private Sub Назад_Click()
    DoCmd.Quit
End Sub

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

Public Sub ЗагрузкаЗадачСФайлаWORD()

    Dim dbCur As Database
    Dim rs As DAO.Recordset
    Dim WA As Object
    Dim NameFile As String

    Set dbCur = CurrentDb

    NameFile = Form_Темы.ИмяФайла ' Считываем полный путь к файлу


    КодТемы = Form_Темы.КодТемы ' Считываем код темы


    MsgBox "Путь" & " " & NameFile
    MsgBox "КодТемы" & " " & КодТемы


    Set WA = CreateObject("word.application") ' Создаем объект WORD


    WA.Documents.Open NameFile 'Открываем файл с задачами


    WA.Documents.Open "C:\Мои документы\ud\Прототип 1\Temp.doc" 'Открываем временный файл
    WA.Visible = True 'Делаем видимым открытые документы


    For i = 1 To 2 'Организуем цикл по двум файлам
    With WA


        Windows(2).Activate ' Активизируем файл с задачами


        .ActiveDocument.Tables(1).Cell(i, 1).Select 'Выделяем ячейку таблицы с номером (i, 1)

        Selection.Copy ' Копируем выделенную область таблицы

        Windows(1).Activate ' Активизируем временный файл

    Selection.Paste ' Вставляем скопированное выше

         ' Сохраняем временный файл
        ActiveDocument.SaveAs FileName:="C:\Мои документы\ud\Прототип 1\Temp.doc"
    End With

    Form_ЗадачиПодчиненнаяФорма.Задачи.SetFocus
    Form_ЗадачиПодчиненнаяФорма.Задачи.SourceDoc = "C:\Мои документы\ud\Прототип_ 1\Temp.doc"
    Form_ЗадачиПодчиненнаяФорма.Задачи.Action = acOLECreateEmbed

    WA.Windows(1).Activate

    WA.Selection.WholeStory 'Выделить все

    WA.Selection.Delete 'Удалить выделенное

    Form_ЗадачиПодчиненнаяФорма.КодТемы.SetFocus
    Form_ЗадачиПодчиненнаяФорма.КодТемы = Val(КодТемы)

    DoCmd.DoMenuItem acFormBar, acRecordsMenu, 5, , acMenuVer70 'Обновление данных формы

    DoCmd.GoToRecord , , acNewRec ' Создаем новую запись
    Next

    WA.Documents.Close 'Закрываем все открытые документы

    WA.Application.Quit ' Закрываем объект WORD
End Sub Результат:


Решение задачи обучаемым должно быть примерно таким:
Дано:
А1. Упростить и вычислить при
1) 0;      2) -10;      3) -20;      4) -30;      5) -40.
А1. Упростить и вычислить:
1) 20,5      2) 5,25;      3) 10,5;      4) -7;      5) 21.
А1. Упростить и вычислить при
1) 8;      2) 7;      3) -8;       4) -7;      5) 3.
А1. Упростить и вычислить при
1) 4;      2) -4;      3) -0,25;      4) 0;      5) 0,25.
Решение:


Private Sub Загрузить_Click()
    Call ЗагрузкаЗадачСФайлаWORD
End Sub


Public Sub ЗагрузкаЗадачСФайлаWORD()
    Dim dbCur As Database
    Dim rs As DAO.Recordset
    Dim WA As Object
    Dim task As Variant
    Dim rans As Variant
    Dim n As Integer
    Dim mass As Variant
    Dim NameFile As String
    Dim NameDOC As String

    Set dbCur = CurrentDb
    NameFile = dbCur.Name

    'Вычисление путей
    Dim poz As Integer
    Dim pozj As Integer
    Dim NPath As String

    poz = -1

    'Найти \
    For pozj = Len(NameFile) To pozj Step -1
        If Mid(NameFile, pozj, 1) = "\" Then
            poz = pozj
            Exit For
        End If
    Next pozj


    'Выделение пути доступа к файлу из полного имени
    If poz <> -1 Then
        NPath = Left(NameFile, poz - 1)
    End If


    MsgBox "Путь" & " " & NPath
    NameDOC = Form_Темы.ИмяФайла
    COD = Form_Темы.КодТемы

    MsgBox "Имя файла" & " " & NameDOC
    MsgBox "КодТемы" & " " & КодТемы

    Set WA = CreateObject("word.application")
    WA.Documents.Open NPath & "\" & NameDOC & ".doc"

    WA.Documents.Open NPath & "\" & "Temp.doc" 'Временный файл вопроса
    n = InputBox("Введите количество задач ")
    For i = 1 To n
        With WA

            .Windows(2).Activate
            .ActiveDocument.Tables(1).Cell(i, 1).Select
            rans1 = .ActiveDocument.Tables(1).Cell(i, 2)
            .Selection.Copy
            .Windows(1).Activate
            .Selection.Paste
            .ActiveDocument.SaveAs FileName:=NPath & "\" & "Temp.doc"
        End With

        Form_ЗадачиПодчиненнаяФорма.Задачи.SetFocus
        Form_ЗадачиПодчиненнаяФорма.Задачи.SourceDoc = NPath & "\" & "Temp.doc"
        Form_ЗадачиПодчиненнаяФорма.Задачи.Action = acOLECreateEmbed

        WA.Windows(1).Activate
        WA.Selection.WholeStory 'Выделить все
        WA.Selection.Delete 'Удалить выделенное

        Form_ЗадачиПодчиненнаяФорма.КодВарРеш.SetFocus
        Form_ЗадачиПодчиненнаяФорма.КодВарРеш.Text = Val(rans1)
        Form_ЗадачиПодчиненнаяФорма.КодТемы = Val(COD)
        'Обновление данных формы
        DoCmd.DoMenuItem acFormBar, acRecordsMenu, 5, , acMenuVer70

        DoCmd.GoToRecord , , acNewRec
    Next
    WA.Documents.Close
    WA.Application.Quit
End Sub

Результат:

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

Литература

[Одинцов И., 2002] Одинцов И. Профессиональное программирование. Системный подход. - СБб.: БХВ - Петербург, 2002 г.-521 с., ил
[Трофимов С.А., 2001] Трофимов С.А. CASE - технологии и практическая работа на Rational Rose. М: "Издательство БИНОМ", 2001 г. - 267 с., ил
[Буч Г., 1999] Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++, 2 - е изд./Пер. с англ. - М.: "Издательство - БИНОМ", СПБ. "Невский диалект", 1999 г.- 560 с., ил
[Кордуэлл М., 1999] Кордуэлл М. Психология. М.: "Издательство ГРАНД ", 1999 г.- 442 c.