Файл: Применение объектно-ориентированного подхода при проектировании информационной системы(SPARX Enterprise Architect).pdf

В качестве отступления, интерес представляет тот факт, что в сгенерированном программном коде присутствует заготовка под деструктор класса.

~Class(){

}

В управляемых средах, таких как CLR, уничтожением объектов в памяти занимается сборщик мусора как только обнаруживает что объект вышел из зоны видимости и не имеет ссылок, его можно вызвать методом GC.Collect(), или вызвать метод Finalize() для объекта, но в любом случае решение об удалении будет принято на основе внутренних алгоритмов среды CLR. Деструктор в том виде нужен для неуправляемых объектов, удалять которые сборщик мусора не умеет. Если в дальнейшей работе такие объекты не планируется использовать, то данный фрагмент программного кода может быть удален.

Реализация метода Create добавленная на этапе проектирования также сохранилась. Данный программный код был добавлен в целях демонстрации возможностей SPARX Enterprise Architect.

public static IManage Create(){

if (start_instance == null && current_instance == null)

{

start_instance = new Class();

current_instance = start_instance;

return start_instance; //implicit upcast to IManage

}

else

{

//Design error -- must not be instantiated more than once

throw new Exception("Attemp to create second instance of ST");

}

}

Реализованы интерфейсы

public interface IDraw {

///

/// <param name="g"></param>

void Draw(Graphics g);

///

/// <param name="p"></param>

bool CheckClick(Point p);

///

/// <param name="p"></param>

void SetPos(Point p);

}//end IDraw

И перечисления

public enum Visability : int {

PRIVATE,

PUBLIC

}//end Visability

§ 2.5 Выводы

Таким образом, насколько это возможно в рамках данной работы, были рассмотрены ряд возможностей программного продукта SPARX Enterprise Architect для моделирования UML диаграмм и генерации кода.

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

Глава 3. Visual Studio Community Edition

К сожалению, в данный пакет более не входят ряд инструментов UML моделирования – например UML Model Explorer, а ряд возможностей доступны только в платной Enterprise версии^[5]. Тем не менее доступных возможностей вполне достаточно для данного исследования.

В состав бесплатно распространяемого данного пакета программного обеспечения входит компонент «Конструктор классов», установку которого необходимо произвести в Visual Studio Installer как показано на рисунке 5.

Рисунок 5. Установка отдельных компонентов

Visual Studio 2019 Community Edition

Если в предыдущей главе был получен программный код на основе визуального моделирования, то далее мы рассмотрим также использование Конструктора классов для создания диаграммы классов по существующему программному коду. Создание диаграммы классов показано на рисунке 6.

Рисунок 6. Создание диаграммы классов в

Visual Studio 2019 Community Edition

В целом, приходится признать, что что возможности программного продукта Microsoft сильно уступают Sparx Enterprise Architect. По крайней мере в Community Edition набор возможностей значительно уступает таковому в ранее рассмотренном программном продукте.

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

Рисунок 7. Панель элементов Конструктора классов Microsoft Visual Studio Community Edition

§ 3.1 Разработка в Дизайнере Классов

• • 1. Тем не менее воспользуемся предоставленными инструментами для создания основы условной информационной системы. Для целей данного исследования разработаем тикетинговую информационную систему с минимальным функциональным наполнением.
       1. Создадим класс TroubleTicket с конструктором и свойством Issued. Поле Issued будет иметь тип System.DateTime, конструктор будет присваивать этому полю дату и время в момент создания экземпляра класса.

Также, создадим класс TTContainer который, как ясно следует из названия, будет контейнером для объектов типа TroubleTicket. Для этого создадим поле tickets типа TroubleTicket[]. Семантика [] означает что тип является массивом, а управляемом языке C# массивы реализуют интерфейс IEnumerable, что позволяет легко использовать для них шаблоны итерации.

В завершении соединим два класса связью типа Ассоциация. Результат показан на рисунке 8.

Рисунок 8. Классы и Ассоциация в Конструкторе классов

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

public class TroubleTicket

{

public DateTime Issued

{

get { return Issued; }

private set { Issued = value; }

}

public TroubleTicket() { Issued = DateTime.Now; }

}

Класс TTContainer

public class TTContainer

{

public TroubleTicket[] tickets

{

get => default;

set { }

}

public TroubleTicket TroubleTicket

{

get => default;

set { } } }

Стоит обратить внимание что дизайнер классов не позволяет объявлять массив в качестве свойства при этом отражая это схематически, что можно считать недостатком. При попытке изменить тип свойства теряется схематическая ассоциация с классом, представляющим этот тип. Во фрагменте 2 показано то что можно создать в дизайнере классов, а во фрагменте 1 исправленный вариант. В данной работе, таким образом показан программный код, соответствующий схематическому изображению в Дизайнере Классов и продемонстрировано каким он должен быть. На рисунке 9 справа показано наследование класса TroubleTicket от условного класса Ticket.

Рисунок 9. Классы и Наследование в Конструкторе классов

В отличие от Ассоциации данный тип связи в рассматриваемом продукте не имеет вообще каких-либо настроек, впрочем, отражается в программном коде корректно: public class TroubleTicket : Ticket

На рисунке 10 поле Issued перенесено в базовый класс Ticket, добавлен конструктор в базовый класс. Также, добавлен делегат для обработки события OnCreated.

Рисунок 10. Классы и Наследование в Конструкторе классов

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

public Foo()

{

OnCreateHandler hand;

hand = (s, e) =>

{

//Обработчик события

};

TroubleTicket.OnCreated += (s, e) => hand(s, e);

}

Помимо возможности создавать классы и связанность между ними в Дизайнере Классов также имеется возможность построить диаграмму классов имеющегося проекта. Именно эта возможность будет рассмотрена в следующем параграфе.

§ 3.2 Представление проекта в Дизайнере Классов

Для достижения целей данной работы был разработан небольшой проект дизайнера классов, который подробно будет рассмотрен в следующей главе. На данный момент данный проект будет использован для исследования возможностей Дизайнера Классов по построению диаграммы классов уже созданного проекта. Проект носит условное название UML Modeller.

Как уже отмечалось ранее, проект носит исследовательский и учебный характер поэтому не претендует на полноценную функциональность. Тем не менее, демонстрирует объектно-ориентированный подход в объеме возможном для данной работы.

Переходя к рассмотрению построенной Дизайнером Классов диаграмме, стоит отметить что отображаемые классы, относящиеся к фреймворку .NET по понятным причинам рассмотрены не будут. Лишь частично будет рассмотрен класс MainForm поскольку он непосредственно реализует интерфейс спроектированного приложения. Классы Program, Resources и Settings таким образом исключаются из рассмотрения. На представленном ниже рисунке 11.

Рисунок 11. Классы и Наследование в Конструкторе классов

На рисунке 1 показана диаграмма классов, созданная автоматически на основе программного кода рассматриваемого проекта. Показательно отсутствие связей между элементами, даже тех, которые присутствуют в функционале Дизайнера Классов. Тем не менее, классы и интерфейсы показаны корректно.

В данной работе не удалось установить, если это вообще возможно сделать, каким образом в Конструкторе Классов связать интерфейс и реализующий этот интерфейс класс. В ранее рассматриваемом SPARX Enterprise Architect для этого можно было использовать связь типа Генерализация.

§ 3.3 Выводы

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

Глава 4. Проектирование UML приложения

Чтобы проиллюстрировать объектно-ориентированного подход на практике было разработано простое приложение, позволяющее моделировать классы на UML. Сама по себе разработка и реализация такого приложения является важным моментом для понимания и дальнейшего использования данного подхода.

§ 4.1 Интерфейс приложения

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

Рис. 12 Интерфейс приложение UML Modeller

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

Отрисовка схематических изображений классов производится на форме, однако непосредственная реализация вынесена в ClassElement (Листинг 3).

Стандартные элементы Windows Forms расположенные внизу служат для добавления и редактирования элементов диаграммы.

§ 4.2 Классы и интерфейсы

Используемые классы показаны на листингах 2-4 в приложении к данной работе. Класс ClassContainer (Листинг 2) инкапсулирует методы управления классами и регистрацию событий на форме через интерфейс IManageContainer. Для обновления изменений со стороны элементов содержащихся в контейнере используется реализуемый интерфейс IUpdatable. Также ClassConatainer через интерфейс IMoveable осуществляет взаимодействие с ClassElement, обеспечивающий «перетаскивание» элементов диаграммы.

ClassElement(Листинг 3) в свою очередь вляется контейнером для экземпляров класса Feature, реализует отрисовку классов через интерфейс IDraw, перетаскивание через эинтерфейс IMoveable а также управление членами класса через интерфейс IClassElementManage.

Наконец класс Feature (Листинг 4) содержит информацию о свойствах класса, реализует интерфейс IDraw для отрисовки свойств.

§ 4.3 Выводы

Исследованный, таким образом, метод объектно-ориентированного проектирования с использованием С# демонстрирует высокий уровень гибкости, простоты и возможностей.

Заключение