книги / Проектирование автоматизированных информационных систем на основе объектно-ориентированного подхода
..pdfПо прибытии клиента на склад кладовщик отпускает товар (соб ранный заказ). Спецификация на прецедент «Выдача товара клиенту» приведена в табл. П3.6.
|
|
Т аблиц а П 3.6 |
1.0. |
Наименование |
Выдача товара клиенту |
|
прецедента |
|
|
|
|
1.1 |
Краткое |
Прецедент инициируется актером «Клиент» и за |
|
описание |
ключается в выдаче выполненного заказа. |
2.0Потоки событий
2.1 Основной поток |
Клиент прибывает на склад и обращается к одно |
|
му из кладовщиков. |
|
Кладовщик проверяет наличие накладной клиента |
|
в списке готовых накладных в форме «Работа с на |
|
кладными» системы управления складом (если на |
|
кладной нет в этом списке, то активизируется поток |
|
2.2.). Далее кладовщик выдает товар клиенту и остав |
|
ляет необходимые записи и свою подпись в обоих эк |
|
земплярах накладной. Один экземпляр остается у кла |
|
довщика, а второй у клиента. |
|
В электронном документе кладовщик проставляет |
|
дату фактической отгрузки. Накладная получает ста |
|
тус «отгруженная» и начинает отображаться в третьем |
|
списке формы - отгруженных накладных. |
2.2Альтернативные Накладной нет в списке готовых накладных: по
|
потоки |
накладной еще не собран заказ либо отгрузка приоста |
|
|
новлена. Возникшие в этом случае проблемы решает |
|
|
кладовщик вместе с менеджером, ведущим заказ. |
3.0 |
Специальные |
Не определены. |
|
требования |
|
4.0 |
Предусловия |
Не определены. |
5.0 |
Постусловия |
Не определены. |
6.0Дополнительные Нет. замечания
5. Диаграмма классов
Прежде чем перейти к построению диаграммы классов, необходимо определить словарь предметной области. Источником в этом случае мо гут выступать спецификации описанных прецедентов. Так, например, в результате исследования спецификаций были выявлены следующие классы: предприятие, склад, клиент, продукт, менеджер, бухгалтер, логист, экспедитор, кладовщик, счет, накладная, план закупок и др.
Конечным результатом нашей работы будет являться создание программного кода системы управления складом, поэтому названия классов, атрибутов, операций и т.д., будем записывать с использова нием английского языка.
В общем случае из диаграммы классов можно получить про граммный текст для множества различных языков программирования. Мы будем ориентироваться на язык C++. В этом случае для каждого построенного класса необходимо создать конструктор, деструктор, а для каждого атрибута класса методы чтения (get) и установки атри бутов (set). Все эти функции являются стандартными и создаются ав томатически системой Rational Rose в том случае, даже если они явно не указаны. Поэтому при описании классов стандартные операции по чтению/записи атрибутов, а также конструкторы/деструкторы указы вать не будем. Автоматическая генерация методов get/set может быть отключена на закладке «C++» окна спецификации атрибутов (позиции
GenerateGetOperation, GenerateSetOperatiori).
5.1. Определение структуры предприятия
оптовой торговли
Начнем построение диаграмм классов с определения структуры нашего предприятия.
Наиболее общим классом, характеризующим предприятие, являет ся класс «Company» (предприятие). Данный класс содержит атрибуты:
-name (название предприятия);
-INN (ИНН);
-juridicalAddress (юридический адрес);
-postAddres (почтовый адрес);
-phoneNumber (телефонный номер);
-faxNumber (номер факса).
Предприятие структурно состоит из складов и офисов, послед ние, в свою очередь, состоят из отделов. Соответствующая диаграм ма классов представлена на рис. П3.5.
Рис. П3.5. Структура предприятия оптовой торговли
Помимо класса «Company» на диаграмме классов, изображенной на рис. П3.5, представлены классы: «Warehouse» (склад), «Office» (офис) и «Department» (отдел).
Перечисленные новые классы содержат атрибуты:
-name (название склада/офиса/отдела);
-address (фактический адрес склада/офиса);
-phoneNumber (основной телефонный номер склада/отдела).
Из диаграммы видно, что предприятие должно иметь как мини мум один склад и один офис, состоящий не менее чем из одного от дела. Диаграмма была построена с учетом того, что мы не подразде ляем склад на какие-либо отделы, в отличие от офиса.
Менеджер, бухгалтер, кладовщик и другие работники склада и офиса являются сотрудниками предприятия. Каждый сотрудник предприятия характеризуется фамилией, именем, отчеством, табель ным номером, датой рождения и другой ценной информацией. Все эти данные объединяются в классе «Employee» (сотрудник). Список атрибутов данного класса следующий:
-tblNumber (табельный номер);
-lastName (фамилия);
-fisrtName (имя);
-secondName (отчество);
-birthday (дата рождения);
-sex (пол);
-inDate (дата приема на работу);
-phoneNumber (номер телефона);
-eMail (адрес электронной почты).
Следующие два класса, которые будут добавлены в модель, на следуют структуру и поведение класса «Employee» и называются «WarehouseWorker» (работник склада) и «OfficeWorker» (работник офиса) (рис. П3.6). Данные классы содержат по одному атрибуту. Класс «WarehouseWorker» содержит атрибут булева типа «геsponsPerson» (материально ответственное лицо). В случае установки этого атрибута в истину экземпляр класса будет рассматриваться как материально ответственное лицо. Класс «OfficeWorker» содержит ат рибут «roomNumber» (номер комнаты), который отражает номер комнаты, занимаемой сотрудником офиса.
Рис. П3.6. Сотрудник предприятия
Работник склада работает на складе, а работник офиса, соответ ственно, в отделе офиса. Таким образом, мы можем построить от дельную диаграмму классов и отобразить на ней ассоциативные от ношения между классом «WarehouseWorker» и «Warehouse», классом «OfficeWorker» и «Department» (рис. П3.7).
Рис. П3.7. Отношения ассоциации
Теперь настало время определить такие классы, как «Manager» (ме неджер), «Accountant» (бухгалтер), «Storekeeper» (кладовщик) и т.п. Эти классы определяют конкретную роль сотрудника в системе и на пред приятии в целом. Все эти классы наследуют свою структуру от класса «QfficeWorker» либо от класса «WarehouseWorker» (рис. П3.8).
Рис. П3.8. Отношения наследования
Большинство сотрудников предприятия являются пользователя ми системы управления складом. Пользователь системы - это от дельный класс, содержащий информацию о регистрации пользовате ля в системе и об уровне его доступа к определенным операциям и объектам системы. Назовем этот класс «SystemUser».
1..П
Warehouse
%name : char* ^address : charx %phoneNumber : char’ %faxNumber: char*
Company
%name : char* fclNN : float
%juridicalAddress : char* %postAddress : charx %phoneNumber: charx 4bfaxNumber : charx
Employee
%tblNumber: int ^astName : char* ^firstName : char* ^secondName : char* ^birthday : charx %sex : int
^inDate : char* %phoneNumber: charx %e№il
1..n Offioe Црпате : charx ^address : charx
T
1..n
Department
%name : charx ^pphoneNumber: char’ %faxNumber : charx
T
1..n |
I |
WarehouseWorker |
1..n |
OfficeWorker |
|
%responsPerson : int |
ЦртоотNumber: char* |
I
X
Storekeeper |
Guardian |
Driver |
Director |
Manager |
Accountant |
Legist |
|
|
SystemUser |
0..1 |
|
|
|
|
|
|
|
|
|
|
|
|
^name : charx |
0..1 |
|
|
|
|
|
^password : charx |
|
|
|
|
|
|
0..1 %accessLevel ; int |
0..1 |
|
|
|
^registerO
Рис. П3.10. Структура предприятия и сотрудники
Класс содержит следующие атрибуты и операции:
-паше (уникальное имя пользователя системы);
-password (пароль пользователя системы);
-accessLevel (уровень доступа);
-register() (операция регистрации пользователя).
Данный класс ассоциативно связан с такими классами, как «Store' keeper», «Manager» и др. (рис. П3.9).