Переименуем элемент Package_1 в удобное для нас название packModel.

Рис. 5.58. Окно просмотра модели

5.4.2.1.Создание модели UML

Для создания модели дважды щелкнем мышью на строке packModel в окне просмотра модели. Откроется окно packModel [diagram] диаграммы классов ЕСО. Это окно напоминает окно построения обычных диаграмм классов UML. Только при работе с ним применяются элементы, специфичные именно для технологии ЕСО.

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

Назовем класс clChair (Кафедра). Пробелы в имени класса ЕСО не допускаются.

Добавим атрибуты класса командой контекстного меню Add>Attribute. Создадим таким образом три атрибута Название кафедры, ФИО заведующего кафедрой, ФИО секретаря кафедры – ChairName, ChairHeadSNP и ChairSecrSNP соответственно (Рис. 5 .59). Для задания типа атрибута выделим нужный атрибут и в окне Properties установим необходимое значение поля Type в категории General. В данном случае все три атрибута имеют тип String.

Рис. 5.59. Добавление класса clChair с его атрибутами

Переименуем названия класса и атрибутов в понятные названия на русском языке. Для этого в свойстве Alias (категория General) класса и его атрибутов введем русскоязычные названия.

По аналогии добавим к модели еще один класс clLecturer (Преподаватель) с атрибутами LecturerSNP (ФИО преподавателя) и LectAcadDegree (Ученая степень) типа String. Переименуем элементы нового класса на диаграмме, изменив значения свойства Alias.

Настроим связи между созданными классами. Эта связь будет представлять отношение ассоциации. Выберем на палитре инструментов инструмент Generalization/Implementation. Щелкнем мышью на представлении класса Кафедра, протянем связь к классу Преподаватель и снова щелкнем мышью. В результате между двумя классами сформируется ассоциативное отношение.

Настроим мощность ассоциативного отношения. В нашем случае одному экземпляру класса Кафедра соответствует множество экземпляров класса Преподаватель (от 1 и более). Для этого в окне Properties выделенной связи выберем категорию End1, соответствующую классу Кафедра, и в поле Multiplicity установим значение 1, а в категории End2 (для класса Преподаватель) этому же полю — значение 1..*. Теперь дадим сторонам связи названия. В свойство Name для сторон End1 и End2 введем roleChair и roleLecturers соответственно (Рис. 5 .60). То есть мы назвали роли каждого класса в ассоциативной связи.

На этом этапе создание простейшей модели закончено. Теперь надо организовать связь модели с пользовательским интерфейсом.

5.4.2.2.Создание интерфейса

Перейдем к окну Проектировщика для главной формы проекта WinForm (вкладка Design). Переименуем стандартное название главной формы. Назовем ее wfMainForm, а сам класс TWinForm переименуем в TMainForm в свойстве Name категории Design. Свойство Text (категория Appearance) отвечает за название заголовка окна, введем в него строку, например «Главная форма».

Для представления таблицы с объектами ЕСО на форме воспользуемся готовым компонентом DataGrid из категории палитры инструментов Data Controls. Поместим этот компонент на форму и дадим ему название dgChair (в свойстве Name). Эта таблица будет отвечать за представление экземпляров класса Кафедра (clChair). Исходно таблица должна быть пуста. В свойстве CaptionText (заголовок таблицы) введем название Кафедры.

Рис. 5.60. Настройка связи между классами

Добавим еще одну таблицу dgLecturer, которая в готовом приложении будет отвечать за отображение экземпляров класса Преподаватель (clLecturer). В свойстве CaptionText введем название Преподаватели.

Для работы с таблицами в простом приложение потребуется пять операций: добавление и удаление данных в двух таблицах и сохранение копии ECO пространства из оперативной памяти в базу данных. Редактирование данных будет осуществляться непосредственно в полях таблиц. Добавим на форму пять кнопок – экземпляров класса Button (Рис. 5 .61).

5.4.2.3.Связывание интерфейса с моделью

Связь пользовательского интерфейса с моделями ЕСО обычно происходит через компонент ExpressionHandle. Он доступен в категории палитры инструментов Enterprise Core Objects. Через подобные идентификаторы (дескрипторы) организуется доступ к объектам модели и пространства ЕСО во время работы программы.

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

Рис. 5.61. Добавление компонентов пользовательского интерфейса

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

Добавим к проекту компонент ExpressionHandle. Он отображается в нижней части окна Проектировщика, под формой, где уже имеется набор компонентов ЕСО. Назовем его ehChair, введем это имя в свойство Name категории Design.

В свойстве RootHandle этого дескриптора выберем значение rhRoot – ссылку на родительский, автоматически созданный корневой идентификатор. Так задают место данного идентификатора в цепочке доступа к объектному пространству ЕСО.

В свойстве DataSource таблицы dgChair выберем имя ehChair в списке доступных идентификаторов ЕСО.

Настроим таблицу Преподаватель так, чтобы она отражала список преподавателей, принадлежащих выбранной кафедре в первой таблице. Для начала добавим в проект дескриптор CurrencyManagerHandle (из категории Enterprise Core Objects) и дадим ему имя cmhChair, так как этот компонент будет указывать на текущую строку таблицы Кафедра. Свяжем дескриптор cmhChair с таблицей dgChair через свойство BindingContext. Теперь он отслеживает выделенную строку этой таблицы.

Зададим ссылку на объект ehChair в свойстве RootHanler, определяющим корневой идентификатор ECO.

Добавим к проекту еще один компонент ExpressionHandle. Назовем его ehLecturer. Дескриптор ehLecturer будет обращаться к экземплярам класса Преподаватель.

Зададим ссылку на объект cmhChair в свойстве RootHanler.

Потребителем объектов, предоставляемых дескриптором ehLecturer, будет вторая таблица. В ее свойстве DataSource выберем ссылку на объект ehLecturer.

Приступим к настройке элементов пользовательского интерфейса. Организуем с помощью визуальных средств Delphi создание новых экземпляров класса Кафедра и добавление их в таблицу. Выделим в окне Проектировщика кнопку Button1. В свойстве EcoListAction (Список стандартных действий ЕСО) выберем значение Add (Добавить объект).

Кнопка Button1 автоматически получила название Add. Переименуем кнопку. Для этого воспользуемся компонентом EcoListActions (он добавляется в проект по умолчанию и находится в нижней части окна Проектировщика), в его свойстве CaptionAdd введем Добавить.

Объект ЕСО, который мы хотим добавить к проекту (сделать доступным через элементы управления на форме), задается в свойстве RootHandle. В нем надо выбрать подходящий поставщик объектов ЕСО, в нашем случае — идентификатор ehChair.

Свяжем результат действия кнопки (созданный экземпляр класса Кафедра) с визуальным элементом, отображающим этот экземпляр, в нашем случае — с таблицей dgChair. Для этого в свойстве BindingContext (контекст связывания) выберем имя dgChair (Рис. 5 .6).

Теперь добавим операцию удаления экземпляров класса Кафедра. Реализуем это действие по аналогии с операцией добавления. Выделим в окне Проектировщика кнопку Button2. В свойстве EcoListAction выберем значение Delete. Зададим идентификатор ehChair в свойстве RootHandle. Свяжем результат действия кнопки с визуальным элементом — таблицей dgChair. Для этого в свойстве BindingContext у кнопки Delete выберем имя dgChair. Перейдем к компоненту EcoListActions и в его свойстве Caption Delete введем Удалить.

Настройка кнопки Button3 (будет отвечать за добавление экземпляра класса Преподаватель). Значения свойств кнопки: EcoListAction – Add; RootHandle – ehLecturer; BindingContext – dgLecturer. Перейдем к компоненту EcoListActions и в его свойстве Caption Add введем Добавить.

Рис. 5.6 Настройка кнопки добавления экземпляра класса Кафедра

Настройка кнопки Button4 (будет отвечать за удаление экземпляра класса Преподаватель). Значения свойств кнопки: EcoListAction –Delete; RootHandle – ehLecturer; BindingContext – dgLecturer. Перейдем к компоненту EcoListActions и в его свойстве Caption Delete введем Удалить.

Кнопка Button5 будет отвечать за обновление БД. Назовем ее Сохранить. В свойстве EcoAction (категория ECO|GUI) выберем UpdateDatabase. Таким образом, по нажатию этой кнопки выполняется синхронизация содержимого пространства ECO в оперативной памяти и его копии в базе данных. После каждого нажатия кнопки «Сохранить» содержимое таблицы сохраняется в БД. После нового запуска программы в таблицу пользовательского интерфейса автоматически загружается содержимое модели, сохраненное при последнем выполнении команды UpdateDatabase.

На данном этапе связывание интерфейса с моделью закончено (Рис. 5 .7).

Действия, которые выполняет дескриптор в программе, определяются значением свойства Expression. В это свойство вводится выражение языка OCL, которое определяет схему создания объектов модели ЕСО.

Используем дескриптор ehChair для обращения к экземплярам класса Кафедра. Введем в свойство Expression объекта ehChair строку clChair.allinstances. Иначе это можно сделать с помощью редактора OCL выражений. Введенное выражение задает доступ ко всем текущим экземплярам класса Кафедра в объектном пространстве. В таблице, показанной на форме в окне Проектировщика, сразу же отобразятся поля класса Кафедра (ChairHeadSNP, ChairSecrSNP и ChairName). Дескриптор ehChair становится поставщиком данных нашей модели ЕСО для первой таблицы.

5.4.2.4.Создание логики на OCL

В качестве выражения OCL объекта ehLecturer введем строку self.roleLecturers в свойство Expression. Здесь roleLecturers — это введенное нами при построении модели имя роли класса Преподаватель (clLecturer) в его ассоциативной связи с классом Кафедра (clChair). Это выражение определяет группу преподавателей, принадлежащих кафедре, которая выбрана в первой таблице. Дескриптор ehLecturer становится поставщиком данных для второй таблицы (Рис. 5 .8).

Дадим заголовкам полей таблиц русскоязычные названия. Выберем на форме таблицу dgChair. Щелчком на кнопке с многоточием в строке свойства TableStyles откроем окно редактора коллекции стилей таблицы DataGridTableStyle Collection Editor. Создадим новый стиль таблицы, нажав на кнопку Add (Рис. 5 .9).

Рис. 5.7 Настроенный пользовательский интерфейс приложения

Рис. 5.8 Настройка OCL-выражений для взаимосвязанных таблиц

Теперь настроим оставшиеся два элемента коллекции. Эти столбцы будут называться ФИО зав кафедрой и ФИО секретаря кафедры. Нажмем кнопку ОК в обоих открытых окнах и убедимся, что поля таблицы получили новые названия.

По аналогии настроим стиль таблицы Преподаватели. В ней отобразим два поля: LecturerSNP и LectAcadDegree. Назовем их ФИО преподавателя и Ученая степень.

Рис. 5.9. Коллекция таблиц компонента gdChair

Рис. 5.10 Настройка элемента коллекции столбцов

Запустим программу и убедимся, что при нажатии кнопки Добавить в таблице автоматически формируются новые строки, отражающие содержимое новых экземпляров класса из объектного пространства ЕСО. В них можно ввести нужные значения.

6.Документирование программных систем в соответствии с ГОСТ

6.1.Управление документированием программного обеспечения

6.1.1.Предисловие

Управление документированием программного обеспечения должно выполняться в соответствии с ГОСТ Р ИСО/МЭК ТО 9294-93. Данный ГОСТ разработан техническим комитетом по стандартизации ТК 22 «Информационная технология». Утверждён и введён в действие постановлением Госстандарта России от 20.12.93 № 260. Стандарт подготовлен на основе применения аутентичного текста технических рекомендаций ИСО/МЭК ТО 9294—90 «Информационная технология. Руководство по управлению документированием программного обеспечения».

6.1.2.Область применения

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

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

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

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

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

6.1.3.Роль руководителей

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

Эффективность выполнения руководящей роли можно рассматривать как основанную на трех элементах:

1. руководящая обязанность по документированию. Данная обязанность требует признания того, что программная

2. документация важна и что ее следует планировать, описывать, проверять, утверждать, выпускать, распространять и сопровождать;

3. руководящая поддержка обязанностей персонала по документированию.

Для этого требуется руководство и стимулирование персонала при проведении требуемого документирования и обеспечение его ресурсами для содействия в данной работе.

Для этого требуется обеспечить:

а) опубликованные официальные отчеты о стратегии документирования;

б) стандарты и руководства, определяющие все аспекты документирования программного обеспечения;

в) опубликованные процедуры документирования;

г) выделение соответствующих ресурсов для документирования;

д) планирование документирования, осуществляемое как неотъемлемая часть процесса разработки программного обеспечения;

е) постоянную проверку, осуществляемую для обеспечения соответствия со стратегией, стандартами, процедурами и. планами по документированию.