Разработчикам ПО комплекс помогает решать и автоматизировать множество практических задач, таких, как:

• Создание на уровне кода классов и объектов, соответствующих предметным сущностям и их отношениям;

• ORM (Object-Relational Mapping)  - объектно-реляционное отображение, хранение объектных данных в реляционных БД, в том числе объектов наследующихся классов;

• Поддержка различных реляционных СУБД и поддержка источников данных любой другой «природы»;

• Создание пользовательского интерфейса;

• Реализация системной архитектуры: от монолитной до распределённой многоуровневой;

Начало выполнения лабораторной работы

1. Запустите CASEBERRY

2. В ыберите репозитарий и добавьте новый проект. Назовите его «АСУ Склад <Ваша ФИО>»

3. Создайте конфигурацию, стадию и систему

Постановка задачи

Характеристики объекта автоматизации

Предприятие производит оптовую реализацию промышленной продукции широкого ассортимента. Поставщиками компании выступают заводы и фабрики, находящиеся на территории РФ. Клиенты предприятия – предприниматели, фирмы и др. организации, осуществляющие розничную и мелкооптовую продажу.

Постановка задачи на проектирование информационной системы

Проектируемая система обязана производить учет и контроль движения продуктов на складе. Автоматизировать процесс выписки накладных, счётов и других документов.

Описание бизнес-процесса «Реализация продукции со склада»

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

В случае если все затребованные клиентом позиции продуктов есть в наличии, либо клиентом приняты альтернативные варианты, заказ передается в бухгалтерию, и клиенту предлагается его оплатить.

Если клиент оплачивает заказ по наличному расчету, то после оплаты бухгалтер сразу выписывает две товарно-транспортные накладные, которые передаются клиенту.

После получения накладной клиент прибывает на склад за своим товаром. Кладовщик выдает необходимые продукты и делает отметку в обоих экземплярах накладной о том, что груз выдан. Далее, клиент расписывается в двух экземплярах накладной и отбывает с полученным товаром и одним экземпляром накладной. Второй экземпляр накладной остается у кладовщика.

Построение диаграммы вариантов использования (Usecase Diagram)

Краткие сведения о диаграмме вариантов использования.

Диаграмма вариантов использования является самым общим представлением функциональных требований к системе. Для последующего проектирования системы требуются более конкретные детали, которые описываются в документе, называемом «сценарием варианта использования» или «потоком событий» (flow of events). Сценарий подробно документирует процесс взаимодействия действующего лица с системой, реализуемого в рамках варианта использования. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок). Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные ситуации) и их обработку.

---

Достоинства модели вариантов использования заключаются в том, что она:

• определяет пользователей и границы системы;

• определяет системный интерфейс;

• удобна для общения пользователей с разработчиками;

• используется для написания тестов;

• является основой для написания пользовательской документации;

• хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).

Основные элементы диаграмм вариантов использования

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

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

Между активным субъектом и вариантом использования устанавливаются связь ассоциация (association relationship), которая выполняет коммуникативную функцию, сообщая о взаимодействии субъекта с системой в рамках определенного варианта использования. Направление связи указывает, кто (субъект или система) является инициатором взаимодействия.

Помимо связей между субъектом и вариантом использования, связи могут устанавливаться и между вариантами использования. Связи бывают двух типов - включающими (inclusive) и расширяющими (extensive).

Порядок построения Usecase Diagram

1. Создайте usecase диаграмму с именем «Основная функциональность»

2. Проанализируйте какие активные субъекты должны взаимодействовать с будущей системой.

3. Нарисуйте actor’ов. (Предлагается сделать 3: Менеджер, Бухгалтер и Кладовщик.)

4. Добавьте следующие прецеденты:

   1. Оформление заказа

   2. Оформление счёта

   3. Оформление накладной

   4. Выдача товара

5. Для пояснения можно использовать комментарии

6. Расставьте стрелки, обозначающие зависимость (подумайте какие прецеденты находятся в отношении зависимости)

7. Должна быть получена подобная диаграмма:

8. Сохраните диаграмму

Построение диаграммы видов деятельности (Activity Diagram)

Краткие теоретические сведения

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

Порядок построения диаграммы видов деятельности

---

1. Создайте диаграмму видов деятельности

2. В этом бизнес-процессе участвуют четыре объекта: клиент, менеджер, бухгалтер и кладовщик. Создайте дорожки (swimlanes) для каждого из объектов. Каждая из дорожек ответственна за выполнение определенных действий тем объектом, с которым она проассоциирована.

3. Далее необходимо расположить на диаграмме все деятельности/действия, которые выполняются тем или иным объектом.

4. Результат: диаграмма, представленная на рисунке:

5. Сохраните диаграмму.

Эта диаграмма также может оказаться опорной для построения диаграммы классов.

Построение диаграммы классов (Class Diagram)

После того, как мы определились с функциональными требованиями к системе и её границами, начнём анализировать предметную область с целью построения диаграммы классов.

Краткие теоретические сведения о диаграммах классов

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

О сновные элементы диаграммы классов

Основными элементами являются классы и связи между ними. Классы характеризуются при помощи атрибутов и операций.

Атрибуты описывают свойства объектов класса. Большинство объектов в классе получают свою индивидуальность из-за различий в их атрибутах и взаимосвязи с другими объектами. Однако, возможны объекты с идентичными значениями атрибутов и взаимосвязей. Т.е. индивидуальность объектов определяется самим фактом их существования, а не различиями в их свойствах. Имя атрибута должно быть уникально в пределах класса. За именем атрибута может следовать его тип и значение по умолчанию.

Операция есть функция или преобразование. Операция может параметризоваться и возвращать значения.

Виды связей: ассоциация, агрегация и наследование.

А ссоциация (association) – представляет собой отношения между экземплярами классов.

Каждый конец ассоциации обладает кратностью (синоним – мощностью, ориг. — multiplicity), которая показывает, сколько объектов, расположенных с соответствующего конца ассоциации, может участвовать в данном отношении. В примере на рисунке каждый Товар имеет сколь угодно Записей в накладной, но каждая Запись в накладной обязательно один Товар. В общем случае кратность может быть задана любым множеством.

Ассоциации может быть присвоено имя. В качестве имени обычно выбирается глагол или глагольное словосочетание, сообщающие смысл и назначение связи.

---

Также, на концах ассоциации под кратностью может указываться имя роли, т.е. какую роль выполняют объекты, находящиеся с данного конца ассоциации.

Агрегация (aggregation) – это ассоциация типа «целое-часть». Агрегация в UML представляется виде прямой с ромбом на конце.

Р омб на связи указывает, какой класс является агрегирующим (т.е. «состоящим из»), — класс с противоположного конца — агрегированным (т.е. те самые «части»).

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

Важно понимать разницу между агрегацией и композицией: при агрегации объекты-части могут существовать сами по себе, а при композиции — нет. Пример агрегации: автомобиль—колесо, пример композиции: дом—комната.

Наследование (inheritance) – это отношение типа «общее-частное». Позволяет определить такое отношение между классами, когда один класс обладает поведением и структурой ряда других классов. При создании производного класса на основе базового (одного или нескольких) возникает иерархия наследования. Реализация принципов наследования является ключевой предпосылкой возможности повторного использования кода, поскольку это основной инструмент достижения полиморфизма.

Порядок построения диаграммы классов

1. Создаём новую диаграмму с именем «Сущности».

2. Проанализируйте предметную область и постройте диаграмму классов. У вас должно получиться нечто подобное:

Давайте поподробнее рассмотрим эту диаграмму. Основной сущностью в нашей системе будет являться товар. Как мы знаем из задания на проектирование, товар хранится на складе. Но понятия товара как некоего описания и товара лежащего непосредственно на складе отличаются друг от друга. Товар, лежащий на складе, кроме того что связан со складом отношением композиции (агрегация не совсем подходит, поскольку в данной системе товар является товаром, пока он не покинет склад), ещё характеризуется количеством. Аналогично следует рассуждать и при рассмотрении отношения Товара и Заказа, Товара и Накладной. В связи с тем, что Заказ и Накладная в сущности являются документами и имеют сходные атрибуты, они были объединены с помощью общего класса-предка Документ. Также заметьте, что тут есть два класса со стереотипом «Enumeration» (перечисление). Стереотип можно установить из контекстного меню для класса.

3. Сохраните диаграмму

Построение диаграмм взаимодействия (Interaction diagram)

Краткие теоретические сведения

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

---

Для описания взаимодействия объектов, участвующих в некотором прецеденте, используются сценарии. Сценарий – это экземпляр прецедента, определяющий один из возможных потоков событий данного прецедента. Сам прецедент представляет собой переплетение сценариев – как основных, представляющих нормальное течение событий, так и вспомогательных, определяющих логику функционирования системы в ситуациях вида «что произойдет, если…». На ранних стадиях проектирования системы, как правило, ограничиваются рассмотрением основного сценария для каждого выявленного прецедента.

Для примера создадим реализацию прецедента «Оформление заказа»:

Построим для данной реализации диаграмму последовательностей, которая будет описывать сценарий размещения нового заказа.

Порядок построения диаграммы последовательностей (Sequence Diagram)

1. Создайте диаграмму последовательностей «Создание нового заказа»

2. На данной диаграмме отразим взаимодействие объектов классов: «Менеджер», «Списковая форма товаров на складе», «Списковая форма заказов», «Форма редактирования заказов», «Заказ», «Позиция Заказов». Построенная диаграмма представлена на рисунке:

3. Сохраните диаграмму.

Диаграммы последовательностей не только отображают взаимодействие объектов, но и позволяют определить/отыскать операции, которые должны иметь те или иные классы.

Краткие теоретические сведения

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

Создадим реализацию прецедента «Оформление накладных» - построим диаграмму кооперации для сценария «Печать накладной».

Построение диаграммы сотрудничества (Collaboration Diagram)

1. Создайте диаграмму сотрудничества

2. Разместите следующие элементы:

3. Сохраните диаграмму.

Построение диаграмм состояний (Statechart Diagram)

Диаграмма состояний определяет последовательность состояний объекта, вызванных последовательностью событий.

Порядок построения диаграммы

1. Создайте диаграмму состояний для объектов класса «Заказ».

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

• «Новый»;

• «Оплаченный»;

• «Отмененный».

В состояние «Новый» заказ попадает сразу после своего создания и находится в нем до момента перевода его менеджером в состояние «Оплаченный». Событием к переходу является поступление денег в кассу. Условие перехода – оплата должна производиться не позднее 10 дней со дня оформления заказа. В случае если оплата не производится в течение отведенных 10 дней или производится позже, заказ переходит в состояние «Отмененный». Соответствующая диаграмма состояний представлена на рисунке:

---

Смотрите также файлы

• Лаб. занятие 10.doc

• Лаб. занятие 7.doc

• Лаб. занятие 6.doc

• Лаб. занятие 5.doc

• Лаб. занятие 4.doc