Вы просматриваете: Главная > Без рубрики > Приемы работы в MS Visual Studio 2010 для создания классов

Приемы работы в 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%.

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

Служащие имеют право выбирать способ оплаты за работу. Они могут получать свои чеки на оплату по почте, на счет в банке или на руки в офисе.

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

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

источник

Метки:


Оставить отзыв