Спецификация программы uWert > Текст программы uWert Доказательство корректности программы uWert Организация многооконного интерфейса и диалога в приложениях (стр. 6 из 10)

/// <summary>

/// Сводка для Form1

///

/// Внимание! При изменении имени этого класса необходимо также изменить

/// свойство имени файла ресурсов ("Resource File Name") для средства компиляции управляемого ресурса,

/// связанного со всеми файлами с расширением .resx, от которых зависит данный класс. В противном случае,

/// конструкторы не смогут правильно работать с локализованными

/// ресурсами, сопоставленными данной форме.

/// </summary>

public ref class TestForm : public System::Windows::Forms::Form

{

public:

TestForm(void)

{

InitializeComponent();

//

//TODO: добавьте код конструктора

//

}

protected:

/// <summary>

/// Освободить все используемые ресурсы.

/// </summary>

~TestForm()

{

if (components)

{

delete components;

}

}

private: System::Windows::Forms::MenuStrip^ menuStrip1;

protected:

private: System::Windows::Forms::ToolStripMenuItem^ testToolStripMenuItem;

private:

/// <summary>

/// Требуется переменная конструктора.

/// </summary>

System::ComponentModel::Container ^components;

#pragma region Windows Form Designer generated code

/// <summary>

/// Обязательный метод для поддержки конструктора - не изменяйте

/// содержимое данного метода при помощи редактора кода.

/// </summary>

void InitializeComponent(void)

{

this->menuStrip1 = (gcnew System::Windows::Forms::MenuStrip());

this->testToolStripMenuItem = (gcnew System::Windows::Forms::ToolStripMenuItem());

this->menuStrip1->SuspendLayout();

this->SuspendLayout();

//

// menuStrip1

//

this->menuStrip1->Items->AddRange(gcnew cli::array< System::Windows::Forms::ToolStripItem^ >(1) {this->testToolStripMenuItem});

this->menuStrip1->Location = System::Drawing::Point(0, 0);

this->menuStrip1->Name = L"menuStrip1";

this->menuStrip1->Size = System::Drawing::Size(292, 24);

this->menuStrip1->TabIndex = 0;

this->menuStrip1->Text = L"menuStrip1";

//

// testToolStripMenuItem

//

this->testToolStripMenuItem->Name = L"testToolStripMenuItem";

this->testToolStripMenuItem->Size = System::Drawing::Size(40, 20);

this->testToolStripMenuItem->Text = L"Test";

this->testToolStripMenuItem->Click += gcnew System::EventHandler(this, &TestForm::testToolStripMenuItem_Click);

//

// TestForm

//

this->AutoScaleDimensions = System::Drawing::SizeF(6, 13);

this->AutoScaleMode = System::Windows::Forms::AutoScaleMode::Font;

this->ClientSize = System::Drawing::Size(292, 266);

this->Controls->Add(this->menuStrip1);

this->MainMenuStrip = this->menuStrip1;

this->Name = L"TestForm";

this->Text = L"TestForm";

this->menuStrip1->ResumeLayout(false);

this->menuStrip1->PerformLayout();

this->ResumeLayout(false);

this->PerformLayout();

}

#pragma endregion

private: System::Void testToolStripMenuItem_Click(System::Object^ sender, System::EventArgs^ e) {

PseudoFun();

};

};

}

Модуль TestForm.h содержит определение класса TestForm, содержащего пункт в главном меню, при активировании которого вызывается функция PseudoFun(), определённая в модуле NewBox.

Модуль NewBox:

namespace CLRWin02 {

using namespace System::Windows::Forms;

static void vbut_Click(System::Object^ sender, System::EventArgs^ e)

{

dynamic_cast< System::Windows::Forms::Form^ >(dynamic_cast< System::Windows::Forms::Button^ >(sender)->Parent)->Close();

};

void PseudoFun()

{

System::Windows::Forms::Form ^vForm2;

vForm2 = gcnew System::Windows::Forms::Form();

vForm2->AutoScaleMode = System::Windows::Forms::AutoScaleMode::Font;

vForm2->ClientSize = System::Drawing::Size(400, 200);

vForm2->Name = L"NBox";

vForm2->Text = L"Кириллизованный MessageBox";

System::Windows::Forms::Button^ vbut;

vbut = (gcnew System::Windows::Forms::Button());

vForm2->Controls->Add(vbut);

vbut->Location = System::Drawing::Point(100, 100);

vbut->Size = System::Drawing::Size(100, 30);

vbut->Text = L"ЖМИ";

vbut->UseVisualStyleBackColor = true;

vbut->Click += gcnew System::EventHandler(vbut_Click);

vForm2->ShowDialog();

}

}

Легко заметить, что в случае языка C++, не допускающего определение класса частями в нескольких модулях (как со спецификатором partial в языке C#l), фрагмент приложения, порождаемый средой проектирования автоматически и инициирующий форму, помещается в том же модуле, в котором находится определение класса, в данном случае – в модуле TestForm.h.

В проект входят вспомогательные модули:

stdafx.cpp: исходный файл, содержащий только стандартные включаемые модули

// CLRWin02.pch будет предкомпилированным заголовком

// stdafx.obj будет содержать предварительно откомпилированные сведения о типе

#include "stdafx.h"

stdafx.h: включаемый файл для стандартных системных включаемых файлов

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

// не часто изменяются

#pragma once

TestForm.resx, app.aps, app.ico, CLRWin02.vcproj, а также

AssemblyInfo.cpp

#include "stdafx.h"

using namespace System;

using namespace System::Reflection;

using namespace System::Runtime::CompilerServices;

using namespace System::Runtime::InteropServices;

using namespace System::Security::Permissions;

//

// Общие сведения об этой сборке предоставляются следующим набором

// атрибутов. Отредактируйте значения этих атрибутов, чтобы изменить

// общие сведения об этой сборке.

//

[assembly:AssemblyTitleAttribute("CLRWin02")];

[assembly:AssemblyDescriptionAttribute("")];

[assembly:AssemblyConfigurationAttribute("")];

[assembly:AssemblyCompanyAttribute("Microsoft")];

[assembly:AssemblyProductAttribute("CLRWin02")];

[assembly:AssemblyCopyrightAttribute("Copyright (c) Microsoft 2010")];

[assembly:AssemblyTrademarkAttribute("")];

[assembly:AssemblyCultureAttribute("")];

//

// Сведения о версии сборки состоят из следующих четырех значений:

//

// Основной номер версии

// Дополнительный номер версии

// Номер построения

// Редакция

//

// Можно задать все значения или принять номер построения и номер редакции по умолчанию,

// используя "*", как показано ниже:

[assembly:AssemblyVersionAttribute("1.0.*")];

[assembly:ComVisible(false)];

[assembly:CLSCompliantAttribute(true)];

[assembly:SecurityPermission(SecurityAction::RequestMinimum, UnmanagedCode = true)];

Главная форма и вызванное диалоговое окно выглядят на экране следующим образом;

6. ПРОЕКТИРОВАНИЕ КЛАССОВ

6.1. Основы модельно-ориентированного проектирования

Откуда берутся объекты в АСУ и бизнес-приложениях?

В настоящее время систематический подход к объектно-ориентированному проектированию представлен, главным образом, так называемым, MDA (model-driven architecture), или МОП (модельно-ориентированным проектированием). Основоположник – Rational Rose, подхватившей более 10 лет назад наработки OMG.

Идея MDA: проектирование включает в себя создание имитационной модели реальной системы ведётся на основе этой модели, и в неё же встраивается проектируемое компьютерное приложение для замены или развития её определённых функций.

Модельно-ориентированное и, соответственно, объектно-ориентированное проектирование реализуются в конкретных организационных формах в рамках определённых концепций жизненного цикла программ. Относительно независимым от этих форм и концепций является перечень “дисциплин” – видов деятельности, составляющих процесс создания программы (специальные виды технологических процессов):

бизнес-моделирование (business modeling),

работа с требованиями (анализ требований requirements),

проектирование (design),

реализация,

тестирование,

развёртывание,

конфигурирование,

управление изменениями,

управление проектом,

связь с окружением.

Дисциплины характеризуются своими результатами – “артефактами”. Основным артефактом бизнес-моделирования является имитационная модель реальной системы. Артефакты анализа требований: виденье (как бы ТЗ), описание (модель) “прецедентов”, словарь, спецификация требований, функциональных и прочих.

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

Модель реальной системы отображает основные объекты моделируемой системы, их свойства и отношения. Для этой модели характерно отражение статических аспектов системы.

Динамический аспект системы отражается, главным образом, в описании прецедентов и функциональных требований. Прецедент (use case). Основной прецедент и другие.

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

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

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

UML предоставляет графические средства для составления “диаграмм”:

диаграммы прецедентов,

диаграммы классов,

диаграмм взаимодействия, а именно: диаграммы последовательностей (sequence diagram) и диаграммы кооперации (collaboration diagram), в частности, системной диаграммы последовательностей. UML доступен в разных системах, в частности, в Microsoft Visio, Rational Rose, Delphi, начиная с издания 8.

6.2. Проект разработки компьютерной поддержки библиотеки

Далее в качестве примера рассматривается разработка компьютерной поддержки библиотеки.

6.2.1. Начальная фаза проектирования

В соответствии с рекомендациями Унифицированного процесса проектирования (UP) [1] во время начальной фазы проектирования в качестве рабочих материалов («артефактов») разрабатываются диаграмма концептуальных классов и диаграмма прецедентов, приведённые ниже.

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

На диаграмме концептуальных классов отражены только операции по выдаче и возврату публикаций, операции, связанные с прецедентами “Регистрация читателя” и “Комплектация библиотеки”, не показаны, чтобы избежать излишней густоты связей. Читатель может указать эти связи на отдельных экземплярах диаграммы концептуальных классов в качестве упражнения.