Отношение включения
Отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования. Данное отношение является направленным бинарным отношением в том смысле, что пара экземпляров вариантов использования всегда упорядочена в отношении включения.
Семантика этого отношения определяется следующим образом. Когда экземпляр первого варианта использования в процессе своего выполнения достигает точки включения в последовательность поведения экземпляра второго варианта использования, экземпляр первого варианта использования выполняет последовательность действий, определяющую поведение экземпляра второго варианта использования, после чего продолжает выполнение действий своего поведения. При этом предполагается, что даже если экземпляр первого варианта использования может иметь несколько включаемых в себя экземпляров других вариантов, выполняемые ими действия должны закончиться к некоторому моменту, после чего должно быть продолжено выполнение прерванных действий экземпляра первого варианта использования в соответствии с заданным для него поведением.
Один вариант использования может быть включен в несколько других вариантов, а также включать в себя другие варианты. Включаемый вариант использования может быть независимым от базового варианта в том смысле, что он предоставляет последнему некоторое инкапсулированное поведение, детали реализации которого скрыты от последнего и могут быть легко перераспределены между несколькими включаемыми вариантами использования. Более того, базовый вариант может зависеть только от результатов выполнения включаемого в него поведения, но не от структуры включаемых в него вариантов.
Отношение включения, направленное от варианта использования А к варианту использования В, указывает, что каждый экземпляр варианта А включает в себя функциональные свойства, заданные для варианта В. Эти свойства специализируют поведение соответствующего варианта А на данной диаграмме. Графически данное отношение обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от базового варианта использования к включаемому. При этом данная линия со стрелкой помечается ключевым словом «include» («включает»), как показано на рисунок 11.
Рисунок 11. Пример графического изображения отношения включения между вариантами использования
Следует заметить, что рассмотренные три последних отношения могут существовать только между вариантами использования, которые определены для одной и той же сущности. Причина этого заключается в том, что поведение некоторой сущности обусловлено вариантами использования только этой сущности. Другими словами, все экземпляры варианта использования выполняются лишь внутри данной сущности. Если некоторый вариант использования должен иметь отношение обобщения, включения или расширения с вариантом использования другой сущности, получаемые в результате экземпляры вариантов должны быть включены в обе сущности, что противоречит семантическим правилам представления элементов языка UML. Однако эти отношения, определенные в пределах одной сущности, могут быть использованы в пределах другой сущности, если обе сущности связаны между собой отношением обобщения. В этом случае поведение соответствующих вариантов использования подчиняется общим правилам наследования свойств и поведения сущности‑предка всеми дочерними сущностями.
В качестве примера рассмотрим процесс моделирования системы продажи товаров по каталогу, которая может быть использована при создании соответствующих информационных систем. В качестве актеров данной системы могут выступать два субъекта, один из которых является продавцом, а другой - покупателем. Каждый из этих актеров взаимодействует с рассматриваемой системой продажи товаров по каталогу и является ее пользователем, т. е. они оба обращаются к соответствующему сервису "Оформить заказ на покупку товара". Как следует из существа выдвигаемых к системе требований, этот сервис выступает в качестве варианта использования разрабатываемой диаграммы, первоначальная структура которой может включать в себя только двух указанных актеров и единственный вариант использования (рис. 12).
Рис. 12. Исходная диаграмма вариантов использования для примера разработки системы продажи товаров по каталогу Значения указанных на данной диаграмме кратностей отражают общие правила или логику оформления заказов на покупку товаров. Согласно этим правилам, один продавец может участвовать в оформлении нескольких заказов, в то же время каждый заказ может быть оформлен только одним продавцом, который несет ответственность за корректность его оформления и, в связи с этим, будет иметь агентское вознаграждение за его оформление. С другой стороны, каждый покупатель может оформлять на себя несколько заказов, но, в то же время, каждый заказ должен быть оформлен на единственного покупателя, к которому переходят права собственности на товар после его оплаты.
На следующем этапе разработки данной диаграммы вариант использования "Оформить заказ на покупку товара" может быть уточнен на основе введения в рассмотрение четырех дополнительных вариантов использования. Это следует из более детального анализа процесса продажи товаров, что позволяет выделить в качестве отдельных сервисов такие действия, как обеспечить покупателя информацией о товаре, согласовать условия оплаты товара и заказать товар со склада. Вполне очевидно, что указанные действия раскрывают поведение исходного варианта использования в смысле его конкретизации, и поэтому между ними будет иметь место отношение включения. С другой стороны, продажа товаров по каталогу предполагает наличие самостоятельного информационного объекта - каталога товаров, который в некотором смысле не зависит от реализации сервиса по обслуживанию покупателей. В нашем случае, каталог товаров может запрашиваться покупателем или продавцом при необходимости выбора товара и уточнения деталей его продажи. Вполне резонно представить сервис "Запросить каталог товаров" в качестве самостоятельного варианта использования. Полученная в результате последующей детализации уточненная диаграмма вариантов использования будет содержать 5 вариантов использования и 2 актеров (рис. 13), между которыми установлены отношения включения и расширения.
Рис. 13. Уточненный вариант диаграммы вариантов использования для примера системы продажи товаров по каталогу Приведенная выше диаграмма вариантов использования, в свою очередь, может быть детализирована далее с целью более глубокого уточнения предъявляемых к системе требований и конкретизации деталей ее последующей реализации. В рамках общей парадигмы ООАП подобная детализация может выполняться в двух основных направлениях. С одной стороны, детализация может быть выполнена на основе установления дополнительных отношений типа отношения "обобщение-специализация" для уже имеющихся компонентов диаграммы вариантов использования. Так, в рамках рассматриваемой системы продажи товаров может иметь самостоятельное значение и специфические особенности отдельная категория товаров - компьютеры. В этом случае диаграмма может быть дополнена вариантом использования "Оформить заказ на покупку компьютера" и актерами "Покупатель компьютера" и "Продавец компьютеров", которые связаны с соответствующими компонентами диаграммы отношением обобщения (рис. 4.14). Уточненный таким способом вариант диаграммы вариантов использования содержит одну важную особенность, которую необходимо отметить. А именно, хотя на данной диаграмме (рис. 4.14) отсутствуют изображения линий отношения ассоциации между актером "Продавец компьютеров" и вариантом использования "Оформить заказ на покупку компьютера", а также между актером "Покупатель компьютера" и вариантом использования "Оформить заказ на покупку компьютера", наличие отношения обобщения между соответствующими компонентами позволяет им наследовать отношение ассоциации от своих предков. Поскольку принцип наследования является одним из фундаментальных принципов объектно-ориентированного программирования, в нашем примере можно с уверенностью утверждать, что эти линии отношения ассоциации с соответствующими кратностями присутствуют на данной диаграмме в скрытом виде.
Рис. 14. Один из вариантов последующего уточнения диаграммы вариантов использования для примера рассматриваемой системы продажи Для пояснения изложенного можно привести фрагмент диаграммы вариантов использования для рассмотренного примера, на котором явно указаны отношения ассоциации между дочерними компонентами (рис. 15). Данное изображение фрагмента диаграммы приводится с методической целью, при этом остальные компоненты диаграммы, которые остались без изменений, условно отмечены многоточием.
Рис. 15. Фрагмент диаграммы вариантов использования, который в неявном виде присутствует на уточненной диаграмме с отношением ассоциации между отдельными компонентами
Второе из основных направлений детализации диаграмм вариантов использования связано с последующей структуризацией ее отдельных компонентов в форме элементов других диаграмм. Например, конкретные особенности реализации вариантов использования в терминах взаимодействующих объектов, определенных в виде классов данной сущности, могут быть заданы на диаграмме кооперации. Указанное направление отражает основные особенности ООАП применительно к их реализации в языке UML. Эти особенности являются предметом рассмотрения во всех последующих главах книги. Построение диаграммы вариантов использования является самым первым этапом процесса объектно-ориентированного анализа и проектирования, цель которого - представить совокупность требований к поведению проектируемой системы. Спецификация требований к проектируемой системе в форме диаграммы вариантов использования представляет собой самостоятельную модель, которая в языке UML получила название модели вариантов использования и имеет свое специальное стандартное имя или стереотип "useCaseModel".
Задача1
Построение диаграммы вариантов использования при открытии расчетного счета в банке (Рисунок 1).
Рисунок 1 - Диаграмма вариантов использования при открытии расчетного счета в банке
Для того чтобы построить эту диаграмму, необходимо открыть Microsoft Office Visio 2007(Рисунок 2).
Рисунок 2 – Главное окно Microsoft Visio 2007
Откроется интерфейс программы с предложенным Каталогом шаблонов, в котором выбираем вкладку Программное обеспечение и базы данных. Из Готовых шаблонов выберем значок Схема модели UML и нажмем кнопку Создать на панели справа. После нажатия кнопки откроется новый документ MS Visio (Рисунок 3).
Рисунок 3 – Новый документ MS Visio
Слева от нового документа открывается панель Фигуры и Проводник по моделям, в которой можно будет подобрать необходимые фигуры для построения модели, а также появляется удобный способ для навигации по модели. Затем при помощи мышки нужно перенести на новый документ 1 фигуру Актера, 5 фигур Сценарий выполнения и стрелки-отношения обозначающие Обобщение и Зависимость (Рисунок 4). Фигуры лучше выбрать во вкладке Сценарий выполнения UML и Статическая структура UML.
Рисунок 4 - Размещение фигур на документе
После этого нужно присвоить имена фигурам Актер, Сценарий выполнения (1-5) и добавить значения других свойств. Откройте диалоговое окно Свойства UML для данного элемента, дважды щелкнув значок элемента в представлении в виде дерева (Представление дерева. Отображается в окне в навигаторе UML. Иерархическая структура, в которой элемент или представление (диаграмма) UML представлены пиктограммами. Шаблон UML автоматически создает представление дерева модели.) или фигуру, представляющую элемент на схеме, и внесите данные. Чтобы отобразить или скрыть значения свойств, щелкните фигуру правой кнопкой мыши, выберите команду Параметры отображения фигуры, а затем установите или снимите соответствующие флажки. Получится диаграмма как на рисунке 5.
Рисунок 5 –Окончательная диаграмма вариантов использования
Задача2
Построение диаграммы вариантов использования для АИС ЖКХ
АИС выполняет следующие функции:
ввод в данных о сотрудниках, жильцах;
добавление данных о сотрудниках, жильцах;
ввод данных по тарифам;
ввод данных по первичным банковским и бухгалтерским документам;
корректировка данных при необходимости;
формирование финансовых бухгалтерских отчетов;
формирование документов для подготовки отчетности в налоговые и другие контролирующие органы.
База данных указанной системы содержит:
данные о сотрудниках предприятия;
данные о жильцах обслуживаемого дома;
данные по тарифам на услуги ЖКХ;
первоначальные остатки по счетам бухгалтерского учета;
справочник поставщиков услуг и прочих организаций;
справочник банков;
константы, учетную политику и сведения об организации;
данные о наличии льготных категорий жильцов.
Решение
На самой диаграмме Актерами изображены главный бухгалтер и жильцы дома, они напрямую взаимодействуют друг с другом, а предметом взаимодействия являются квитанции на оплату ЖКУ.
Варианты использования имеют индивидуальные названия и подразумевают собой отдельные сегменты для программирования в системе, они изображены в виде овалов. Между вариантами существуют различные связи (отношения):
зависимости – изображены пунктиром, а стрелка указывает на то, кто от кого зависит;
обобщения – изображены сплошной линией со стрелкой, стрелка также указывает на направленность воплощения сущностей;
ассоциации - изображены сплошной линией без стрелок и показывают связь между объектами.
Диграмма имеет вид (рисунок6)
Рисунок 6 – Диаграмма вариантов использования
Общие сведения
Диаграммы классов
Центральное место в методологии ООАП занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов отражает, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов может служить дальнейшим развитием концептуальной модели проектируемой системы Диаграмма классов (class diagram) — диаграмма языка UML, на которой представлена совокупность декларативных или статических элементов модели, таких как классы с атрибутами и операциями, а также связывающие их отношения. Диаграмма классов предназначена для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. При этом диаграмма классов может содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры классификаторов, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы, т. е. графическое представление таких структурных взаимосвязей логической модели системы, которые не зависят от времени. Класс Класс (class) — абстрактное описание множества однородных объектов, имеющих одинаковые атрибуты, операции и отношения с объектами других классов. Графически класс в нотации языка UML изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции (рисунок 5.1). В этих секциях могут указываться имя класса, атрибуты и операции класса.
Риунок 1 - Варианты графического изображения класса на диаграмме классов На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником, в котором должно быть указано имя соответствующего класса (рисунок 1, а). По мере проработки отдельных компонентов диаграммы описание классов дополняется атрибутами (рисунок 1, б) и операциями (рисунок 1, в). Четвертая секция (рисунок 1, г) не обязательна и служит для размещения дополнительной информации справочного характера, например, об исключениях или ограничениях класса, сведения о разработчике или языке реализации. Предполагается, что окончательный вариант диаграммы содержит наиболее полное описание классов, которые состоят из трех или четырех секций. Даже если секции атрибутов и операций пусты, в обозначении класса они должны быть выделены горизонтальной линией, с тем чтобы отличить класс от других элементов языка UML. Примеры графического изображения конкретных классов приведены на рисунок 2. В первом случае для класса Окружность (рисунок 2, а) указаны только его атрибуты – точка на координатной плоскости, которая определяет расположение ее центра. Для класса Окно (рисунок2, б) указаны только его операции, при этом секция его атрибутов оставлена пустой. Для класса Счет (рисунок 2, в) дополнительно изображена четвертая секция, в которой указано требование – реализовать резервное копирование объектов этого класса.
Рисунок 5.2. Примеры графического изображения конкретных классов Имя класса Имя класса должно быть уникальным в пределах пакета, который может содержать одну или несколько диаграмм классов. Имя указывается в самой верхней секции прямоугольника, поэтому она часто называется секцией имени класса. В дополнение к общему правилу именования элементов языка UML, имя класса записывается по центру секции имени полужирным шрифтом и должно начинаться с заглавной буквы. Рекомендуется в качестве имен классов использовать существительные, записанные по практическим соображениям без пробелов. Необходимо помнить, что имена классов образуют словарь предметной области при ООАП. В секции имени класса могут также находиться стереотипы или ссылки на стандартные шаблоны, от которых образован данный класс и, соответственно, от которых он наследует атрибуты и операции. В этой секции может также приводиться информация о разработчике данного класса и статус состояния разработки. Здесь также могут записываться и другие общие свойства этого класса, имеющие отношение к другим классам диаграммы или стандартным элементам языка UML. Класс может иметь или не иметь экземпляров или объектов. В зависимости от этого в языке UML различают конкретные и абстрактные классы. Конкретный класс (concrete class) — класс, на основе которого могут быть непосредственно созданы экземпляры или объекты. Рассмотренные выше обозначения относятся к конкретным классам. От них следует отличать абстрактные классы. Абстрактный класс (abstract class) — класс, который не имеет экземпляров или объектов. Для обозначения имени абстрактного класса используется наклонный шрифт (курсив). В языке UML принято общее соглашение о том, что любой текст, относящийся к абстрактному элементу, записывается курсивом. Это имеет принципиальное значение, поскольку является семантическим аспектом описания абстрактных элементов языка UML. В некоторых случаях необходимо явно указать, к какому пакету относится тот или иной класс. Для этой цели используется специальный символ разделитель – двойное двоеточие - (::). Синтаксис строки имени класса в этом случае будет следующий: <Имя пакета>::<Имя класса>. Другими словами, перед именем класса должно быть явно указано имя пакета, к которому его следует отнести. Например, если определен пакет с именем Банк, то класс Счет в этом банке может быть записан в виде: Банк::Счет. |
|
Атрибуты класса Атрибут (attribute) — содержательная характеристика класса, описывающая множество значений, которые могут принимать отдельные объекты этого класса. Атрибут класса служит для представления отдельного свойства или признака, который является общим для всех объектов данного класса. Атрибуты класса записываются во второй сверху секции прямоугольника класса. Эту секцию часто называют секцией атрибутов. В языке UML принята определенная стандартизация записи атрибутов класса, которая подчиняется некоторым синтаксическим правилам. Каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута, имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного значения. Общий формат записи отдельного атрибута класса следующий: <квантор видимости> <имя атрибута> [кратность] : <тип атрибута> = <исходное значение> {строка-свойство}. Видимость (visibility) — качественная характеристика описания элементов класса, характеризующая потенциальную возможность других объектов модели оказывать влияние на отдельные аспекты поведения данного класса. Видимость в языке UML специфицируется с помощью квантора видимости (visibility), который может принимать одно из 4-х возможных значений и отображаться при помощи специальных символов.
Квантор видимости может быть опущен. Его отсутствие означает, что видимость атрибута не указывается. Эта ситуация отличается от принятых по умолчанию соглашений в традиционных языках программирования, когда отсутствие квантора видимости трактуется как public или private. Однако вместо условных графических обозначений можно записывать соответствующее ключевое слово: public, protected, private, package. Имя атрибута представляет собой строку текста, которая используется в качестве идентификатора соответствующего атрибута и поэтому должна быть уникальной в пределах данного класса. Имя атрибута - единственный обязательный элемент синтаксического обозначения атрибута, должно начинаться со строчной (малой) буквы и не должно содержать пробелов. |
|
Операции класса Операция (operation) - это сервис, предоставляемый каждым экземпляром или объектом класса по требованию своих клиентов, в качестве которых могут выступать другие объекты, в том числе и экземпляры данного класса. Операции класса записываются в третьей сверху секции прямоугольника класса, которую часто называют секцией операций. Совокупность операций характеризует функциональный аспект поведения всех объектов данного класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого операцией значения и, возможно, строка-свойство данной операции. Общий формат записи отдельной операции класса следующий: <квантор видимости> <имя операции>( список параметров): <выражение типа возвращаемого значения> {строка-свойство} Квантор видимости, как и в случае атрибутов класса, может принимать одно из четырех возможных значений и, соответственно, отображается при помощи специального символа либо ключевого слова. Символ "+" обозначает операцию с областью видимости типа общедоступный (public). Символ "#" обозначает операцию с областью видимости типа защищенный (protected). Символ "-" используется для обозначения операции с областью видимости типа закрытый (private). И, наконец, символ "~" используется для обозначения операции с областью видимости типа пакетный (package). Квантор видимости для операции может быть опущен. В этом случае его отсутствие просто означает, что видимость операции не указывается. Вместо условных графических обозначений также можно записывать соответствующее ключевое слово: public, protected, private, package. Имя операции представляет собой строку текста, которая используется в качестве идентификатора соответствующей операции и поэтому должна быть уникальной в пределах данного класса. Имя операции - единственный обязательный элемент синтаксического обозначения операции, должно начинаться со строчной (малой) буквы, и, как правило, записываться без пробелов. Список параметров является перечнем разделенных запятой формальных параметров, каждый из которых, в свою очередь, может быть представлен в следующем виде: <направление параметра> <имя параметра>: <выражение типа> = <значение параметра по умолчанию>. Параметр (parameter) — спецификация переменной операции, которая может быть изменена, передана или возвращена. Параметр может включать имя, тип, направление и значение по умолчанию. Направление параметра — есть одно из ключевых слов in, out или inout со значением in по умолчанию, в случае если вид параметра не указывается. Имя параметра есть идентификатор соответствующего формального параметра, при записи которого следуют правилам задания имен атрибутов. Выражение типа является спецификацией типа данных для допустимых значений соответствующего формального параметра. Наконец, значение по умолчанию в общем случае представляет собой некоторое конкретное значение для этого формального параметра. Выражение типа возвращаемого значения также указывает на тип данных значения, которое возвращается объектом после выполнения соответствующей операции. Две точки и выражение типа возвращаемого значения могут быть опущены, если операция не возвращает никакого значения. Для указания нескольких возвращаемых значений данный элемент спецификации операции может быть записан в виде списка отдельных выражений. Операция с областью действия на весь класс показывается подчеркиванием имени и строки выражения типа. В этом случае под областью действия операции понимаются все объекты этого класса. В этом случае вся строка записи операции подчеркивается. Строка-свойство служит для указания значений свойств, которые могут быть применены к данной операции. Строка-свойство может отсутствовать, если свойства не специфицированы. Список формальных параметров и тип возвращаемого значения не обязателен. Квантор видимости атрибутов и операций может быть указан в виде специального значка или символа, которые используются для графического представления моделей в инструментальном средстве. Еще раз следует напомнить, что имена операций, так же как атрибутов и параметров, записываются со строчной (малой) буквы, а их типы параметров — с заглавной (большой) буквы. При этом обязательной частью строки записи операции является наличие имени операции и круглых скобок. |
Расширение языка UML для построения моделей программного обеспечения и бизнес-систем Одним из несомненных достоинств языка UML является наличие механизмов расширения, которые позволяют ввести в рассмотрение дополнительные графические обозначения, ориентированные для решения задач из определенной предметной области. Язык UML содержит два специальных расширения: профиль для процесса разработки программного обеспечения (The UML Profile for Software Development Processes) и профиль для бизнес-моделирования (The UML Profile for Business Modeling). В рамках первого из них предложено три специальных графических примитива, которые могут быть использованы для уточнения семантики отдельных классов при построении различных диаграмм:
Рисунок 5.3. Графическое изображение классов для моделирования программного обеспечения В рамках второго профиля также предложено три специальных графических примитива, которые могут быть использованы для уточнения семантики отдельных классов при построении моделей бизнес-систем:
Рисунок 5.4. Графическое изображение классов для моделирования бизнес-систем Интерфейс Интерфейс (interface) — именованное множество операций, которые характеризуют поведение отдельного элемента модели. Интерфейс в контексте языка UML является специальным случаем класса, у которого имеются операции, но отсутствуют атрибуты. Для обозначения интерфейса используется специальный графический символ окружность или стандартный способ – прямоугольник класса со стереотипом <<interface>> (рисунок 5). На диаграмме вариантов использования интерфейс изображается в виде маленького круга, рядом с которым записывается его имя (рисунок 5, а). В качестве имени может использоваться существительное, которое характеризует соответствующую информацию или сервис, например, "Датчик температуры", "Форма ввода", "Сирена", "Видеокамера" (рисунок 5, б). С учетом языка реализации модели имя интерфейса, как и имена других классов, рекомендуется записывать на английском и начинать с заглавной буквы I, например, ITemperatureSensor, IsecureInformation (рисунок 5, в).
Рисунок 5.5. Примеры графического изображения интерфейсов на диаграммах классов Интерфейсы на диаграмме служат для спецификации таких элементов модели, которые видимы извне, но их внутренняя структура остается скрытой от клиентов. Интерфейсы не могут содержать ни атрибутов, ни состояний, ни направленных ассоциаций. Они содержат только операции без указания особенностей их реализации. Формально интерфейс не только отделяет спецификацию операций системы от их реализации, но и определяет общие границы проектируемой системы. В последующем интерфейс может быть уточнен явным указанием тех операций, которые специфицируют отдельный аспект поведения системы. Графическое изображение интерфейсов в форме окружности могут использоваться и на других типах канонических диаграмм, например, диаграммах компонентов и развертывания. |
Задача 3
Построить диаграмму классов для АИС ЖКХ
Решение
На диаграмме обозначены следующие классы:
«Ввод первичной документации» - это элемент, который включает в себя ввод банковских выписок. Во вкладке Операции указаны операции, которые являются обязательными в этом процессе и без которых дальнейшая работа не возможна.
«Ввод данных по начислениям» - здесь указаны те поля, которые обязательно заполняются в каждой квитанции, а также действия, связанные с этим.
«Корректировка справочника Жильцы» - здесь вносятся необходимые изменения в справочник Жильцы.
«Корректировка журнала тарифов» - в этот журнал вносятся изменения ежемесячно перед заполнением квитанций.
«Оформление квитанций на оплату ЖКУ» - в этом сегменте происходит процесс заполнения квитанций, а также формирование задолженности по каждому жильцу.
«Вывод на бумажный носитель» - здесь происходит распечатывание квитанций с указанием соответствующих реквизитов, табличных частей, а затем подписывается главным бухгалтером.
«Главный бухгалтер» - человек, который несет ответственность за своевременное представление начислений, оформление квитанций на оплату, формирование отчетности и ведение бухгалтерского учета в целом.
«Жильцы» - этот элемент подразумевает жильцов обслуживаемого дома. Они являются получателями заполненных квитанций.
«Вывод сводного отчета для руководителя» - здесь формируется один или несколько отчетов для руководителя организации для наглядного отображения результатов деятельности за указанный период.
Диаграмма, выполненная в среде VISIO, имеет вид (рисунок 7)
Рисунок 7 – Диаграмма классов
Здания для самостоятельного выполнения.
Разработать диаграммы вариантов использования и классов для:
кассира
экономиста;
менеджера гипермаркета;
регистратора в лечебном учреждении;
сотрудника отдела кадров;
маркетолога;
инженера по охране труда и технике безопасности.
Оформить диаграммы и сделать выводы по работе.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ И ЛИТЕРАТУРЫ
Электронныйресурс. Режим доступа http://www.business-process.ru/designing/methodology/uml/theory/class_diagram_theory.html
Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS. 2-е изд. / Пер. с англ.; Под общей редакцией проф. С. Орлова — СПб.: Питер, 2006. — 736 с.
Джозеф Шмуллер. Освой самостоятельно UML 2 за 24 часа. Практическое руководство = Sams Teach Yourself UML in 24 Hours, Complete Starter Kit. — М.: Вильямс, 2005. — 416 с.
Крэг Ларман. Применение UML 2.0 и шаблонов проектирования = Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development. — 3-е изд. — М.: Вильямс, 2006. — 736 с.
Советов Б.Я., Яковлев С.А. Моделирование систем: Учебник для вузов. – М.: Высшая школа, 2005. – 320 с.
Колесов Ю.Б., Сениченков Ю.Б. Моделирование систем. Практикум по компьютерному моделированию. – Спб.: БХВ-Петербург, 2005. – 282 с.
Проектирование программного обеспечения экономических информационных систем – Вендров А.М.: М., ФИС 2005 – 352сОбъектно – ориентированный анализ и проектирование с примерами приложений на С++ - Гради Буч: Бином 2001 – 560с.: ил. – ISBN 5-7989-0067-3
Самоучитель UML 2 – Леоненков А.: СПБ. , БХВ – Петербург 2007 – 576с