Как создать диаграмму классов в visual studio 2019
Поиск
Графическая диаграмма классов в C# (View Class Diagram)
Посмотрели 24175 раз(а) Комментариев 1
Последний комментарий : (10 сентября 2019 11:47) как визуально протягивать связи? (кодом я и так. читать. написать комментарий.
Графическая диаграмма классов в C# (View Class Diagram)
последнее обновление: 14 мая 2018
Чтобы увидеть диаграмму классов в Visual Studio 2013, 2015, 2017 нужно
1) Пишем код
C# Создаем новое C# консольное приложение. и напишем код
namespace ConsoleApplication1
<
abstract class Person
<
abstract public void ShowInfo();
>
class Student : Person
<
public String UniversityName < get; set; >
override public void ShowInfo()
<
Console .WriteLine( «Student, study in » + UniversityName);
>
>
class Developer : Person
<
public String CompanyName < get; set; >
override public void ShowInfo()
<
Console .WriteLine( «Developer, work in » + CompanyName);
>
>
class Program
<
static void Main( string [] args)
<
>
>
>
Приемы работы в MS Visual Studio 2010 для создания классов
Диаграммы классов (class diagram) используются для моделирования статического вида системы с точки зрения проектирования. Диаграмма классов — диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Используется в следующих целях:
· для моделирования словаря системы: предполагает принятие решения о том, какие абстракции являются частью системы, а какие — нет. С помощью диаграмм классов можно определить эти абстракции и их обязанности;
· для моделирования простых коопераций. Кооперация — это сообщество классов, интерфейсов и других элементов, работающих совместно для обеспечения некоторого кооперативного поведения;
· для моделирования логической схемы базы данных.
Согласно Мартину Фаулеру существуют три различные точки зрения на построение диаграмм классов или любой другой модели:
· концептуальная точка зрения — диаграммы классов служат для представления понятий изучаемой предметной области. Эти понятия будут соответствовать реализующим их классам, но прямое соответствие может отсутствовать. Концептуальная модель может иметь слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать без привязки к какому-то языку программирования;
· точка зрения спецификации — рассматривается программная система, при этом рассматривается только ее интерфейсы, но не реализация;
точка зрения реализации — классы диаграммы соответствуют реальным классам программной системы.
Для создания классов и отношений между ними в MS Visual Studio предназначена панель Панель элементов, которая расположена вертикально слева от окна диаграммы. Также её можно вызвать с помощью кнопки Панель элементов на панели инструментов Visual Studio.
Рис. 2.1 Панель инструментов
На ней по умолчанию представлены следующие кнопки:
Рис. 2.2 Панель элементов диаграммы классов
| Название кнопки | Назначение кнопки |
| Указатель | Превращает курсор в стрелку указателя для того, чтобы можно было выделять объекты |
| Класс | Добавление на диаграмму нового класса |
| Интерфейс | Добавление на диаграмму нового интерфейса |
| Перечисление | Добавление на диаграмму нового перечисления |
| Пакет | Добавление на диаграмму нового пакета |
| Комментарий | Добавление к диаграмме примечания |
| Ассоциация | Создание отношения ассоциации |
| Агрегат | Создание отношения агрегации |
| Композиция | Создание отношения композиции |
| Зависимость | Создание отношения зависимости |
| Наследование | Создание отношения наследования |
| Импорт пакета | Добавление существующего пакета |
| Соединитель | Создание неименованного отношения |
Создание новой диаграммы классов в MS Visual Studio 2010
1. В меню Архитектура выберите пункт Создать схему.
(Меню Архитектура доступно только в Visual Studio Ultimate.)
2. В диалоговом окне Добавление новой схемы выберите требуемый тип схемы моделирования.
Рис. 2.3 Выбор UML-схемы в Visual Studio
3. Введите имя новой схемы.
4. В окне Добавить в проект моделирования выполните следующее.
5. Выберите проект моделирования, который уже существует в решении, и нажмите кнопку ОК.
6. Выберите Создать новый проект моделирования и нажмите кнопку ОК.
7. В диалоговом окне Создание нового проекта моделирования введите имя и расположение нового проекта, затем нажмите кнопку Создать.
Рис. 2.4 Создание проекта моделирования в Visual Studio
Создание нового класса
Для создания нового класса нужно щелкнуть по кнопке Класс на Панели элементов и затем по свободному месту окна диаграммы (рис. 2.5). После создания класса нужно определить его свойства. Для этого нужно вызвать для него контекстное меню и выбрать пункт Свойства, после чего откроется меню класса, содержащее ряд вкладок (рис. 2.6).
Рис. 2.5 Созданный класс Class1
Рис. 2.6 Свойства класса
Для добавления нового атрибута к классу нужно вызвать контекстное меню для строки Атрибуты и выбрать пункт Добавить, либо вызвать контекстное меню класса, выбрать пункт Добавить (рис. 2.7) и выбрать пункт Атрибут.
Рис. 2.7 Контекстное меню класса.
Добавление новых операций к классу
Для добавления новой операции к классу нужно вызвать контекстное меню для строки Операции и выбрать пункт Добавить, либо вызвать контекстное меню класса, выбрать пункт Добавить (рис. 2.7) и выбрать пункт Операции.
Добавление параметров к операции класса
Для добавления параметров к операции класса необходимо открыть свойства операции, выбрать вкладку Параметры, в ней по кнопке с тремя точками, после чего откроется окно настройки параметров (рис. 2.8).
Рис. 2.8 Окно добавления параметров
Создание отношений между классами.
Общее замечание. Для любого типа отношений задание его свойств осуществляется одинаковым способом — вызвать для нее контекстное меню и выбрать пункт Свойства … .
Отношение зависимости.
Является наиболее общей формой отношения в языке UML. Все другие типы отношений можно считать частным случаем данного отношения. Отношение зависимости показывает, что изменение одного класса влечет изменение другого класса. Чаще всего применяется, когда один класс использует другой в качестве аргумента. Изображается пунктирной линией со стрелкой, направленной от зависимого класса к независимому.
Для создания отношения зависимости следует выбрать кнопку Зависимость на панели,затем щелкнуть мышкой по зависимому классу и не отпуская кнопки мыши перетащить стрелку на независимый класс.
Отношение ассоциации, агрегации и композиции.
Поскольку отношения ассоциации, агрегации и композиции отличаются очень незначительно, то рассмотрим работу с ними в общем.
Отношение ассоциации показывает, что один класс каким-то образом связан с другим классом (аналог связи в диаграмме «Сущность-Связь»). Изображается сплошной линией, соединяющей классы.
Отношение агрегации — частный случай ассоциации. Представляет собой отношение типа «целое/часть». Изображается в виде простой ассоциации с незакрашенным ромбом со стороны «целого». Агрегация не является наследованием, поскольку все классы-«части» в агрегации являются вполне самостоятельными, со своими атрибутами и операциями, отличающимися от атрибутов и операций класса-«целое».
Отношение композиции — частный случай агрегации. Служит для выделения специальной формы отношения «целое-часть», при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, т.е. с уничтожением целого уничтожаются и все его составные части. Изображается в виде сплошной линии с закрашенным ромбом возле класса «целое».
Для создания одного из приведенных выше отношений следует выбрать соответствующую кнопку на панели,затем щелкнуть мышкой по одному классу и не отпуская кнопки мыши перетащить стрелку на другой класс.
Отношение наследования
Это отношение между двумя элементами модели, при котором один элемент (клиент) реализует поведение, заданное другим (поставщиком). Изображается в виде пунктирной линии с большой незакрашенной стрелкой, указывающей на поставщика. Чаще всего наследование используют для определения отношений между интерфейсом и классом или компонентом, который предоставляет объявленные в интерфейсе операции или услуги.
Для создания отношения наследования следует выбрать кнопку Наследование на панели, затем щелкнуть мышкой по объекту-клиенту и не отпуская кнопки мыши перетащить стрелку на объект-поставщик.
3. Пример выполнения лабораторной работы
3.1. Создание диаграммы классов для сценария «Добавить новый заказ» прецедента «Работа с заказом»
Диаграммы классов будем рассматривать с концептуальной точки зрения. Для упрощения задачи и чтобы не загромождать диаграммы несущественными деталями методы setX, getX для каждого атрибута Х классов задавать не будем.
Создадим в Логическом представлении браузера новую диаграмму классов и назовем ее «Add New Order«. В поле документации запишем для нее следующий текст: «Диаграмма классов для сценария «Добавить новый заказ» прецедента «Работа с заказом»«.
Заполнение диаграммы начнем с определения классов-сущностей. Рассматриваемый сценарий состоит из:
· самого заказа;
· клиента, который делает заказ;
· комплектующих изделий, которые входят в заказ.
Создадим классы-сущности Order (Заказ), Client (Клиент) и ComponentPart (Комплектующее изделие). Поскольку в один заказ может входить много разных комплектующих изделий, и одно комплектующее изделие может входить во много заказов, то введем еще один класс-сущность OrderItem (Состав заказа). Опишем каждый класс.
Класс Client:
| Параметр | Значение |
| Комментарий | Класс, представляющий собой клиента фирмы |
| Атрибуты | name : String — наименование клиента address : String — адрес клиента phone : String — телефон клиента Все атрибуты имеют модификатор доступа — private |
| Операции | AddClient() — добавление нового клиента RemoveClient() — удаление существующего клиента GetInfo() — получить информацию о клиенте Все операции имеют модификатор доступа — public |
Класс Order:
| Параметр | Значение |
| Комментарий | Класс, представляющий собой заказ, который делает клиент |
| Атрибуты | orderNumber : Integer — номер заказа orderDate : Date — дата оформления заказа orderComplete : Date — дата выполнения заказа Все атрибуты имеют модификатор доступа — private |
| Операции | Create() — создание нового заказа SetInfo() — занести информацию о заказе GetInfo() — получить информацию о заказе Все операции имеют модификатор доступа — public |
Класс OrderItem:
| Параметр | Значение |
| Комментарий | Класс, представляющий собой пункт заказа, который делает клиент |
| Атрибуты | itemNumber : Integer — номер пункта заказа quantity : Integer — количество комплектующих изделий price : Double — цена за единицу Все атрибуты имеют модификатор доступа — private |
| Операции | Create() — создание новой строки заказа SetInfo() — занести информацию о строке заказа GetInfo() — получить информацию о строке заказа Все операции имеют модификатор доступа — public |
Класс ComponentPart:
| Параметр | Значение |
| Комментарий | Класс, представляющий собой комплектующие изделия |
| Атрибуты | name : String — наименование manufacturer : String — производитель price : Double — цена за единицу description — описание Все атрибуты имеют модификатор доступа — private |
| Операции | AddComponent() — добавление нового комплектующего изделия RemoveComponent() — удаление комплектующего изделия GetInfo() — получить информацию о комплектующем изделии Все операции имеют модификатор доступа — public |
Результат создания классов-сущностей показан на рис. 2.9:
Рис. 2.9 Созданные классы-сущности
Добавим отношения между классами (рис. 2.10):
· класс Client и Order — отношение ассоциации, поскольку данные два класса просто связаны друг с другом и никакие другие типы связей здесь применить нельзя. Один клиент может сделать несколько заказов, каждый заказ поступает только от одного клиента, поэтому кратность связи со стороны класса Client — 1, со стороны Order — 1..n;
· класс Order и OrderItem — отношение композиции, поскольку строка заказа является частью заказа, и без него существовать не может. В один заказ может входить несколько строк заказа, строка заказа относится только к одному заказу, поэтому кратность связи со стороны Order — 1, со стороны OrderItem — 1..n;
· класс OrderItem и ComponentPart — отношение агрегации, поскольку комплектующие изделия являются частями строки заказа, но и те, и другие, явлюятся самостоятельными классами. Одно комплектующее изделие может входить во много строк заказа, в одну строку заказа входит только одно комплектующее изделие, поэтому кратность связи со стороны ComponentPart — 1, со стороны OrderItem — 1..n.
Рис. 2.10 Классы-сущности и отношения между ними
Создание пакетов
Пакеты предназначены для группировки элементов в группы по определенным критериям. В простейшем случае классы можно группировать по их стереотипам. Создадим пакет Entities (классы-сущности):
Рис. 2.11 Пакет Entities
Группировка классов в пакеты
Группировка классов в пакеты осуществляется путем перетаскивания в Логическом представлении браузера соответствующего класса в соответствующий пакет:
Рис. 2.13 Классы и пакеты для сценария «Добавление нового заказа»
Задание для самостоятельного выполнения работы
· создать диаграмму классов для одного из сценариев диаграммы прецедентов, созданной в предыдущей лабораторной работе. Для каждого класса необходимо задать атрибуты и операции. Каждый класс должен быть подробно задокументирован — необходимо задать текстовое описание самого класса, описания его атрибутов и операций;
· создать пакеты для группировки классов, созданных в пункте 1;
· сгруппировать классы из пункта 1 в пакеты;
Содержание отчета
· созданные диаграммы классов (для диаграммы классов из пункта 2 задания должен быть указан сценарий, для которого данная диаграмма построена);
· краткое описание каждого созданного класса и отношений между классами.
Лабораторная работа № 3
Создание диаграмм деятельности
3.1 Цель работы:получить навыки построения диаграмм деятельности.
Теоретическое введение
Важнейшим понятием, применяемым при описании поведения, является деятельность.
Деятельность (activity) в UML — это описание поведения в форме графа деятельности.
Деятельность в UML моделирует то же, что и действие, т. е. какую-то содержательную активность во время работы системы; в этом смысле деятельность подобна действию, но деятельность противопоставляется действию по всем характеристическим признакам. В таблице 3.1 проведено сопоставление понятий «действие» и «деятельность» в UML.
Таблица 3.1 Сопоставление действия и деятельности
| Характеристика | Действие | Деятельность |
| Внешнее событие | Не прерывает выполнения | Может прерваться и завершить выполнение |
| Завершаемость | Всегда завершается самостоятельно | Может продолжаться неограниченно долго |
| Внутренняя структура | Не моделируется | Может быть раскрыта на отдельной диаграмме |
| Время выполнения | Пренебрежимо мало | Продолжительное |
Если нам не важно различие между действием и деятельностью и нужно употребить более общее понятие, то применяется термин активность.
Граф деятельности
Семантически граф деятельности(activity graph) — это множество сущностей, которыми являются действия или деятельности, и отношения между этими сущностями, которые задают порядок их выполнения.
Синтаксически граф деятельности— это нагруженный ориентированный (псевдо) гиперграф, в котором используются узлы четырех типов: узлы действий, узлы деятельности, узлы управления и узлы объектов, а дуги являются потоками управления или потоками данных.
На диаграмме деятельности применяется ряд значков, которые на самом деле не являются сущностями, хотя и являются узлами графа деятельности. Это так называемые узлы управления. Для VS 2010 узлы управления перечислены в Таблице 3.2.
Таблица 3.2. Узлы управления
| Название | Изображение | Что обозначает |
| Начальный узел (initial node) |  |
Начало деятельности |
| Конечный узел (final node) |  |
Завершение деятельности |
| Узел решения (decision node) |  |
Начало альтернативных ветвей деятельности |
| Узел слияния (merge node) |  |
Конец альтернативных ветвей деятельности |
| Узел ветвления (fork node) |  |
Начало параллельных ветвей деятельности |
| Соединительный узел (join node) |  |
Конец параллельных ветвей деятельности |
| Посылка сигнала (send) |  |
Действие посылки сигнала |
| Прием сигнала (accept) |  |
Ожидание события прихода сигнала |
Приведем пример диаграммы деятельности. Для этого рассмотрим увольнение сотрудника как бизнес-процесс, реализующий соответствующий вариант использования. Приведенная на рис. 3.0 блок схема буквально воспроизводит текстовое описание сценария. Никаких пояснений, как именно выполняется, например, деятельность Написать заявление здесь нет, но бизнес-процесс описан совершенно ясно.
Рис. 3.0 Диаграмма деятельности
Создавать диаграммы взаимодействия будем для сценария «Добавить новый заказ» прецедента «Работа с заказом». В этом сценарии кроме основного потока существуют еще и альтернативные потоки. Хотя стандарт языка UML допускает ветвления на диаграммах последовательности, мы, чтобы не загромождать наши диаграммы, ограничимся рассмотрением только случая, когда пользователь правильно вводит свой пароль, правильно заполняет необходимые поля и введенные данные без ошибок сохраняются в базе данных. В случае необходимости альтернативные потоки можно показать на дополнительных диаграммах последовательности.
Построение любой диаграммы взаимодействия начинается с определения перечня объектов, которые будут участвовать во взаимодействии. Для выбранного сценария в лабораторной работе № 2 была разработана диаграмма классов. Экземпляры классов этой диаграммы и будут участниками диаграмм взаимодействия.
Создание диаграммы последовательности для сценария «Добавить новый заказ» прецедента «Работа с заказом»
Для создания диаграммы последовательностей в диалоговом окне Добавление новой схемы выберите Диаграмма последовательностей UML (рис. 4.2).
Рис. 4.2 Создание диаграммы последовательности
Построение диаграммы последовательности начинается с размещения на ней линий жизни объектов, которые будут обмениваться сообщениями. Сначала необходимо разместить линии, которые посылают сообщения, а потом линии, получающие их. Инициатором взаимодействия выступает Менеджер по работе с клиентами. Поэтому на диаграмме он будет находится в левом углу. Далее размещаем:
· линия жизни OrderOptions (Параметры работы с заказом), отвечающая за выбор возможного действия с заказом в рассматриваемом прецеденте;
· линия жизни AddNewOrder (Добавление нового заказа), отвечающая за добавление заказа;
· линия жизни OrderManager (Менеджер по работе с заказами), отвечающая за обработку потока событий рассматриваемого прецедента;
· линия жизни Order (Заказ);
· линия жизни Client (Клиент);
· линия жизни ComponentPart (Комплектующее изделие).
Теперь на диаграмме следует разместить сообщения, которыми будут обмениваться объекты (рис. 4.3):
| Номер сообщения | Объект — отправитель сообщения | Объект — получатель сообщения | Название |
| Менеджер по работе с клиентами | OrderOptions | ввод пароля | |
| OrderOptions | Менеджер по работе с клиентами | проверка пароля | |
| Менеджер по работе с клиентами | OrderOptions | выбор операции «добавить» | |
| OrderOptions | AddNewOrder | отображение полей ввода | |
| Менеджер по работе с клиентами | AddNewOrder | выбор типа компьютера | |
| AddNewOrder | OrderManager | получение списка клиентов | |
| OrderManager | Client | получение списка клиентов | |
| Client | OrderManager | список клиентов | |
| OrderManager | AddNewOrder | отображение списка клиентов | |
| Менеджер по работе с клиентами | AddNewOrder | выбор клиента | |
| AddNewOrder | OrderManager | получение списка комплектующих | |
| OrderManager | ComponentPart | получение списка комплектующих | |
| ComponentPart | OrderManager | список комплектующих | |
| OrderManager | AddNewOrder | отображение списка комплектующих | |
| Менеджер по работе с клиентами | AddNewOrder | выбор необходимых комплектующих | |
| Менеджер по работе с клиентами | AddNewOrder | сохранить заказ | |
| AddNewOrder | OrderManager | передача управления | |
| OrderManager | Order | сохранить |
Рис. 4.3 Итоговая диаграмма последовательности
Лабораторная работа № 5
Создание диаграммы состояний
5.1 Цель работы: получить навыки построения диаграмм состояний.
Теоретическое введение
Диаграммы состояний (state diagrams) являются хорошо известным средством описания поведения систем. Они определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате влияния некоторых событий.
На рис. 5.1 показана диаграмма состояний UML, отражающая поведение отчета в системе управления проектами. На диаграмме изображены различные состояния, в которых может находиться отчет.
Рис. 5.1 Диаграмма состояний
Процесс начинается с начальной точки, затем следует самый первый переход в состояние «Проверка даты отчета». В поведении объекта в системе можно выделить действия, отображаемые переходами, и деятельности, отображаемые состояниями. Хотя и то и другое – это процессы, реализуемые, как правило, некоторым методом класса «Отчет», они трактуются различным образом. Действия связаны с переходами и рассматриваются, как мгновенные и непрерываемые. Деятельности связаны с состояниями и могут длиться достаточно долго. Деятельность может быть прервана в результате наступления некоторого события.
Переход может содержать метку. Если метка перехода не содержит никакого события, это означает, что переход происходит, как только завершается какая-либо деятельность, связанная с данным состоянием.
Из состояния «Проверка даты отчета» возможны два перехода. Метка одного из них включает условие. Условие — это логическое условие, которое может принимать два значения: «истина» или «ложь». Условный переход выполняется только в том случае, если условие принимает значение «истина», в противном случае выполняется переход, не помеченный условием.
Из конкретного состояния в данный момент времени может быть осуществлен только один переход; таким образом, условия являются взаимно исключающими для любого события.
Существует два особых состояния: вход и выход. Любое действие, связанное с событием входа, выполняется, когда объект входит в данное состояние. Событие выхода выполняется в том случае, когда объект выходит из данного состояния.
Диаграммы состояний хорошо использовать для описания поведения некоторого объекта в нескольких различных вариантах использования. Они не слишком пригодны для описания поведения ряда взаимодействующих объектов.
Рекомендуется строить диаграммы состояний только для тех классов, поведение которых влияет на общее поведение системы, например для классов пользовательского интерфейса и управляющих объектов.
Компоненты на диаграмме компонентов представляют собой физические модули программного кода (рис. 6.2). Обычно они в точности соответствуют пакетам на диаграмме пакетов (см. рис. 6.1); таким образом, диаграмма компонентов отражает выполнение каждого пакета в системе.
Рис. 6.2 Диаграмма компонентов
Зависимости между компонентами должны совпадать с зависимостями между пакетами. Эти зависимости показывают, каким образом одни компоненты взаимодействуют с другими. Направление данной зависимости показывает уровень осведомленности о коммуникации.
Проводить сравнение диаграмм пакетов и компонентов в общем случае бессмысленно, так как эти диаграммы не существуют сами по себе, а являются интерпретацией некоторой диаграммы классов, для которой и уместно проводить сравнение с другими диаграммами классов.
Диаграммы пакетов содержат один тип элементов — пакет и один тип связей — зависимость, поэтому численная оценка для диаграммы пакетов не столь велика, как для диаграммы классов.
Диаграммы компонентов строятся и используются на этапе реализации и сопровождения, когда базовая архитектура системы уже обычно определена; поэтому они однозначно получаются из диаграммы классов и для них достаточно привести по одному примеру.
1. Построить для моделируемой системы общую диаграмму пакетов, отметить на ней пакеты с необходимыми системными библиотеками, отобразить зависимости между пакетами.
2. Построить для данной системы диаграмму компонентов, соответствующую построенной диаграмме пакетов, системные пакеты изобразить в виде спецификаций пакетов.
3. Построить для проектируемой системы несколько вариантов диаграммы размещения (для архитектуры «клиент-сервер», трехуровневой архитектуры и т. д.), обосновать каждый вариант, предложить наиболее оптимальный.
Варианты заданий для выполнения лабораторных работ.
Вариант 1.
В качестве предметной области используется описание работы видеобиблиотеки, которая получает запросы на фильмы от клиентов и ленты, возвращаемые клиентами. Запросы рассматриваются администрацией видеобиблиотеки с использованием информации о клиентах, фильмах и лентах. При этом проверяется и обновляется список арендованных лент, а также проверяются записи о членстве в библиотеке. Администрация контролирует также возвраты лент, используя информацию о фильмах, лентах и список арендованных лент, который обновляется. Обработка запросов на фильмы и возвратов лент включает следующие действия: если клиент не является членом библиотеки, он не имеет права на аренду. Если требуемый фильм имеется в наличии, администрация информирует клиента об арендной плате. Однако, если клиент просрочил срок возврата имеющихся у него лент, ему не разрешается брать новые фильмы. Когда лента возвращается, администрация рассчитывает арендную плату плюс пени за несвоевременный возврат. Если фильма нет в наличии, фиксируется заявка на него, в соответствии с которой при поступлении фильма клиенту отправляется уведомление по указанному способу связи (СМС, электронный ящик и т.д.).
Видеобиблиотека получает новые ленты от своих поставщиков. Когда новые ленты поступают в библиотеку, необходимая информация о них фиксируется. Информация о членстве в библиотеке содержится отдельно от записей об аренде лент.
Администрация библиотеки регулярно готовит отчеты за определенный период времени о членах библиотеки, поставщиках лент, выдаче определенных лент и лентах, приобретенных библиотекой.
Вариант 2.
В качестве предметной области рассматривается организация, занимающаяся поставками оборудования. К основным операциям относятся:
· учет клиентов компании (поддержание справочника клиентов в актуальном состоянии);
· учет оборудования и его спецификаций (поддержание справочника оборудования в актуальном состоянии);
· подготовка прайс-листов на оборудование;
· учет заявок на закупку оборудования;
· подготовка коммерческих предложений;
· поддержка процесса согласования с клиентом предмета сделки;
· формирование, учет и контроль исполнения бизнес-плана на поставку оборудования;
· формирование, учет и контроль схемы оплаты за оборудование;
· формирование схемы линии (перечень требуемого оборудования);
· формирование, учет и контроль состояний договоров (приложений) на поставку, производство, сертификацию, доставку и страхование оборудования;
· обеспечение расчетов с клиентами компании;
· учет информации и документов по этапам поставки оборудования (заказ оборудования, производство, сертификация, страхование, доставка, монтаж, наладка, сдача в эксплуатацию и обучение персонала заказчика выпуску на нем продукции);
· учет платежей клиентов компании;
· поддержка процесса гарантийного обслуживания;
· подготовка материалов, поддерживающих процесс обучения;
· поддержка документооборота между автоматизированными рабочими местами должностных лиц.
Вариант 3.
Типография «Печатник» работает позаказно. 20 менеджеров продаж осуществляют приём заказов. У каждого заказа имеется плановый срок выполнения. В заказе может быть одно или несколько изданий (например, плакат, визитка, рекламный буклет, журнал, этикетка, коробка). Длительность выполнения заказа составляет от 1 до 10 дней, в среднем – 3.
Для производства каждого издания требуется выполнить ряд работ, таких, как, вёрстка, изготовление плёнок, печать, резка, склеивание, перебор листов, упаковка. В момент передачи заказа в производство для каждой из работ известна её плановая продолжительность. Работы должны производиться в определённом порядке. Часть работ выполняется на полиграфическом оборудовании, часть – вручную. Некоторые единицы оборудования являются взаимозаменяемыми. На предприятии есть 5 производственных участков, по которым группируется оборудование.
В функции диспетчера входит: назначение точного срока начала и окончания выполнения работ над заказами; составление графиков работы оборудования и сменного персонала; планирование работ производственных участков; информирование менеджеров продаж о текущем состоянии их заказов в производстве; контроль исполнения и оперативная корректировка планов; учёт брака. Основная его цель – добиться бесперебойной работы типографии, исключив ситуацию срыва плановых сроков исполнения заказов.
Вариант 4.
ЗАО «СЛАТАН» — это торговое предприятие, занимающееся закупкой, хранением и оптовым и розничным сбытом текстильных материалов, а также имеет в своем подчинении небольшой цех по пошиву автомобильных и мебельных чехлов, тюли и штор. Организация имеет в своем распоряжении несколько складов для хранения своей продукции и свой транспортный отдел, занимающейся транспортировкой продукции, как до мест розничного сбыта, так и осуществляющий поставку товаров оптовым покупателям. Основным направлением деятельности ЗАО «Слатан» является розничная продажа товаров в собственных точках продаж (павильонах, магазинах и на строительных рынках).
Вариант 5.
Отдел кадров промышленного предприятия реализует следующие функции управления персоналом:
— обеспечение потребностей предприятия в персонале;
− разработка системы целей управления персоналом;
− управление карьерой персонала;
− деловая оценка персонала;
− организация обучения персонала.
Вариант 6.
Организация, занимающаяся продажей строительных и отделочных материалов, осуществляет свою деятельность двумя способами:
− продажа определенного вида товара через сеть магазинов-складов;
− продажа товара с использованием сети Интернет (оформление заказа, доставка товара, оплата товара и т. д.).
Товар находится в различных точках продаж, поэтому необходимо предусмотреть возможность информационного обслуживания, заключающегося в подборе точки, имеющей в своем распоряжении необходимый товар в заданном количестве. Для оптимизации размещения товаров по точкам решено использовать предсказание покупательского спроса, по результатам которого товар будет размещаться в том или ином магазине.
Вариант 7.
Администрация больницы заказала разработку ИС для отдела приема пациентов и медицинского секретариата, предназначенную для обработки данных о врачах, пациентах, приеме пациентов и лечении.
Перед приемом в больницу проводится встреча пациента и врача. Врач сообщает в отдел приема пациентов об ожидаемом приеме больного и передает данные о нем. Если пациент ранее не лечился в больнице, то ему присваивается регистрационный номер и записываются его данные. Пациент должен быть зарегистрирован в системе до приема в больницу.
Во время пребывания в больнице пациент может лечиться у нескольких врачей; каждый врач назначает один или более курсов лечения. Данные о курсах лечения передаются в секретариат больницы, который занимается координацией лечения пациентов, регистрируются и хранятся там. При необходимости врач может запросить в медицинском секретариате историю болезни пациента.
Вариант 8.
В колледже работают N преподавателей. Каждый преподаватель может вести один или несколько предметов. За каждой группой студентов закреплен один руководитель.
Имеется расписание занятий, в котором зафиксировано, в какое время, в какой день недели, в какой аудитории, какая группа занимается, каким предметом, какой преподаватель его ведет.
Некоторые преподаватели ведут специальные семинары. Имеется расписание работы семинаров. Известно, кто из студентов посещает каждый семинар.
В колледже работают спортивные секции. Занятия в каждой из них ведут несколько тренеров. Занятия в секции ведутся по группам. Каждый студент может заниматься в одной или нескольких секциях. В каждой из этих секций он записан в определенную группу. Каждая группа закреплена за определенным тренером. Имеется расписание работы секций, в котором указано, какая группа, в какое время, с каким тренером занимается, а также место проведения занятий. Каждый тренер для каждой группы ведет журнал посещения занятий ее членами.
Вариант 9.
Небольшой банк автоматизирует деятельность, связанную с кредитованием физических и юридических лиц (индивидуальных клиентов и организаций).
В настоящее время кандидат на получение кредита заполняет бумажную форму, прикладывает необходимые документы (финансовый отчет, перспективную оценку финансового состояния и др.) и отправляет в банк. Референт по кредитованию анализирует запрос на предмет возможных ошибок и подтверждает его достоверность. Затем референт запрашивает отчет о кредитных операциях клиента в отделе кредитования. Копия отчета просматривается банковским служащим, а референт проверяет финансовое положение и доход клиента. Служащий также обращается к существующей системе управления счетами клиентов, чтобы получить необходимую информацию о состоянии счета и предыдущих кредитах клиента. Вся информация комплектуется в кредитный запрос и направляется для оценки инспектору по кредитам. Если запрос утверждается, инспектор определяет наилучшие условия кредитования и уведомляет об этом клиента. Если клиент принимает условия, то кредит оформляется. На обработку запроса обычно уходит минимум две недели (как для индивидуальных клиентов, так и для организаций).
Цель автоматизации – сократить время обработки запроса до 48 часов для индивидуальных клиентов и 72 часов для организаций, сократить количество сотрудников, занятых в процессе обработки, и увеличить количество запросов, обрабатываемых в заданный период.
Вариант 10.
Необходимо разработать новую систему начисления зарплаты, которая должна предоставлять служащим возможность записывать электронным способом информацию из карточки учета рабочего времени и автоматически формировать чеки на оплату, учитывающие количество отработанных часов и общий объем продаж (для служащих, получающих комиссионное вознаграждение).
Система должна предоставлять служащим возможность вводить информацию из карточки учета рабочего времени, вводить заказы на поставку, изменять свои параметры (такие, как способ оплаты за работу) и формировать различные отчеты. В целях обеспечения безопасности и аудита служащие должны иметь возможность доступа и редактирования только своих собственных карточек учета рабочего времени и заказов на поставку.
В системе должна храниться информация обо всех служащих компании в различных странах. Система должна обеспечивать правильную и своевременную оплату работы каждого служащего в соответствии с указанным им способом. Часть служащих получает почасовую оплату. Она начисляется на основе карточек учета рабочего времени, каждая из которых содержит дату и количество часов, отработанных в соответствии с конкретным тарифом. Если какой-либо служащий отработал в день более 8 часов, сверхурочное время оплачивается с коэффициентом 1,5. Служащие-почасовики получают зарплату каждую пятницу.
Некоторые служащие получают фиксированный оклад, однако они тоже представляют свои карточки учета рабочего времени. Благодаря этому система может вести учет количества часов, отработанных в соответствии с конкретными тарифами. Такие служащие получают зарплату в последний рабочий день месяца.
Некоторые служащие с фиксированным окладом также получают комиссионное вознаграждение, учитывающее объем продаж. Они представляют заказы на поставку, отражающие дату и объем продаж. Процент комиссионного вознаграждения определяется индивидуально для каждого служащего и может составлять 10, 15, 25 или 35%.
Одной из наиболее часто используемых возможностей новой системы является формирование разных отчетов: запросить количество отработанных часов, суммарную зарплату, оставшееся время отпуска и т.д.
Служащие имеют право выбирать способ оплаты за работу. Они могут получать свои чеки на оплату по почте, на счет в банке или на руки в офисе.
Администратор системы курирует информацию о служащих. В его обязанности входят ввод данных о новых служащих, удаление данных и изменение любой информации о служащем, а также формирование различных отчетов для руководства.
Приложение начисления зарплаты должно запускаться автоматически каждую пятницу и в последний рабочий день месяца, рассчитывая в этот день зарплату соответствующих служащих. Начисление зарплаты должно производиться автоматически, без ручной обработки.
Видео курс C# базовый (ООП)
Вы действительно хотите открыть доступ к тестированию по курсу C# базовый (ООП) на 40 дней?
ВИДЕОУРОК №2. Классы и объекты. Диаграммы классов.
Войдите или зарегестрируйтесь для того чтоб продолжить просмотр бесплатного видео
Введение в ООП, классы и объекты
Первый видео урок содержит массу полезной информации: автор в течение 3-х часов подробно и максимально доходчиво рассказывает про классы, их поля, свойства и экземпляры, а также раскрывает тему объектно-ориентированного программирования и демонстрирует реализацию одного из ее главных принципов — инкапсуляцию. Весь материал подкрепляется понятными практическими примерами.
Изучив содержание данного урока, вы сможете:
- понимать суть основных парадигм ООП;
- понимать, как устроены и для чего предназначены классы;
- создавать классы и правильно их использовать;
- понимать назначение полей и свойств, уметь их реализовывать;
- создавать конструктор класса;
- понимать принцип инкапсуляции и реализовывать его на языке C#.
Читать дальше.
Классы и объекты. Диаграммы классов.
В видео уроке «Классы и объекты. Диаграммы классов» будет продолжена тема урока «Введение в OOП. Классы и объекты», а также будет раскрыта тема возможности языка программирования C# разделять определение класcа между двумя и/или более файлами, именуемая частичными или partial классами. После ознакомления с частичными классами в С#, будут рассмотрены диаграммы классов, связи отношений между классами такие как ассоциация, агрегация, композиция, реализация, самоассоциация зависимости и другие.
Читать дальше.
Наследование и полиморфизм в C#
Все языки ООП, включая С#, основаны на трёх парадигмах (концепциях), называемых инкапсуляцией, наследованием и полиморфизмом. В ходе видео урока Вам будет представлена информация о двух основных парадигмах ООП — полиморфизме и наследовании, также Вы познакомитесь с модификаторами доступа и виртуальными членами. В ходе урока, на примерах, представленных тренером, Вы сможете понять практическое применение полиморфизма и наследования и научитесь работать с иерархией классов.
Читать дальше.
Абстракция. Абстрактные классы и интерфейсы
В видео уроке будет продемонстрированы практические примеры создания и использования абстрактных классов и интерфейсов. Абстракция позволяет программисту рассматривать объект, не разбирая сумму сложных частей, из которых состоит данный объект. В ходе видео урока Вы получите необходимые знания, которые помогут Вам разобраться с понятием абстракции в С#, а также научитесь создавать и реализовывать свои собственные абстрактные классы и интерфейсы и понимать разницу между ними.
Читать дальше.
Массивы и индексаторы
В видео уроке рассмотрены примеры создания и практического применения массивов и индексаторов. Тренер объясняет Вам принципы создания и практического применения индексаторов и способы их переопределения. Программисты с опытом знакомы с процессом обращения к индивидуальным элементам, которые содержат стандартные массивы. В видео уроке будет представлена возможность языка программирования С# проектировать специальные классы, которые можно индексировать подобно стандартному массиву через определение индексатора. Индексаторы часто используют при создании специальных типов — коллекций. В этом уроке Вы подробно изучите возможности индексаторов в языке C#.
Читать дальше.
Статические и вложенные классы
В видео уроке будут рассмотрены статические классы, принципы создания и практического применения статических членов. Также, в ходе видео урока будет объяснена работа и использование расширяющих методов.Во второй части видео урока тренер рассмотрит понятие вложенных классов и шаблон проектирования «Одиночка» (Singleton).
Читать дальше.
Структуры и их разновидности
В видео уроке будет представлена полная информация о структурах, рассмотрены отличия между классами и структурами, а также рассказаны практические советы по их применению. Структуры — фундаментальные типы данных в языке программирования C#. Структуры по своей сути просты и зачастую начинающие программисты могут не понимать, насколько быстро работа со структурами может стать сложной.
Читать дальше.
Перечисления (enum)
В данном видео уроке будут рассмотрены такие понятия как упаковка (boxing) и распаковка (unboxing), структурный тип DateTime, а также работа с перечислениями(enum). В ходе занятия тренер ознакомит студентов с практическими примерами, которые позволят с легкостью использовать и применять полученные на уроке знания. Последней темой, рассмотренной в видео уроке будут перечисления, которые предоставляют способ эффективно определить набор именованных интегральных констант.
Читать дальше.
Видео урок позволяет студенту понять работу лямбда-выражений и делегатов. Начинающие программисты, продумывая интерфейс очередного класса, часто понимают, что очень полезной могла бы быть возможность передавать в качестве аргумента методов часть исполняемого кода. Делегаты позволяют Вам реализовать подобный подход. В видео уроке будет представлена информация о создании и применении делегатов, а также основные трудности при работе с ними.
Читать дальше.
Универсальные шаблоны (generics) в C#
В языке программирования C# существует два механизма для создания кода, который будет повторно использован через различные типы — уже рассмотренное ранее наследование и обобщения. Обобщения, в отличии от наследования, выражают повторное использование кода через использование универсальных шаблонов(generics), в которых применяются различные типы данных на этапе выполнения. В ходе видео урока тренер рассмотрит с Вами все основы работы с обобщениями и их применение в языке программирования C#, а также расскажет о контрвариантности и ковариантности.
Читать дальше.
Ограничения универсальных шаблонов в C#
В видео уроке «Ограничения универсальных шаблонов» Вас ждет продолжение знакомства с универсальными шаблонами в C#. Вы узнаете, каким образом можно использовать ограничения для обобщенных типов данных. В ходе видео урока тренер остановит Ваше внимание на работе с Nullable типами, а также операциях поглощения, показав примеры практического их использования.
Читать дальше.
События (events) в C#
Весь видео урок будет всецело посвящен работе с событиями в C#. В деталях будет рассмотрено, каким образом создавать «издателей» и «подписчиков», а также обращаться к созданным событиям и вызывать их. Тренер уделит отдельное внимание делегату EventHandler и базовому классу EventArgs, а также работе с ними.
Читать дальше.
Потоки (threads) в C#
В процессе просмотра видео урока Вы получите основные сведения, которые потребуются Вам для работы с многопоточностью в языке программирования C#. Многопоточность — важное средство многозадачного программирования среды .NET. Видео урок даст Вам основное понимание многопоточности в языке программирования С#. Также в ходе урока тренер расскажет Вам об использовании делегатов ThreadStart и ParameterizedThreadStart и объяснит работу с критическими секциями, как средствами синхронизации доступа потоков к различным разделяемым ресурсам.
Читать дальше.
Коллекции в C#
В видео уроке будут объяснены коллекции, их назначение и примеры их практического применения. Также Вы детально изучите базовые интерфейсы IEnumerable, IEnumerator. Также в ходе видео урока тренер рассмотрит с Вами примеры создания и использования пользовательских коллекций, продемонстрирует наглядные примеры по работе оператора yield.
Читать дальше.
Обработка исключений (exception)
В этом видео уроке Вы узнаете какие системные исключения существуют в языке C# и как правильно обрабатывать исключительные ситуации с помощью конструкции try — catch — finally. Также вы научитесь создавать свои объекты исключения. При выполнение приложения может сложится ситуация, когда корректное выполнение приложения невозможно. Например, приложение читает файл на диске, которого нет. В такой ситуации в приложении возникает специальный объект – исключение. Исключение описывает проблему, которая возникла в момент выполнения кода и позволяет разработчику выбрать подходящее действие для решения проблемы.
Читать дальше.
Перегрузка операторов в C#
В данном видео уроке тренером будет рассмотрен базовый класс object его применение и использование, а так же техника перегрузки операторов. В процессе объяснения будет затронута техника клонирования, а также будет рассмотрено назначение шаблона проектирования «Прототип» (Prototype) и интерфейса ICloneable. Вам будут продемонстрировано практическое использование техники перегрузки операторов.
Читать дальше.
Анонимные и динамические типы. LINQ.
Данный видео урок будет очень важен для понимания всех современных технологий. В ходе видео урока тренер познакомит Вас с основами LINQ, а также с анонимными и динамическими типами, которые активно используются при построении запросов. Язык LINQ — это набор функций, который позволяет значительно расширить возможности синтаксиса языка программирования C#. Language Integrated Query (LINQ) представляет расширение языка C#, которое дает возможность работать с различными источниками данных используя синтаксис запросов подобный языку SQL.
Читать дальше.
Пространства имен. Директивы препроцессора в C#
В этом видеоуроке Вы узнаете, что такое пространства имен и как правильно организовывать проект используя пространства имен. Также Вы узнаете, как создавать библиотеки (DLL) в языке C#. Тренер рассмотрит тип проекта Class Library и на простом примере объяснить для чего используются библиотеки. В конце урока Вы изучите новые модификаторы доступа internal и internal protected и рассмотрите некоторые препроцессорные директивы, узнаете, как они могут помочь при разработке больших решений.
Читать дальше.
Следующий курс:
Видео курс Алгоритмы и структуры данных — онлайн обучение ITVDN
ПОКАЗАТЬ ВСЕ
Поделитесь этим видео в соц сетях
Доступ к полному курсу с учебными материалами и тестированием на 30 дней за 19,99 USD
основные темы, рассматриваемые на уроке
Частичные классы
Частичные методы
Работа с инкапсуляцией
Поля только для чтения
Диаграммы классов
Ассоциация
Разновидности UML диаграмм
Самоассоциация
Использование техники фабричных методов
ПОКАЗАТЬ ВСЕ
Рекомендуемая литература
Язык программирования C# 5.0 и платформа .NET 4.5 Эндрю Троелсен
Титры видеоурока
Здравствуйте! И тема сегодняшнего урока: «использование классов и объектов». В этом уроке мы рассмотрим такие понятия, как частичные классы, частичные методы, рассмотрим различные парадигмы ООП, и так же рассмотрим язык моделирования UML (Unified Modeling Language) – это язык для представления визуального формализма при моделировании объектно-ориентированных систем. Так же мы рассмотрим отношения связей между классами.
И первое, что мы рассмотрим – понятие «частичные классы» или «partial class». Давайте посмотрим на этот слайд. На слайде мы видим представление классов, как они выглядят, и вот на этом слайде есть комментарий: «В С# реализована возможность разделить создание класса или метода (структуры, интерфейса) между двумя или более исходными файлами или модулями. Каждый исходный класс содержит определение типа или метода, и все части объединяются при компиляции приложения». Давайте мы зайдем в visual studio и посмотрим как выглядят частичные классы в коде, Обратите внимание мы открываем папку “PartialClasses” в первом проекте и здесь мы имеются два файла с расширением .cs. Заходим в первый файл “PartialClass_1.cs”. На 6-й строке мы создаем partial class с именем «PartialClass». На 8-й строке мы создаем метод с именем «MethodFromPart1», который ничего не принимает, ничего не возвращает. В методе мы выводим на экран строку, чтобы оттенить работу нашего метода. Теперь заходит во второй файл с расширением .cs «PartialClass_2.cs» и в нем на 6-й строке мы так же создаем partial class, обратите внимание на ключевое слово partial – оно говорит о том что класс будет «частичным», то есть один класс будет разбит на несколько частей и разносится по нескольким файлам. Зачем это делается? Это делается для удобства. Сейчас мы посмотрим, где такие классы встречаются в практической деятельности. На 8-й строке мы создаем метод с именем «MethodFromPart2». Обратите внимание, если в первом файле мы создали метод с именем «MethodFromPart1» то здесь у нас имеется метод с именем «MethodFromPart2», в котором мы выводим строку: «II part». Теперь если мы зайдем в класс Program, в теле метода main на 11 строке мы создаем экземпляр класса PatialClass под названием instance и на 13-й строке мы обращемся к экземпляру нашего класса и вызываем метод «MethodFromPart1» и метод «MethodFromPart2». Обратите внимание, здесь у нас создается экземпляр одного класса, но, тем не менее, получается, что методы присутствуют как из одной части, так и с другой. Что это такое? Это некое удобство, чтобы мы могли распределять функциональность по разным частям класса например, в каком-то случае тело класса может быть слишком большим и разные программисты работают над одним классом, в каком-то случае у нас имеется раздельная функциональность, которая должна входить в этот класс, например, если у нас есть вспомогательная функциональность, то она может быть вынесена в какую-то одну часть, а некая бизнес-логика может быть вынесена в другую, снова же для удобства. Мы такой подход видим часто в шаблоне, при создании проекта «Windows Forms Application».
Давайте мы сейчас попытаемся создать такой проект. Мы создаем проект по шаблону «Windows Forms Application» и сейчас мы посмотрим, что у нас здесь сгенерировалось. Если мы зайдем в код и нажмем клавишу F7, обратите внимание, на 13-й строке мы создаем класс Form1, который помечен спецификатором partial. Если мы теперь посмотрим что у нас тут еще есть, перейдем допустим в файл Form1.Designer.cs. Обратите внимание у нас здесь имеется еще один partial class «Form1». Таких класса «Form1» их два: в одной части обычно хранятся методы обработчики событий элементов управления. Обычно, если мы по кнопке дважды кликаем, здесь автоматически генерируется обработчик событий. Давайте посмотрим как это выглядит. Заходи в Designer Form, открываем Toolbox, возьмем на пример кнопочку и поместим ее в область формы. Дважды кликаем и в одной из частей класса Form1 метод обработчик события нажатия на кнопку button_Click1. То есть мы видим, что partial классы достаточно часто используются в программировании, если мы их видим сразу же, после создания шаблона «Windows Forms Application».
Хорошо, мы с вами продолжаем. Еще раз вернемся к презентации и посмотрим на эти коды, которые здесь представлены. У нас создается один PartialClass, второй одноименный PartialClass и в каждом классе имеется свой метод. Далее в теле метода Main() мы создаем экземпляр класса PatialClass, который в действительности будет объединен в один класс, то есть вся функциональность будет объединена. И мы видим, что в примере мы обращаемся к методам, которые расположены в разных частях этого класса. Еще раз, для разделения класса на несколько частей, используется ключевое слово patial.
И следующее, что мы рассмотрим, это такие конструкции как partial или частичные методы. Частичные методы – это методы, где «прототип» или сигнатура метода определена при создании частичного класса, а реализация происходит в любой другой (только одной) части этого класса. Что это значит? Вот сморите, у нас имеется частичный класс и в этом классе у нас есть только сигнатура метода. Это напоминает старый подход, когда мы использовали компилируемые языки программирования, когда у нас в проекте (например в проекте С++) присутствовал файл с расширением .cpp и с расширением .h (так сказать header – заголовочный файл). В заголовочных файлах мы обычно определяли только прототипы, которые состояли, практически, только из сигнатуры. И тут мы тоже видим только прототип. В С++, когда мы задавали прототип в заголовочном файле, то мы говорили, что мы объявляем какую-то конструкцию, а уже в .срр файле мы определяли эту конструкцию. Поэтому, когда мы программируем на языке C#, это не совсем корректно говорить, что тут мы объявляем класс или метод, а там – определяем, потому что объявить можно в одном месте, а определить — в другом, и невозможно определить ранее не объявленное. А когда вы просто что-то создаете, то нужно говорить, что мы просто создаем. Поэтому я рекомендую говорить не «объявляем или определяем какую-то конструкцию», а говорить, что мы создаем (например, мы создаем класс, мы создаем метод, мы создаем свойство, и так далее). Но относительно частичных методов мы можем говорить, что тут мы объявляем, а там определяем, потому что в одной части класса мы объявляем метод, а сама реализация – в другой части. И вот обратить внимание в теле main мы создаем экземпляр класса PartialClass, у нас происходит слияние двух частей и далее мы вызываем на экземпляре метод СallPatrialMethod(). Обратите внимание, что в теле метода СallPartialMethod() мы вызываем PartialMethod, модификатор доступа используется private, кстати с partial методами мы не можем использовать никаких модификаторов доступа. Они всегда будут private. Давайте мы перейдем к следующему слайду. И здесь мы видим правила использования частичных методов: частичные методы должны быть определены только частичных классах, частичные методы должны быть помечены ключевым словом partial, частичные методы всегда являются private, попытка явного использования сними модификатора доступа приведет к ошибке, частичные методы должны возвращать void, частичные методы могут быть не реализованными – это значит, что в одной части можем его объявить а в другой можем пока не определять (не реализовывать). Давайте перейдем к программному коду и посмотрим, как у нас выглядит работа в коде с частичными методами.
Заходим во второй проект. Обратите внимание, у нас в папке PartialMethod находятся двя файла PatialClass_1 и PartialClass_2. Заходим в PatialClass_1. Видим, что на 6 строке мы создаем PartialClass. В теле этого класса мы объявляем частичный метод PartialMethod. Обратите внимание, здесь используется только его сигнатура, но не используется тело. На 11 строке мы объявляем еще один частичный метод MyMethod. Помните, мы говорили что, частичные методы не могут иметь возвращаемого типа? Давайте попробуем это проверить. При попытке описать новый частичный метод с возвращаемым типом int «partial int My();» — компилятор выдаст нам ошибку. Главное помнить, что частичные методы могут иметь аргументы, но не могут иметь возвращаемых значений. И еще важно помнить, что частичные методы объявляются в одной части класса, а реализуются в другой. Зачем так делается, мы с вами будем смотреть дальше пример использования частичных методов. Сейчас мы смотрим правила их создания и варианты использования. Сразу скажу, что частичные методы встречаются достаточно редко.
На 6 строке мы создаем частичный класс с именем PartialClass. На 9 строке мы уже определяем метод PartialMethod, ранее объявленым в первой части. Нотация звучит как и в С++: в хедере — объявляем, в срр — определяем. Мы понимаем, что частичные методы являются private и к ним мы можем обратиться только внутри класса, в котором они созданы. И на 15 строке мы создаем открытый метод CallPartialMethod. В теле этого метода на 17 строке мы вызываем PartialMethod, а на 15 строке — вызываем MyMethod. Обратите внимание, что метод MyMethod — не реализован. При выполнении программы у нас ошибки нет, не смотря на то, что у нас происходит здесь вызов. Давайте снимем комментарий и еще раз выполнить программу и видим что, нам выводится текст, указанный в методе MyMethod: » реализация частичных методов в других частях класса не обязательна», хотя мы можем это сделать. То есть мы можем вызвать метод, если у нас есть объявление, но нет определения.
Я думаю, что с частичными методами и частичными классами все предельно понятно: это достаточно простые конструкции, они используются в основном для удобства. Дальше мы еще будем с ними встречаться и посмотрим варианты использования.
И следующее что мы с вами рассмотрим такое понятие как инкапсуляция. На 7 строке мы создаем класс MyClass, а на 9 строке мы создаем поле того же типа, что и мы создаем. То есть получается что здесь создается ссылка на самого себя. На 11 строке мы создаем метод с именем Method. На 16 строке создаем открытый метод CallMethod и в нем мы присваиваем полю my ссылку на экземпляр класса MyClass. Но при этом мы сразу же обращаемся к закрытому private методу Method данного класса. Если мы попробуем сделать то же самое за пределами класса, у нас будет ошибка. На 29 строке в теле метода main мы создаем экземпляр класса MyClass, вызываем открытый метод CallMethod. Но если мы сейчас попытаемся обратиться к закрытому методу, то компилятор выдаст ошибку. То есть правило следующее: объект не может скрывать (инкапсулировать) ничего от другого объекта того же класса, то есть внутри само класса инкапсуляция не работает, то есть не работает реализация членов класса. Здесь мы также видим новую технику — технику само-ассоциации, но об этом мы поговорим чуть позже, когда подойдем к рассмотрению языка UML.
А сейчас мы рассмотрим одну особенность — поля только для чтения. Обратите внимание, у нас имеется ключевое слово readonly — это модификатор, который можно использовать только для полей. Здесь мы на 10 строке создаем открытое поле, только для чтения, и присваиваем ему некоторые значения, в данном случае слово «hello». На 15 строке в конструкторе мы присваиваем новое значение этому полю «поле только для чтения». При этом, попытка присвоения значения из любого другого места, кроме как конструктора — приведет к ошибке. Даже если мы в этом же классе создадим еще один метод, например void M() и присвоим этому полю некоторые значения — у нас тоже будет ошибка. Поэтому поля только для чтения не немного похожи по своему поведению на константы, но на самом деле они являются полноценным полем, но инициализировать их мы можем только во время их создания либо в конструкторе класса, который содержит такое поле. Давайте вернемся к презентации и посмотрим описание. Если поле используется с модификатором readonly, то присвоение значений таким полям может происходить только при создании или в конструкторе того же класса.
А сейчас мы посмотрим, что такое язык UML. Расшифровывается как Unified Modeling Language -унифицированный язык моделирования. На этом языке невозможно программировать, но можно моделировать объектно-ориентированные системы, либо часть этих систем, для их удобного представления. Чтобы обеспечить визуальный формализм, с помощью которого мы можем производить как создание, так и анализ программного обеспечения. Об этом языке подробно можно посмотреть на сайте omg.org в меню раздел technology и раздел UML. UML имеет множество различных диаграмм, но нас, как программистов, будет интересовать только 2-3 типа диаграмм: диаграммы классов, диаграммы последовательности и диаграммы кооперации. Полностью создать модель с использованием языка uml достаточно хлопотное и дорогое занятие, потому что язык uml позволяет описать модель объектно-ориентированной системы, но иногда это нерационально писать полностью все сущности, которые есть у нас в программе.
Вернемся к презентации и посмотрим, что из себя представляет диаграмма классов. Диаграммы классов — это такие диаграммы, которые позволяют нам представлять классы прямоугольниками и между ними проводить разного рода линии. Основные элементы языка uml — это прямоугольник и линия. Прямоугольник будет символизировать собой некий класс, структуру или какой либо другой стереотип, линия будет представлять собой одну из нескольких связей отношений. Прямоугольник принято называть классификатором. Сам классификатор разбивается на секции. 1 секция — это секция имени. Обратите внимание, секции, фактически нарисованы как карандашом под линейку. Это значит, что uml диаграммы мы можем рисовать как на бумаге, так и с помощью каких-то программных средств. Такие программные средства есть даже у нас в visual studio, которые мы можем посмотреть . Давайте откроем и попробуем создать новый проект: Add -> New project -> Modeling projects. Кликаем правой кнопкой мыши по Modeling projects и выбираем Add -> new item. И видим, что здесь у нас в шаблонах имеется UML Class Diagram. Открываем палитру элементов. И видим, что мы в область диаграммы можем поместить класс. Конечно не принято, чтобы классы хранились в такой белой области . Вы спросите а как принято? Давайте откроем любой пример. Видите вот эту странную конструкцию namespace, в которую складываются все классы? Конструкцию namespace мы рассмотрим на последнем уроке, потому что с помощью этой конструкции мы сможем формировать слои. И когда мы будем проектировать архитектуру нашего приложения, конечно же, мы будем формировать слои. Эти слои являются не чем иным как конструкцией пространств имен — namespace. В языке uml конструкции namespace представляются в виде Package. И мы берем это пространство имен и туда вкладываем наши классы. Например, создадим 3 класса: 1 — Document, 2 — Title, 3- Body. И мы видим, что класс Document должен как-то использовать класс Title и Body. Document — это у нас некий ассоциативный объект, который сам не обладает полноценный функциональностью, а собирает эту функциональность из частей, которые в нём написаны. И давайте проведем какую-то связь между этими классами. Проводим ассоциативную связь между классами Document и Title, Document и Body. Направим какую-то стрелочку от Document к Title. Что это значит? Посмотрите на направление этой стрелки. Фактически Document является источником выстрела стрелки, а Title является целью, куда она должна попасть. И вот мы понимаем, что если мы проводим именно такую связь отношений, она называется ассоциацией, это значит, что Document знает об этих частях. Вот эти части не знают ничего о документе, потому что в классе Title не создается поле или какая-то переменная типа Document. Поэтому Title ничего не может знать о документе, который его содержит. И как вы помните, в примере мы рассматривали, что в Document описываются поля типа Title и типа Body . Вот соответственно от него и исходят стрелы к этим классам.
Перейдем обратно к презентации. Мы видим, что классификатор разбивается на секции: 1 секция это секция имени , 2 секция — секция атрибутов , где находится описание полей. Обратите внимание на слово атрибуты. В документации uml поля обозначается не как поля, а как атрибуты. Но при программировании на C# так говорить нельзя, потому что в языке C# есть такая конструкция как атрибуты. Давайте мы ее рассмотрим, как она выглядит. Давайте зайдем в какой-то файл, например AssemblyInfo.cs. И видим, например на строке 8 какую странную конструкцию – это и есть атрибуты. Их вы будете изучать на курсе professional. Конструкция атрибутов пришла к нам из аспектно-ориентированных языков. У нас есть низкоуровневые языки, процедурные языки, функциональные языки, объектно-ориентированные языки, аспектно-ориентированые языки и так далее. Так вот, понятие аспекта у microsoft было названо понятием атрибут. Просто запомните, что в секции атрибутов в нашем случае хранятся поля и мы бы в своей нотации сказали, что это секция полей. Следующая секция — это секция операций. По правилам языка uml метод или функция, созданные в классе, мы говорим, что мы создали операции. Когда мы создали экземпляр этого класса, поставили точку и пытаемся вызвать эту функцию мы говорим, что мы вызываем метод. То есть мы создаем класс, называем эту функцию операцией, во время создания, пока мы в ней что-то пишем. А когда мы уже на экземпляре через точку обращаемся к этой функции, мы говорим, что мы вызываем метод. Но это чистая нотация ООП в представлении языка uml. Далее, обратите внимание на последнюю секцию. Это секция обязанностей и она не обязательна. В этой секции пишутся некие «to do» — что нам нужно сделать. Обязанность можно добавить в коде, написав комментарий вот таким образом: // todo: обязанность. И теперь, если в visual studio зайти в tasklist, то там можно увидеть то, что нужно сделать. То есть, это такая возможность сделать какой-то план или заметки самому себе.
Давайте теперь посмотрим, как вот этот класс, который представлен с использованием языка uml, представить с помощью языка С#. То что находится в секции имени у нас используются вот здесь: «class MyClass». Мы создаем класс с именем MyClass, в секции атрибутов мы создаем поле field и в секции операций мы создаем метод Method(). Давайте теперь посмотрим, как представлен класс на диаграммере visual studio Class Diagram (он доступен только в редакции ultimate). В этом диаграммере мы также можем создать некие классы, провести связь ассоциации, создать методы, поля. Он очень похож на язык uml, но это не он. Этот язык называется DSL (domain specific language). Domain — это определенный архитектурный слой, который описывает именно бизнес сущности, описывает бизнес-модель разрабатываемой программы. Потому что программы разделяются обычно на 3 слоя: 1 слой программы описывает только пользовательский интерфейс, другой слой описывает работу с бизнес логикой , там где мы работаем с такими сущностями как документ, сотрудник и другими суцностями, третий слой это слой по работе с данными. Так вот язык DSL предназначен именно для 3-го слоя.
В языке dsl мы уже имеем дело с секциями полей и методов. Также, обратите внимание, под названием класса находится такое слово как class, мы, так же, встречались c такой конструкцией как структура (struct). А что такое class или что такое структура (struct)? Одним словом эти сущности называются стереотипами. На следующем слайде мы видим список всех стереотипов, которые имеются в языке C#. Мы с вами рассмотрели конструкции класса, краем глаза посмотрели на такой стереотип как структура (вы помните, что все простые типы данных являются структурами (int, boolean), а тип string является классом). Далее у нас будут такие стереотипы как абстрактные классы, интерфейсы, generic структуры , generic интерфейсы, generic классы, generic абстрактные классы, generic делегаты, сами по себе делегаты, перечислительный тип Enum (он является единственным пользовательским скалярным типом данных).
Обратите внимание, у нас имеется классификатор (это класс), у нас имеется секция полей, секция методов, возле каждого поля и метода имеются какие-то значки . Вот эти значки языке dsl обозначают модификаторы доступа если возле синего кубика ничего нет (синие кубики обозначают поля , розовые кубики обозначают методы), значит используется модификатор доступа public. В языке uml public представлен плюсом. Поля с модификатором доступа private, обозначаются минусом.
Теперь рассмотрим все возможные отношения между классами. Обычная линия и линия со стрелкой обозначает связь ассоциации (мы с вами ее рассматривали). Связь отношения ассоциации звучит так: «я знаю о. «. То есть источник знает о цели. Следующая — агрегация, которая звучит так: «состою из. » Мы видим, что в данном случае документ состоит из Title и Body, поэтому здесь нам нужно взять связь отношения агрегации. И теперь мы видим, что документ не знает о своих частях, а, в действительности, состоит из этих частей. И когда я смотрю на диаграмму классов и вижу связь агрегации, я понимаю что документ — это некий составной объект , который состоит из каких-то частей . И допустим, если бы мы описывали какую-то жизненную сущность например холодильник , то мы бы сказали что холодильник состоит из, например коробки с дверями и морозильной системы. Следующая связь отношений — композиция. Композиция это жесткая форма агрегации. Она звучит так: «состоит из и не может без него жить». Например, может ли документ жить без Body? Без Title мы можем как-то обойтись, а вот без body — не можем, поэтому здесь связь агрегации не совсем подходит. И нам здесь лучше выбрать связь отношения композиции. И теперь мы видим, что документ состоит из двух частей и не может состоять без части Body. Идем дальше. Следующая связь отношения это обобщение (так же переводится как наследование). Наследование это процесс передачи всего открытого и защищенного состояния поведения одного класса к другому. Реализация напоминает исследование, но это немножко другое и их нужно различать. Что еще хотелось бы заметить, при описании объектно-ориентированное проектирования часто используется тоже такое слово как композиция. Так вот, если вы будете читать книгу «Паттерны проектирования» , вы будете часто встречать такое слово как композиция . Но в контексте этого источника композиция звучит не как жесткая форма агрегации, а как собирательное понятие ассоциации и агрегации.
Мы с вами идем дальше. Давайте сейчас посмотрим, какая бывает ассоциация. Ассоциация бывает направленная (однонаправленная). Чтобы создать такую конструкцию, нам нужно создать один класс именем MyClass1 и второй класс именем MyClass2. В классе MyClass1 создаем поле MyObj типа MyClass2.
Двунаправленная (или не направленная) — такая зависимость называется циклической зависимостью, она не рекомендуется к использованию. Чтобы создать такую конструкцию, нам нужно создать один класс именем MyClass1 и второй класс именем MyClass2. В классе MyClass1 создаем поле MyObj типа MyClass2. В классе MyClass2 создаем поле MyObj типа MyClass1.
Рефлексивная ассоциация (само-ассоциация) — с ней мы уже встречались, когда у нас в классе было создано поле типа этого же класса. Такая ассоциация выражается стрелочкой, которая выходит из нашего класса и в него же входит. То есть этот класс одновременно является и источником и целью.
Часто допускают такую ошибку , что само-ассоциацию некоторые программисты называют само-агрегацией. Дело в том, что само-агрегации не может быть по определению (ее не бывает). Почему? Потому что мы знаем что ассоциация это «знает о», агрегация — «состоит из», и мы не можем сказать что, например я состою из самого себя.
Теперь давайте рассмотрим какие есть диаграммы. Sequence Diagram — в этой диаграмме у нас находятся диаграммы объектов. То есть, если в диаграмме классов мы работали с классами, то в sequence diagram мы имеем дело с объектами. UseCase Diagram — эти диаграммы интересует больше бизнес-аналитика: «у нас есть система, у нас есть пользователь, этот пользователь взаимодействует с системой каким-то образом. «. Программистам редко приходится использовать такие диаграммы. UML Activity Diagram — такие диаграммы тоже описывает последовательности (такие диаграммы мы рассмотрим на курсе UML), они очень редко используются и скоро будут заменены диаграммами BPMN. UML Component diagrams — здесь у нас идет работа с компонентами. Компонент — это большой сложный объект и главный принцип компонента — он должен быть независимым. С такими компонентами приходится работать по определенным правилам — по контрактам. И, по правде сказать, язык C# не совсем объектно-ориентированный — он компонентно-ориентированный (объектная ориентация является основой для компонентной ориентации. Процедурная ориентация является основой для объектной ориентации). Layer diagram — здесь мы строим общее представление о приложении. Мы уже говорили, что в основном приложение делится на три слоя. Presentation Layer – там, где находится работа со всеми графическими составляющими, business layer – там, где у нас идет работа с бизнес объектами, и data layer.
Идем дальше. И сейчас мы рассмотрим использование техники в фабричных методов. У нас имеется класс Product , имеется конструктор, в котором мы вводим строку, имеется фабрика — это отдельный класс, в котором имеется специальный фабричный метод — это методы которые порождают продукты. И в итоге на 27 строке мы создаем фабрику, на 29 строке мы создаем локальную переменную product типа Product и присваиваем ей возвращаемое значение фабричного метода, внутри которого создается экземпляр класса Product на куче и возвращается ссылка на него. Эта ссылка присваивается вот этой переменной. И получается? что как в жизни: если мы, допустим, посмотрим на какую-нибудь кондитерскую фабрику — это большой объект, внутри которой стоят станки (фабричные методы), которые выплевывают из себя какой-то продукт.
Мы рассмотрели первую работу с фабриками и фабричными методами. И если вас интересует более углубленное изучение, вы можете зайти на наш видео портал, найти вебинар по паттернам проектирований и его посмотреть (там хорошо и очень детально описывается фабричный подход в программировании).
И теперь давайте посмотрим последний пример. На 5 строке создаем класс MyClass1, на седьмой строке конструктор оттеняет его работу выводом строки. На 13 строке мы создаем класс с именем MyClass2, на пятнадцатой строке мы создаем поле MyObj типа MyClass1 и зануляем его. Смотрите, что мы здесь пытаемся сделать. Мы в методе Method создаем экземпляр класса MyClass1. Можем ли мы назвать этот метод фабричным? Нет, фабричным методом мы можем назвать только тот метод, который имеет возвращаемое значение типом порождаемого этого продукта. А если происходит вот такое создание, то этот метод не является фабричным (таким способом не рекомендуется создавать объекты).
Мы подошли к концу этого урока давайте вернемся к презентации и посмотрим, что мы с вами сегодня изучали. Мы с вами изучали частичные классы (partial classes), такие понятия как частичные методы (partial methods), рассмотрели правила использования частичных методов, рассмотрели такую конструкцию языка как readonly, мы подошли к знакомству с языком uml, мы это сделали, потому что uml хорошо описывает различные объектно-ориентированные подходы, различные правила и, как мы видим, этот язык подходит не для программирования, а для моделирования объектно-ориентированных систем. Так же, мы рассмотрели с вами, какие у нас имеются диаграммы языка и связи отношений uml. Мы рассмотрели основные лексические единицы языка uml, как мы понимаем это прямоугольник, который называется классификатором, и линия, которая выражает собой различные связи отношений. Дальше мы рассмотрели более подробно о классификаторе, познакомились с таким понятием как стереотип, рассмотрели связи отношений, разобрали что такое ассоциация, агрегация и композиция, и поговорили вообще об объектно-ориентированном программировании, об его парадигмах. Об этом мы, конечно же, будем говорить еще много на протяжении всего курса. Будем повторять, будем расширять, будем исправлять те не полные иллюзии абстракции, которые мы готовы воспринять на таком уровне. Пока мы не можем все полностью понять, приходится что-то недоговаривать или говорить немножко искаженно, в упрощенной форме, чтобы потом вносить корректировки. Хорошо, мы тогда заканчиваем наш урок, спасибо за внимание, до новых встреч.
Как вернуть поддержку диаграмм классов в Visual Studio 2017
В среде разработки Visual Studio версий, предшествовавших версии 2017, имелся инструмент для создания диаграмм классов на языке моделирования DSL (не путать с UML ). В версии Visual Studio 2017 эти диаграммы могут не открываться. Чтобы восстановить поддержку старого дизайнера классов, можно попробовать сделать следующее.
В файле c:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\Managed\Microsoft.VisualBasic.DesignTime.targets (или аналогичный файл для C#, если вы программируете на C#) найти строку: и добавить в неё ClassDesigner, чтобы получилось
Теперь в проекте, в который нужно добавить диаграмму классов, создаём файл с расширением *.cd и вот таким содержимым:
Кстати, в меню добавления в проект нового элемента ( Ctrl+Shift+A ) имеется пункт «Диаграмма классов» (Class Diagram):
Графические языки моделирования DSL и UML формально предназначены для одного и того же: моделирование программных систем. Среда Visual Studio до версии 2015 поддерживала как диаграммы языка DSL, так и диаграммы UML. К сожалению, начиная с выпуска 2017, IDE более не поддерживает диаграммы UML. Подробнее об этом можно почитать в блоге одного из разработчиков Microsoft.