CC BY
88
Educational Technology & Society 5(4) 2002 ISSN 1436-4522
Формализация проектирования программного обеспечения и ее использование в учебном процессе
Нуриев Н.К.
Казанский государственный технологический университет,
Казань, Россия Nurievnk@mail. ru
АННОТАЦИЯ
В работе проведен системный анализ проектирования как процесса. Сделана попытка оценить состояние проектирования как процесса на качественной шкале степени формализации от методологии до математизации. Проектирование - многостадийный процесс и поэтому можно сказать, что некоторые стадии формализованы полностью до математического уровня, некоторые - в переходе, а некоторые вообще формализации не поддаются в принципе и останутся на уровне методологии. Для изучения и обучения переходные стадии проектирования являются самыми интересными стадиями и особый упор сделан именно на них и их использование в учебном процессе.
Ключевые слова
объектно-ориентированное проектирование, формализация проектирования, UML, программирование, обучение проектированию, тестирование.
Введение
Проектирование программного обеспечения, как процесс творческий, относится к плохоформализуемым процессам. Главными характеристиками любой системы является ее структура и закономерности ее функционирования, а одним из самых надежных путей исследования - формализация. Только при формализации выкристаллизовывается структура и закономерности функционирования систем, которые могут быть записаны на формальном математическом языке. Успех процесса обучения какой - либо науке также зависит от степени формализованности этой науки. Поэтому почти все науки стараются представить результаты своих исследований на математизированном языке. Чтобы познавать и обучать необходима формализация, нет формализации - нет технологии, но не все можно формализовать к несчастью или к с частью, и тогда процесс формализации происходит на уровне методологии. Исследуемый объект - проектирование как процесс в этой шкале формализации от методологии до математизации делает значительные шаги в сторону математизации. И в данном исследовании это хотелось показать. Примечательно и то, как отмечается в работе [Одинцов И., 2002], что западная школа проектирования имеет инженерное начало (более методологическое), а наша -математическое (более формализованное), но в формализации у западной школы успехов оказалось больше. Во всем этом, видимо, большое значение имеет востребованность проектирования как процесса обществу и там это востребованность выше, чем у нас, но это не означает, что в процессе обучения проектированию нам необходимо перейти на инженерное начало.
Формализованное определение модели
Определение понятия модели реалии (объекта) может быть в широком смысле, как любое представление этого объекта, зафиксировано в какой либо форме. В узком смысле определим понятия модели следующим образом:
- Любая предметная область состоит из конечного множества объектов
П ( 0 ) = {о (1 ), ю ( 2 ), о (п) }
- Объекты связаны между собой по смыслу (семантически) связями типа
Д* О*! О отношения й? (■/,)() V ),к
где обозначение «отношения» будет трактоваться так: в пределах предметной области каждый объект ю(1) V i имеет какое-то отношение к объекту ю( ]) V j. Отношения «отношения» могут быть реализованы и не реализованы в рассматриваемый момент времени. Реализованные «отношения» превращаются в связь с обозначением «связь». В свою очередь, «связь» может иметь любую природу: быть процедурой, процессом, функциональной связью, стохастической связью, приказом и т. д., а также «связь» может быть разрушена и переведена в «отношения».
- На множествах О(0), 5(0) имеется множество М(0) семантических сетей, состоящих из реализованных и нереализованных отношений в фиксированный момент времени, т.е. в статике.
да
М(0) =< >чр СТНОШТНКЯ ® (^)
ш (к>
- Любой элемент множества М(0) называется моделью с интеграцией масштаба (0) или (0)-моделью (ноль - моделью) в предметной области. На базе элемента М(0) можно организовать процессы, т.е. когда элементы множества М(0)
дтятгслия 0) ) V І, ]
все упорядочены во времени и «отношения» заменены на «связь». Например, можно взять конкретную модель М1(0) и на ней организовать множество процессов
Р1(0)={р(0Д),/7(0,2), ..., р(0,к)}
где Р1(0) является имитационной моделью модели М1(0), т. е. модель М1(0) в динамике преобразуется в модель Р1(0). Нотацию элемента номер к множества Р1(0) будем обозначать так:
Элемент множества О (0) с номером 1, т.е. ю(1) организован точно так же, как само множество О (0) . В свою очередь, объект О (0) является объектом - элементом другого абстрактного множества с интеграцией масштаба (-1) т.е. за ноль отсчета взят масштаб предметной области. Аналогично, предполагается, что существуют в абстракции масштабы интеграции (-2), (-3) ..., т.е. метоуровни -1, -2, -3, ... . Таким образом, объекты вложены и «вширь», и «вовнутрь», каждый внутренний объект ю(0 V 1 состоит из множества объектов
О (0 ,1) = {ю (1,1), ю (1,2 ), ю (1, т) }
- Объекты связаны семантически между собой связями типа
&тнешення
«?«рк> V ?,к
Аналогично, на множествах О (0,1) , 8(0,1) построено множество М(0,1) семантических сетей вида:
М(0,1 ) —
отношг кия
юО,к)
- Любой элемент множества М(0,1) называется моделью объекта с номером 1, 1 = 1, т с интеграцией масштаба (0, 1) или (0, 1) - моделью (ноль-и - моделью). Совершенно аналогично, определяется (0, 1, j) -модель с интеграцией масштаба (0, 1, ]) и т. д. Этот процесс может продолжаться бесконечно.
Таким образом, формируется дискретное пространство объектов, в которой существуют модели. Это пространство имеет иерархическую структуру от метоуровня до микроуровня. За нулевой уровень иерархии в этом пространстве взят уровень объектов из предметной области, в котором синтезируется модель.
Формализованное описание проектирования программного обеспечения
Рассмотрим предметную область О (0) с уровнем объект - компьютер. Рассмотрим реальный процесс этого же уровня, где компьютер играет определенную роль. Из (0) - модели выберем элемент, обозначим ее как М 1(0) с М(0).
В модели М1(0) локализуем участок семантической сети, семантически содержащий объект - компьютер вместе с другими объектами этого иерархического уровня объектов. Иными словами, выделим среду использования компьютера, обозначим ее через М2(0): М2(0) с М 1(0). По своей сути модель М2(0) является проектом с интеграцией масштаба (0) или (0)-проектом (ноль-проектом) программного обеспечения компьютера, т. е. это участок семантической сети, содержащий объект компьютер.
Как известно, любой проект должен быть реализован, а чтобы он был реализован, он должен быть понят исполнителем. В этом случае в качестве исполнителя выступает компьютер. Поэтому на базе проекта М2(0) пройдет сложный путь декомпозиций до представления его на транслируемом языке. Этот процесс можно представить как итерационный процесс с синтезом элементов, т.е.
М2(0), М2(1), М2(2), М2(3), ..., М2(к), ..., где М 2(1), 1 = 0, к проект на шаге номер
1. На шаге номер к проект может быть реализован на компьютере. Весь процесс синтеза последовательности М2(0), М2(1), ..., М2(к), ..., М2(п), называется проектированием. Таким образом, проектирование до шага номер к делается вручную, а с к-го шага транслируется компьютером до исполняемого кода. Следовательно, чем мощнее транслятор, тем меньше по значению будет величина к, и тем больше можно будет автоматизировать проектирование, т. е. тем меньше конкретизировать семантическую сеть. И на рис. 1 приводится нотация процесса проектирования.
Рис. 1.
Каждая декомпозиция уникальна в своем роде. Каждый раз на каждой иерархической ступени декомпозиции приходится снова решать задачу проектирования в новых условиях. Поэтому следует выработать некоторые общие принципы, которых будем придерживаться при декомпозиции. Эти принципы в дальнейшим будут определять методологию проектирования как процесса, т. е. какие будут заложены в проектирование принципы, такова будет его методология. Если несколько обобщить, взятая современная методология держится на принципе «копирования» закономерностей организации систем из реалии т.е. на принципе копирования закономерностей у естественных организаций. Очевидно, все закономерности естественных организаций скопировать невозможно, поэтому взяты только некоторые закономерности:
1. Каждый объект О (♦) имеет определенную интеграцию и в зависимости от степени интеграции занимает определенное место в предметной области, как показано на рис. 2.
Рис. 2.
Объект является неделимой системой на своем иерархическом уровне. У объекта на этом иерархическом уровне доступен только интерфейс (таким образом, объект является инкапсулированной сущностью на определенном иерархическом уровне с определенной интеграцией). Объект состоит из таких же по устройству объектов. Поэтому с точки зрения объекта есть доступ к объектам, его составляющим, только через их интерфейсы. Допустим, объекту из определенного иерархического уровня требуется решить какую - либо задачу. Для решения этой задачи объект привлекает объекты своего внутреннего содержания, непосредственно следующие ниже по иерархии. И каждый объект, привлеченный к решению задачи (стратегической) имеет свою задачу (тактическую). Объект при решении задачи на каждом иерархическом уровне придерживается определенных закономерностей:
1 . Объект может обращаться к объектам внутреннего содержания, стоящим по иерархии ниже только на одну ступень.
2. Объект может порождать экземпляры объектов, стоящих по иерархии ниже только на одну ступень. Порожденные экземпляры объектов должны обладать свойствами:
2.1. Наследственностью, т. е. сохранять свойство “родителя” и могут иметь дополнительные.
2.2. Полиморфизма, т. е. порожденных объектов могут иметь разные формы - как между собой так и от “родителя”.
2. Объекты отнесены к определенным классам, например, объект класса ©(♦.♦) включает все объекты, расположенные ниже по ветвям
иерархического дерева. Название класса экземпляра объекта соответствует названию иерархического уровня непосредственно ему предшествующему, откуда экземпляр исходит. Например, экземпляр ю(0.1.2.1) из класса ю(0.1.2) а экземпляр ю(0.1.2.2) тоже из этого класса.
Эта закономерность выделена контуром. Экземпляры объекта ю(0.1.2.1), ю(0.1.2.2), ... - наследники родителя экземпляра
ю(0.1.2) .
Таким образом, можно сделать вывод: вся современная методология объектноориентированного проектирования держится на одном принципе - копирования закономерностей организации естественных систем и в качестве основных закономерностей выдвигаются следующие: инкапсуляция, наследие, полиморфизм. В результате получаем итеративную, семантически замкнутую методологию синтеза проекта на любом иерархическом уровне и в иерархической системе предметной области.
Вследствие этого, спроектированный по данной методологии объект - проект (программное обеспечение) должен обладать свойствами инкапсулированности объектов системы и все взаимоотношения между объектами должны быть решены с соблюдением закономерностей инкапсуляции, наследия, полиморфизма.
Программный продукт (проект) должен быть в целом организован по принципу естественной организации «как мир вокруг».
Итак, получили системные требования к организации конечного продукта (программного обеспечения).
Обратимся к отношению «отношения» и реализуем эти отношения в связь «связь», т.е. в определенную процедуру, в результате реализации которой должно произойти событие, например:
Excel
активизирует
Лис
Рассмотрим связи «связь» между объектами в семантической сети конкретной модели с позиции экземпляра объекта, например, ю(0.1.2.1) на рис. 3. Связи имеются непосредственные с этим объектом и опосредованные. Выделим эти связи как показано на рис. 3 и назовем: 1) внутриобъектная связь; 2) внутриуровневая связь; 3) мсжуровнсвая связь.
1} л*о. 1.2.1; 2) «<011-2.1)
связь
CBA3L
0(0.1.2.1.1) сн<0,1.2)
ш((У1.1)
Рис. 3.
На качественном уровне разделим типы связей на несложные и сложные:
1. Несложные системы. Действие между двумя объектами (o(i) и o(j) назовем простым, если алгоритм его исполнения является несложным на иерархическом уровне этих объектов и не требует организации сложных алгоритмов на других, более низких иерархических уровнях. Если связи «связь» между объектами можно представить как тип простого действия, то семантическую связь «связь» назовем простой. Примерами могут служить связи типа «соответствует», «содержит» на иерархическом уровне объектов Microsoft Access при организации базы данных. Модели, содержащие связи не более чем простые назовем несложными информационными системами. Это исходит из того, что формализовать эту связь - процедуру, довольно просто.
2. Сложные системы. Если тип связи между объектами в модели более чем простой, то такие модели назовем сложными информационными системами.
Примером моделей с простыми связями являются модели база данных. В моделях базы данных связи между объектами ю(/) и о( у) можно представить так:
1. На одном иерархическом уровне связь вида
оХг)
с о о гв етству ег
Ш)
По терминологии базы данных эту связь называют (1:1) - один к одному.
2. На разных иерархических уровнях связь вида:
ЩШ 1)
|М2)
&>(/, п)
По терминологии в базах данных эту связь называют (1:®)- один ко многим.
Все остальные связи в базах данных реализуются через эти связи, и других типов связей нет.
Таким образом, базы данных относятся к несложным информационным системам. В несложных информационных системах может быть более большой набор разновидностей связей типа «действия». Для конкретизации рассмотрим пример проектирования программного обеспечения (с комментариями по методике).
Рассмотрим предметную область педагогика. В этой предметной области объекты: студент, экзамен, билет, экзаменационная ведомость, зачетная книжка, оценка, вопрос, ответ, преподаватель. Кто работает (учится) в этой предметной области, знает семантическую сеть связей этих объектов и их содержание, т.е. у него имеется когнитивная карта предметной области [Кордуэлл М., 1999]. В этой предметной области рассмотрим реаль: процесс сдачи экзамена. Построим модель этого процесса. Модель представим в виде графической нотации рис. 4 типа объект-связь (инкапсулированная сущность - связь). Очевидно эту же модель можно описать и на русском языке (используя повествовательную форму).
В рассматриваемом модели нет необходимости в построении программного обеспечения, т.к. нет автоматизированного процесса с использованием компьютера. Изменим ситуацию, в этой же предметной области рассмотрим объекты: преподаватель, студент, экзамен, билет, ведомость, оценка, вопрос, ответ, компьютер. Построим модель процесса сдачи экзамена (рис. 5).
Рис. 5.
Моделирование на языке «нотаций» требует постоянной детализации (объектно-ориентированной декомпозиции) модели, т.е. выделения и конкретизации отдельных эпизодов. Как, например, показано на рис 6.
Компьютер енерисувт '"^3— — Eitner
Компьютер Огні
К ГЬЫ111. ЫП Г Н11Ї BMDMt Оліиш
4)
КйЫПЫОТвр Залшт ВВДНИШ
Рис. б.
Для детализации нотации необходимо рассматривать объекты из другой предметной области - информационные технологии: Microsoft Excel, Книга, Лист 1, Лист 2, Модуль 1, Модуль 2, Макрос, интерфейс, база данных, вопросы, VB проект. Эта нотация показана на рис. 7.
Рис. 7. Нотация связи объектов
И в этой нотации произведем дальнейшую детализацию объектов и их связей как показано на рис. 8.
1)
*^■13 0С!нНЬ1* вопросов (6Д)
МйщЭОС
Выбила* "“>■
вйг-рос
Рис. 8. Нотация объектов
Таким образом, множество эпизодов (объектов) составляют определенную систему с иерархической структурой. Эта иерархия возникает естественно в процессе проектирования, и эти эпизоды будут иметь разный иерархический уровень детализации, т.е. иметь разный масштаб. В совокупности, все эти эпизоды представляют из себя информационную систему с иерархической структурой в зависимости от уровня интеграции эпизодов (разных масштабов), что составляет карту процесса проектирования. Эта карта показана на рис. 9.
Для описания структуры БД необходимы объекты другой предметной области
- базы данных со своими объектами: таблица, поле, связь (1:®) и т.д. На рис. 10 показана нотация структуры базы данных масштаба 1.1.1. Начиная с этого уровня легче описать модель объектами предметной области объектно-ориентированного программирования, например. Microsoft Visual Basic.
Таблица "Темы”
Код Темы
Название Темы
>
Итак, вернемся к проектированию как процессу в целом. Как показано на рис. 1, проектирование в ручном варианте заканчивается на шаге номер к в итерационном процессе декомпозиций. Как вычислить это число к? Рассмотрим три случая: первый случай. Допустим в нашем распоряжении CASE - средство Rational Rose [Трофимов С.А., 2001], и мы довели процесс декомпозиции до определенного числа к, где все записано и представлено на языке UML (стандартизованные формы семантической сети) [Буч Г., 1999]. В этом случае, начиная с шага к, проектирование как процесс полностью формализовано. Второй случай. У нас нет CASE - средств и в распоряжение Microsoft Visual Basic и Microsoft Office (VB +Office).
В этом случае придется делать больше шагов k1, где k1>k ручного проектирования т. к. объекты VB + Office обладают объектами с меньшей интеграцией и средствами их связывания (рис. 11).
Таблица '‘Вопросы"
Коя Темы Вопрос Правильный Ответ
Рис. 10.
Рис. 11.
Третий случай. У нас имеются CASE - средства, но в любой библиотеке объектов нет нам нужного инкапсулированного объекта, тогда придется решать дополнительную задачу создания инкапсулированного нового объекта из нового класса и заносить в библиотеку объектов, т.е. в этом случае, какие бы не были мощные средства, ассемблер тоже может понадобиться. Проектирование - сложный процесс, и на разных этапах приходится решать разные задачи, и для поиска решений в этих проектных задачах приходится организовывать побочные вспомогательные процессы (проектирование). Такие локальные процессы называются прототипными. Прототип проекта - это упрощенный проект (или особо выделенный эпизод проекта) с целью поиска оптимальных решений при проектировании. При построении прототипов обычно идут по двум путям, которые исследуют разные цели. Первый путь исследовательский, а второй - коммерческий. В исследовательских прототипах обычно обрабатывают ядро проекта (его основную идею) и мало обращают внимание на интерфейсную часть. При коммерческом подходе, наоборот, большее внимание обращают на развитие интерфейсной части в целях рекламы будущего программного продукта.
На рис. 12 приводится нотация зацикленного (итеративного) процесса проектирования программного обеспечения.
' 'ЬВПСІ ■ в-Е+чЯРРг»' І!№ с^яіагии.мк'м ' ґавшнпы-яі Липа.
Рис. 12.
Внедрение проекта в реаль - это фактически тестирование проекта в реальных условиях на пригодность к использованию. Таким образом, возникают вопросы об адекватности, жизнеспособности и продолжительности эксплуатации
спроектированного и реализованного проекта. Конечно, практическую адекватность модели и реали, достичь за один шаг трудно, поэтому зарождается целый итеративный процесс, который называют жизненным циклом информационной системы. Этот процесс образно можно представить так: имеется некоторый генератор, конструирующий программное обеспечение. Пусть это программное обеспечение внедрили в реаль и с помощью, какой - то меры оценили адекватность, но нас не устраивает «точность» соответствия. Тогда мы введем «кучу» дополнительных требований к информационному обеспечению и снова запустим генератор, получим новую реализацию и т. д. На рис. 13 изображен этот процесс. В целом, необходимо учесть, что реальный процесс, который моделируем, также изменяется во времени, и брошенная на произвол «судьбы» информационная система «стареет».
Выводы
Проведен системный анализ проектирования как процесса. Сделаны следующие выводы:
1. Проектирование программного обеспечения как процесс состоит из двух частей:
1. проектирование среды использования программного обеспечения;
2. проектирование самого программного обеспечения.
И должен быть объектно-ориентированный переход, т. е. объектноориентированная связь между средой и программным обеспечением. Чтобы поддержать эту целостность, обязательно должно быть проведено проектирование среды использования с достаточным количеством декомпозиций (детализаций).
2. Проектирование среды использования программного обеспечения останется прерогативой ручного проектирования (сугубо творческой работой). Проектирование самого программного обеспечения постепенно на себя возьмут CASE -средства.
3. Процессы декомпозиции при проектировании и при обучении проектированию по сути разные. При обучении проектированию должна быть «прототипная» декомпозиция (в исследовательском смысле), внутри прототипной еще прототипная и т. д. Таким образом, в основу обучения объектно-ориентированному проектированию должен быть положен объектно-ориентированный подход. Только такая ориентация может сформировать объектно-ориентированный подход как «философию» проектирования. Суть объектно-ориентированного подхода в обучении - это обучать проектированию по схеме: «что надо делать», а «как надо делать»- во многом оставлять на самостоятельную работу.
4. Проведенные эксперименты по обучению проектированию объектноориентированным подходом студентов по специальности «Информационные системы и технологии» показывают, что обучаемые должны иметь достаточный интеллектуальный уровень. В противном случае годится только структурный подход, при котором необходимо все время учить «что делать и как делать», но при этом подходе к обучению основное время уходит на то, чтобы научить «как делать». С точки зрения методики преподавания проектирования, важно найти эту грань -балансное состояние между тем, сколько давать «что делать» и сколько давать «как делать».
5. Идеологи и проектировщики программного обеспечения больших и сложных систем (БСС) выработали и активно продолжают развивать методологию БСС. В учебном процессе доминирует эта идеология и остается в тени методология проектирования программного обеспечения уровня фирм, производств, бизнес - процессов, которая имеет свою специфику и свою востребованность.
Будущие специалисты по проектированию программного обеспечения будут «жить», как правило, в среде уровня фирм и решать задачи проектирования программного обеспечения, т.е. заниматься проектированием программного обеспечения несложных информационных систем (НИС), и им необходимо знать эту специфику.
Можно утверждать, что задача проектирования программного обеспечения в пространстве офиса является актуальной, т.е. специалисты из области информационных технологий - востребованы. Причин к этому много, во-первых, развитие самих бизнес - процессов, технологий, массовая информатизация и т. д. С другой стороны, у специалистов из других областей деятельности не хватит «компьютерной» культуры для синтеза дешевого, мобильного, легко-адаптируемого программного обеспечения, которого требуется с каждым днем больше и больше. Несмотря на старания создателей Microsoft Office сделать эту среду доступной для широкого круга пользователей, знаний инструментальных и пользовательских систем Microsoft WORD, Microsoft EXCEL, Microsoft ACCESS, ... явно недостаточно, т. е. все время возникает потребность знания основ моделирования, проектирования,
программирования. Эту среду востребованной деятельности назвали прикладным проектированием программного обеспечения несложных информационных систем. При проектировании несложных систем, вырабатывается своя методика и технология, которая вообще-то отличается от технологии проектирования программного обеспечения больших и сложных систем. БСС создают группа специалистов разного уровня с использованием различных специализированных инструментальных средств проектирования (UML, CASE - средства). На рис. 14 (данные ЗАО «Ланит - Терком» 1999 г., http://www.terkom.ru/real) видно, хотя бы на качественном уровне, какие системы выгодно проектировать вручную, а какие - с использованием CASE - средств.
^втрпы 1Л МС-СЯД
г лр п гггп nw:
С AS]'! ср-рдсти йа г римен и ні.я CASE-tfr СДГ ГВ
Ііреия |) л. ip аоо tkj-j
Рис. 14.
Спецификой проектирования НИС является и психологическая обстановка когда возникает ситуация типа - «сам себе режиссёр», т. е. сам или небольшая группа людей являются и проектировщиками, и программистами, внедренцами и т.д. Обучаемому в этой ситуации необходимо научиться «выживать», т.е. быть специалистом может быть не самой высокой квалификации, но обладать умением решать задачи уровня бизнес - процессов.
Приложение
Рассмотрим процесс обучения проектированию несложных информационных систем как процесс, который должен быть сам спроектирован. На Рис. 15 предлагается проект.
Рис. 15.
Сделаем декомпозицию.
Рис. 1б.
Для стимулирования самостоятельности работы обучаемого при проектировании программного обеспечения, вводится система дозированной выдачи информации (подсказок в виде прототипов к решению задач по проектированию на каждом шаге декомпозиции) с прогрессирующими штрафными баллами за каждый полученный дополнительный прототип (кроме нулевого прототипа). Сделанный проект оценивается на сто баллов за минусом всех штрафных баллов, которые получил обучаемый при проектировании. Конкретный вид прототипа приводится в примере.
Пример. Проектируется оболочка для организации тестового контроля знаний. Рассмотрим эпизод.
Задача: Из редактора Microsoft Word необходимо импортировать в систему Microsoft Access базу данных задач, содержащих OLE - объекты, как показано на рис. І7.
Fild.doc F0c.2,dl*e
ГфЕпии» т*5лчи*
Тена 1 Тана 2
Зідпі Задкн!
|f>L£ ■ С О] .]■! ■ обь«кт|
Задні і ■іалача 1
■ Я-» ■ it
Microsoft Worfl
Рис. 1T.
Для решения поставленной задачи обучаемый в качестве помощи получает прототип решения этой задачи преподавателем.
Прототип решения задачи преподавателя (прототип О)
Задача. Содержимое файла WORD (“Файл WORD.Doc”) необходимо поместить в ячейку таблицы Access.
_______Дано: Содержимое файла с именем “Файл WORD.Doc”_________________________
А1. Упростить и вычислить при b = 5>/2: ъ + 16У2 _ ъ 16'^2
Ъ + 48 Ъ_48 '
1) 0; 2) -10; 3) -20; 4) -30; 5) -40.
Решение:
1. Создаем таблицу Access « ОбъектТабл » со следующей структурой:
Е Microsoft Access - [ОбъектТабл : таблица]
Файл Правка Вид Вставка Сервис Окно Справка
- У Щ # [& 7* I & ^ ® ю ж т ж I Я 1-> >
Имя поля Тип данных
Счетчик Счетчик
Объект Поле объекта OLE
2. Создаем форму в режиме «Создание формы в режиме мастера»
Выбвр-ге ГППЧ ЛЛЧ флТЫ. ^СПуГЕВГТ'СЧЕЬбсГ ННИЦЫОИ ТЗЙ™ НИМ '
. гін
ffl- Z
[T-i0™*id; WbwrTdDu J
Дктгттые пйгн:
Etiopdhriuc юля:
0т>та 1 1 jl-ї.гГГ > EfflHftO
Результат:
Li feltH - |ОЬьїЧгТв€іл]
' У -а V ft « | ЧІ | Jl 11 Д
~\ HSSjuSwf - fl - ж к ч ШШШ it -
(3 Імегч вст-дак* Фстірії 3»™кн GsiBt-т
► Cwtt □Strt і I ‘*■■■4.1 I
3. В режиме «Конструктор» в созданную форму помещаем «Кнопку4» с надписью «Загрузка»
В свойстве кнопки установим событие:
4. Факт нажатия кнопки поддерживается процедурой обработки события:
Private Sub Кнопка4_QickO Call Переход End Sub
«Переход» название процедуры в модуле «Module 1» со следующим содержимым:
[■>* ьм-кч- 'йг*т- -wHr ВМА-ІГі-КІГфСС
II II ■*£ |® і
♦ !4ЧЧ,
|Іі#ЛМвф
?pLLun См^мс Га», at-чзс
ЗчГі Г^рт-гіЛЦІІ
Гз<си_!МмктТч6п_С|йііг*а'.т. Еч-.Г=ь—ія
Гоо- ООНК-ТТ^вП-OeWTT-.'SmiL'WjflD ■ -‘(’■■"І Ноч DC№1<t>m<Ml64<t£- 1V.4J4JI UWP .ЛОО'
Г:-сгі_ ЗЛъяктТвЕ-я.Сйм р.т. А-=-li-Гі ■ ь-:■!<.ЕС:іьс4ігі:ч-і Eir.L (f'(.
Результат:
Результат: отчет созданный в режиме «Автоотчет: в столбец» выглядит следующем образом:
Прототип решения задачи преподавателя (прототип 0.1).
Комментарий. Этот прототип, обучаемый получает со штрафными баллами. Задача: Имеется база данных задач (два файла: Ма^А!^^ Мат_А2.doc ) в
Microsoft Word следующей структурой:___________________________________
Мат А1^ос
А1. Упростить и вычислить: -^0,5(28 + 7л/7) 0,5(28 _ 7л/7).
1) 20,5 ; 2) 5,25 ; 3) 10,5 ; 4) 7 ; 5) 21.______________
А1. Упростить и вычислить при Ъ = 5лІ2 :
: Ъ3 + 16л/2 Ъ3 _ 16л/2
Ъ+ 48 Ъ _48
1) 0 ; 2) -10 ; 3) -20 ; 4) -30 ; 5) -40.
Мат А2^ос
А2. Решить неравенство: 2л/х2 + 5х + 4 < х +1. 1) -1 ; 2) 0 ; 3) 1 ; 4) -2 ; 5) -3.
В каждом файле содержится задачи только по одной теме.
Требуется: Импортировать этих задачи в реляционную базу задач Microsoft Access со следующей структурой и содержанием:
Имя поля
Тип данных
Описание
КодТемы
НазваниеТемы
ИмяФайла
Счетчик
Текстовый
Текстовый
Свойства поля
Общие | Подстановка ]
Размер поля Новые значения Формат поля Подпись И н д е к с и р о ванное поле Длинное целое
Последовательные
Да (Совпадения не допускаются)
в Задачи:і аблица
Имя поля | Тип данных | Описание |
± КодТемы Числовой □
Задачи Поле объекта 01.Е 1
ч
Свойства поля
Общие | Подстановка |
Размер поля Формат поля
Число десятичных знаков
Маска ввода
Подпись
Значение по умолчанию Условие на значение Сообщение об ошибке Обязательное поле Индексированное поле
Длинное целое
Авто
Нет
Да (Допускаются сов
[в Темы: таблица -|п|х]
КодТемы НазваниеТемы ИмяФайла
+ 1 А1 С:\Мои документы\ис1\Прототип 1\MaT_A1.doc
+ 2 А2 С:\Мои документы\ис1\Прототип 1\MaT_A2.doc
► (Счетчик)
Запись: И 1 < 11 3 \ 1 И | >*| из 3
Решение:
1. Организуем форму с подчиненной формой для таблиц “Темы” и “Задачи” с помощью мастера (эту задачу можно решить только через форму).
taw »l< II Г t m 1
Функционирование кнопок поддерживаются соответствующими процедурами:
Private Sub Загрузить_Click()
Call ЗагрузкаЗадачСФайлаWORD End Sub
Private Sub Наза^Ою^)
DoCmd.Quit End Sub
Для осуществления импорта организован модуль
со следующей процедурой:
Public Sub ЗагрузкаЗадачСФайлаWORD0 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 "СММои документы\М\Прототип 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:-'С'Мои документы\М\Прототип 1\Temp.doc"
End With
Form_ЗадачиПодчиненнаяФорма.Задачи.SetFocus
Form_ЗадачиПодчиненнаяФорма.Задачи.SourceDoc = "C:\Мои
документы\М\Прототип_ 1\Temp.doc"
Form_ЗадачиПодчиненнаяФорма.Задачи.Action = acOLECreateEmbed
WA.Windows(1).Activate
WA. Selection. Whole Story 'Выделить все
WA.Selection.Delete 'Удалить выделенное
Form_ЗадачиПодчиненнаяФорма.КодТемы.SetFocus Form_ЗадачиПодчиненнаяФорма.КодТемы = Val(КодТемы)
DoCmd.DoMenultem acFormBar, acRecordsMenu, 5, , acMenuVer70
'Обновление данных формы
DoCmd.GoToRecord , , acNewRec ' Создаем новую запись Next
WA.Documents.Close 'Закрываем все открытые документы
WA.Application.Quit ' Закрываем объект WORD End Sub
Результат:
| В Задачи : таблица
КодТемы Задачи |
Q Документ Microsoft Word
1 Документ Microsoft Word
2 Документ Microsoft Word
2 Документ Microsoft Word
0
| Запись: н | ^ | | 1 ► I и !►*! из 4
Решение задачи обучаемым должно быть примерно таким: Дано:
А1. Упростить и вычислить при Ь = 5л/2 : Ь + 16л/2 - Ьъ - 1^У2
ь+48 ь-48 '
1) 0; 2) -10; 3) -20; 4) -30; 5) -40.____________________
А1. Упростить и вычислить: -^0,5(28 + 7л/7) - д/0,5(28 - 7л/7).
1) 20,5 ; 2) 5,25 ; 3) 10,5 ; 4) 7 ; 5) 21.
Решение:
■ 131 *
Private Sub Загрузшъ_СИск()
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] Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2-е изд./Пер. с англ. - М.: «Издательство -БИНОМ», СПБ. «Невский диалект», 1999 г.- 560 с., ил
[Кордуэлл М., 1999] Кордуэлл М. Психология. М.: «Издательство ГРАНД », 1999 г.-442 c.
