Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, информационных систем, организационно-экономических систем, технических систем и других систем различной природы.
UML позволяет создать своеобразный чертеж, подробно описывающий архитектуру информационной системы. С помощью такого описания (или модели) упрощается разработка и обновление информационной системы, а также гарантируется реализация всех технических требований к разрабатываемым приложениям.
Среда Microsoft Visual Studio 2010 является лидирующей в области ускоренной разработки и поддерживает разнообразные диаграммы UML: вариантов использования, активности, последовательности, кооперативные, состояний, компонентов и размещения. Средства Microsoft Visual Studio 2010 для инжиниринга и реинжиниринга обеспечивают поддержку языков C#, Java, Visual Basic, Visual F и DTD XML. Дополнительные надстройки для среды Microsoft Visual Studio 2010 позволяют расширить ее функции и работать с другими объектно-ориентированными языками программирования.
UML разрабатывался для поддержки таких ценных наработок проектирования, как инкапсуляция, разделение сущностей и выявление сути конструкции модели. UML отвечает требованиям современной разработки программного обеспечения, в том числе таким, как крупномасштабность, параллелизм, распределенность, возможность использования образцов и удобство при командной работе.
В данной курсовой работе была разработана объектно-ориентированная модель информационной подсистемы для управления, учета, контроля и ведения ломбарда. Модель разработана с помощью программного продукта Microsoft Visual Studio 2010, с использованием языка UML.
1. Краткая характеристика предметной области
1.1 Визуальное моделирование
В последнее время наблюдается общее повышение интереса ко всем аспектам, связанным с разработкой сложных программных приложений. Для многих компаний корпоративное программное обеспечения и базы данных представляют стратегическую ценность. Существует высокая заинтересованность в разработке и верификации методов и подходов, позволяющих автоматизировать создание сложных программных информационных систем. Известно, что систематическое использование таких методов позволяет значительно улучшить качество, сократить стоимость и время поставки информационных систем. В настоящее время эти методы включают в себя:
Разработка информационной системы «Страховая компания»
... разрабатываемой информационной системы, которая позволяет в будущем приступить к созданию конкретной программной разработки, используя готовый проект информационной системы дисциплинарной области. 2. РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ «СТРАХОВАЯ ... пор, пока не получали полных, ориентированных на пользователя приложений. Microsoft Access - это функционально полная реляционная СУБД. Он предоставляет ...
компонентную технологию разработки моделей,
визуальное программирование,
использование образцов при проектировании,
визуальное представление различных аспектов проекта.
Визуальные модели широко используются в существующих технологиях управления проектированием систем, сложность, масштабы и функциональность которых постоянно возрастают. В практике эксплуатации ИС постоянно приходится решать такие задачи как: физическое перераспределение вычислений и данных, обеспечение параллелизма вычислений, репликация БД, обеспечение безопасности доступа к ИС, оптимизация балансировки нагрузки информационной системы, устойчивость к сбоям и т.п.
Построение модели корпоративной информационной системы до ее программной разработки или до начала проведения архитектурной реконструкции столь же необходимо, как наличие проектных чертежей перед строительством большого здания. Хорошие модели информационной системы позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков. Визуальные модели обеспечивают ясность представления выбранных архитектурных решений и позволяют понять разрабатываемую систему во всей ее полноте. Сложность разрабатываемых систем продолжает увеличиваться, и поэтому возрастает актуальность использования «хороших» методов моделирования информационных систем. Язык моделирования, как правило, включает в себя:
- элементы модели — фундаментальные концепции моделирования и их семантику;
- нотацию — визуальное предоставление элементов моделирования;
- принципы использования — правила применения элементов в рамках построения тех или иных типов моделей ИС.
Построение визуальных моделей позволяет решить сразу несколько типичных проблем. Во-первых, и это главное, технология визуального моделирования, позволяет работать со сложными и очень сложными системами и проектами. И не важно, преобладает ли в проекте «техническая сложность» или «динамическая сложность управления». Сложность программных систем возрастает по мере создания новых версий. И в какой-то момент наступает «эффект критической массы», когда дальнейшее развитие ИС становиться невозможным, поскольку уже никто не представляет в целом «что и почему происходит». Происходит потеря управлением проектом. Внешней причиной или толчком возникновения этого неприятного эффекта может послужить, например, увольнение ведущего программиста или системного аналитика.
Во-вторых, визуальные модели позволяют содержательно организовать общение между заказчиками и разработчиками. Шутка о том, что «заказчик что-то хочет, но точно не знает, чего именно», с завидным постоянством часто оказывается былью. А если на начальном этапе работы над проектом ИС заказчик думает, что точно знает, что хочет, то, как правило, и об этом свидетельствует богатый опыт, его требования изменяются («плывут») в ходе выполнения проекта. С одной стороны, аппетит приходит во время еды, а с другой, высокая динамика бизнеса объективно заставляет менять требования к разрабатываемой (или поддерживаемой) ИС.
Модель Бисмарка. Система социального страхования Германии
... счет налогов, она не обладает присущим таким системам недостатком, заключающимся в отсутствии стимулов к принятию профилактических мер. Модель Бевериджа. Система обязательного страхования в Великобритании После завершения ... чем у публично-правовых, которые действуют в пределах моделей Бевериджа и Бисмарка. К тому же в подобных системах необходимым является прогнозирование расходов на оплату общих ...
Визуальное моделирование не является «серебряной пулей», способной раз и навсегда решить все проблемы, однако его использование существенно облегчает достижения таких целей как:
повышение качества программного продукта,
сокращение стоимости проекта,
поставка системы в запланированные сроки.
Программное обеспечение за полвека своего существования претерпело огромные изменения, пройдя путь от программ, способных выполнять только простейшие логические и арифметические операции, до сложных систем управления предприятиями. Хотя первоначально компьютеры предназначались главным образом для выполнения сложных математических расчётов, в настоящее время доминирующим является накопление и обработка информации. Сегодня управление предприятием без компьютера просто немыслимо. Компьютеры давно и прочно вошли в такие области, как бухгалтерский учёт, управление ассортиментом и закупками.
Однако современный бизнес требует более широкого применения информационных технологий в управлении. Жизнеспособность и развитие информационных технологий объясняется тем, что современный бизнес крайне чувствителен к ошибкам в управлении. Интуиции, личного опыта руководителя и размеров капитала уже мало для того, чтобы быть первым. Для принятия любого грамотного управленческого решения в условиях неопределённости и риска необходимо постоянно держать под контролем различные аспекты финансово-хозяйственной деятельности, будь то торговля, производство или предоставление услуг. Поэтому современный подход к управлению предполагает вложение средств в информационные технологии. И чем крупнее предприятие, тем серьёзнее должны быть подобные вложения. Они являются жизненной необходимостью в жёсткой конкурентной борьбе. Одержать победу сможет лишь тот, кто лучше оснащен и наиболее эффективно организован.
С точки зрения визуального моделирования, UML можно охарактеризовать следующим образом. UML предоставляет выразительные средства для создания визуальных моделей, которые:
- единообразно понимаются всеми разработчиками, вовлеченными в проект;
- являются средством коммуникации в рамках проекта;
Унифицированный Язык Моделирования :
- не зависит от объектно-ориентированных языков программирования;
- не зависит от используемой методологии разработки проекта;
- может поддерживать любой ОО язык программирования;
— UML является открытым и обладает средствами расширения базового ядра. На UML можно содержательно описывать классы, объекты и компоненты в различных предметных областях, часто сильно отличающихся друг от друга.
1.2 Разработка модели информационной системы «Ломбард» средствами UML
Целью разработки проекта является создание информационной системы «Ломбард» для эффективной деятельности сотрудников ломбарда. Структура и принцип организации работы ломбарда имеют следующий вид:
При обращении клиента в ломбард он может являться либо залогодателем, либо покупателем. В первом случае если он ранее не являлся клиентом данного ломбарда, администратор регистрирует его, либо выбирает из списка уже существующих, оценивает заложенное имущество, определяет срок заложение имущества, процент по кредиту и вносит эти данные в залоговый билет. При возврате залогодателем кредита и выплате процента в срок ему возвращается имущество, в противном случае имущество переходит в собственность ломбарда. Во втором случае осуществляется продажа имущества.
ВКР: «ОРГАНИЗАЦИЯ ДЕЯТЕЛЬНОСТИ ЛОМБАРДОВ В РОССИИ»
... диаграмм, рисунков и др. 1 СОЦИАЛЬНО-ЭКОНОМИЧЕСКАЯ СУЩНОСТЬ ЛОМБАРДОВ 1.1 Теоретическое обоснование ломбарда как финансово-кредитной организации В современной финансово-кредитной системе ... от граждан движимое имущество, предназначенное для личного потребления; , принимаемое ломбардом, принадлежать гражданам (а не лицам); имущество, ломбардом, относиться к движимому ; имущество, принимаемое , ...
Словарь разрабатываемой информационной системы:
Залогодатель — клиент ломбарда, оставляющий свое имущество в залог исполнитель ролей в постановках театра.
Имущество — Вещи, драгоценности и т.д., ходящие в обороте ломбарда.
Сделка — Операция проведенная между клиентом ломбарда и ломбардом.
Залоговый билет — Официальный документ свидетельствующий о заключении сделки между залогодателем.
Срок заложения имущества — Промежуток времени с даты заключения договора по дату возврата средств определенного в договоре.
Процент по кредиту — Сумма денежных средств которую выставляет администратор и обязуется выплатить клиент при возврате имущества.
Разрабатываемая информационная система должна соответствовать следующим требованиям:
- В базе данных должна храниться информация о залогодателях, сделках, имуществе;
- Администратор должен иметь возможность просмотра, добавления, удаления и изменения информации;
- Администратор должен иметь возможность поиска информации по определенным критериям;
- Перед началом работы администратору необходимо пройти аутентификацию;
1.3 Вид с точки зрения прецедентов
Диаграммы прецедентов играют основную роль в моделировании поведения системы, подсистемы или класса. Каждая такая диаграмма показывает множество прецедентов, актеров и отношения между ними.
Диаграммы прецедентов применяются для моделирования вида системы с точки зрения прецедентов (или вариантов использования).
Чаще всего это предполагает моделирование контекста системы, подсистемы или класса либо моделирование требований, предъявляемых к поведению указанных элементов.
Диаграммы прецедентов имеют большое значение для визуализации, специфицирования и документирования поведения элемента. Они облегчают понимание систем, подсистем или классов, представляя взгляд извне на то, как данные элементы могут быть использованы в соответствующем контексте. Кроме того, такие диаграммы важны для тестирования исполняемых систем в процессе прямого проектирования и для понимания их внутреннего устройства при обратном проектировании.
Разрабатываемая информационная система включает следующие прецеденты:
- Поиск залогодателя;
- Поиск имущества;
- Редактирование данных;
- Просмотр отчетов;
- Аутентификация;
- Прецедент редактирование данных включает в себя прецеденты: добавление, удаление и изменение данных.
Поиск залогодателя предполагает поиск по фамилии и его номеру. Поиск имущества может быть осуществлен по номеру или по его цене.
Прецедент просмотр отчетов включает отчеты по залогодателям и отчеты по имуществу.
Для моделирования процесса выполнения операций в языке UML используются диаграммы деятельности. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние выполняется только при завершении этой операции.
Денежно-кредитная система и её роль в развитии экономики (на ...
... фирмам, правительству и частным лицам. В основе денежно-кредитной системы лежит денежная система и кредитная система. Денежная система - устройство денежного обращения в стране, сложившееся исторически, закрепл ... и функции кредита в его различных формах реализуются через кредитную систему. Традиционно кредитная система рассматривается в двух аспектах: функциональном и институциональном. С точки ...
Процесс аутентификации можно представить в виде набора последовательных действий со стороны пользователя и ответа на эти действия со стороны системы.
1.4 Вид с точки зрения проектирования
Центральное место в методологии занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов отражает, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов может служить дальнейшим развитием концептуальной модели проектируемой системы
Диаграмма классов (class diagram) — диаграмма языка UML, на которой представлена совокупность декларативных или статических элементов модели, таких как классы с атрибутами и операциями, а также связывающие их отношения.
Диаграмма классов предназначена для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. При этом диаграмма классов может содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры классификаторов, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы, т. е. графическое представление таких структурных взаимосвязей логической модели системы, которые не зависят от времени.
Класс залогодатели имеет следующие атрибуты: ФИО, номер, дата рождения, наименование документа, реквизиты документа, адрес номер телефона. Атрибут наименование документа удобно определить классом со стереотипом «enum» (enumeration — перечисление), и поместить в него список значений, которые может принимать этот атрибут (паспорт, студенческий, военный билет, свидетельство о рождении, трудовая книжка, приписное).
Классу залогодатель соответствует интерфейс поиск залогодателя, позволяющий организовать поиск по заданным критериям (фамилии или номеру).
К классу имущество относятся атрибуты номер, описание, цена и статус. Атрибут статус удобно определить классом со стереотипом «enum» (enumeration — перечисление), и поместить в него список значений, которые может принимать этот атрибут ( Заложена, На продажу).
Данный класс также реализует интерфейс поиск имущества (по номеру и по цене).
Класс сделки включает: номер, дата займа, дата возврата, сумма кредита, сумма процента.
Залогодатель может совершать неограниченное количество сделок. В таком случае в базе данных будет храниться несколько записей одного залогодателя, следовательно, определим связь между классами залогодатели и сделки как «один-ко-многим».
Класс электронная таблица содержит свойства и операции электронной таблицы для редактирования данных.
Кредитно-банковская система России
... финансово - кредитные учреждения, осуществляющие отдельные банковские операции. Таким образом, кредитная система включает банк России, банки, филиалы и представительства иностранных банков, небанковские ... их деятельностью; осуществляет валютный контроль и другие функции. Второй уровень банковской системы представлен, прежде всего, широкой сетью коммерческих банков. Обеспечивающих кредитно - ...
Для формирования отчетов введем класс — менеджер отчетов. Определим для данного класса соответствующие операции, а также добавим необходимый интерфейс: отчеты.
Добавление новой записи о залогодателе можно представить в виде диаграммы последовательности. На этой диаграмме добавляем следующие элементы: форма ввода, менеджер записей, запись о добавляемом залогодателе (в данном случае Иванове), менеджер транзакций. Добавляем необходимые сообщения: создать новую форму; открыть форму; ввести ФИО, номер, дата рождения, наименование документа, реквизиты документа, адрес, номер телефона. Далее следуют сообщения о сохранении этих данных, сообщение собрать информацию о залогодателе, и, наконец, сохранить запись в БД.
На диаграмме последовательности изображаются только те объекты, которые непосредственно участвуют во взаимодействии. Ключевым моментом для диаграмм последовательности является динамика взаимодействия объектов во времени.
В UML диаграмма последовательности имеет как бы два измерения. Первое слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия. Правее изображается другой объект, который непосредственно взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности образуют некоторый порядок, определяемый очередностью или степенью активности объектов при взаимодействии друг с другом.
Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни. Внутри прямоугольника записываются имя объекта и имя класса разделенные двоеточием. При этом вся запись подчеркивается, что является признаком объекта.
Вторым измерением диаграммы последовательности является вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. Взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения, а их порядок определяется временем возникновения. То есть, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. Масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа «раньше-позже».
Для наглядности диаграмму последовательности можно дополнить диаграммой кооперации.
Главная особенность диаграммы кооперации заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии.
Прежде всего, на диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Далее, как и на диаграмме классов, указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые играют объекты в данной ассоциации. Дополнительно могут быть изображены динамические связи — потоки сообщений. Они представляются также в виде соединительных линий между объектами, над которыми располагается стрелка с указанием направления, имени сообщения и порядкового номера в общей последовательности инициализации сообщений.
Денежно-кредитная система США
... Потребительский кредит - в США - ежемесячный индикатор потребительского спроса, отражающий объем использования американцами системы кредита через кредитные карточки, личное заимствование и покупки в рассрочку (Рис.3 ). ... Рисунок 3. Индикатор потребительского спроса Рассмотрим данные за 10 лет. Из диаграммы ...
В отличие от диаграммы последовательности, на диаграмме кооперации изображаются только отношения между объектами, играющими определенные роли во взаимодействии. На этой диаграмме не указывается время в виде отдельного измерения. Поэтому последовательность взаимодействий и параллельных потоков может быть определена с помощью порядковых номеров. Следовательно, если необходимо явно специфицировать взаимосвязи между объектами в реальном времени, лучше это делать на диаграмме последовательности.
1.5 Виды взаимодействий
Между актерами и вариантами использования могут быть различные виды взаимодействия. Основные виды взаимодействия следующие:
Простая ассоциация — отражается линией между актером и вариантом использования (без стрелки).
Отражает связь актера и варианта использования. На рисунке между актером администратор и вариантом использования просматривать заказ.
Направленная ассоциация — то же что и простая ассоциация, но показывает, что вариант использования инициализируется актером. Обозначается стрелкой.
Наследование — показывает, что потомок наследует атрибуты и поведение своего прямого предка. Может применяться как для актеров, так для вариантов использования.
Расширение (extend) — показывает, что вариант использования расширяет базовую последовательность действий и вставляет собственную последовательность. При этом в отличие от типа отношений «включение» расширенная последовательность может осуществляться в зависимости от определенных условий.
Включение — показывает, что вариант использования включается в базовую последовательность и выполняется всегда .
2. Проектирование системы ломбард на MS Visual Studio
2.1 Создание диаграммы вариантов использования
Основная цель создания любой программной системы — создание такого программного продукта, который помогает пользователю выполнять свои повседневные задачи. Для создания таких программ первым делом определяются требования, которым должна удовлетворять система. Однако если дать пользователям написать эти требования на бумаге, то часто можно получить список функций, по которому трудно судить будет ли будущая система выполнять свое назначение и сможет ли она облегчить пользователю выполнение его работы вообще. Непонятно какие из выполняемых функций более важны и для кого.
Для того, чтобы более точно понять как должна работать система, все чаще используется описание функциональности системы через варианты использования. Варианты использования это — описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем. Варианты использования отражают функциональность системы с точки зрения получения значимого результата для пользователя, поэтому они точнее позволяют ранжировать функции по значимости получаемого результата.
Рисунок 1 Диаграмма вариантов использования
На данной диаграмме отражены отношения, существующие между актерами и прецедентами. Основная задача — представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
Банковская система современной России
... Глава 1. Теоретические основы функционирования Банка России 1.1 Сущность банковской системы Банковская система – совокупность различных видов национальных банков и кредитных учреждений, действующих ... В странах с развитой рыночной экономикой сложились двухуровневые банковские системы. Верхний уровень системы представлен центральным (эмиссионным) банком. На нижнем уровне действуют коммерческие ...
На рисунке 1 приведена разработанная диаграмма вариантов использования. Основными действующими лицами (актерами) являются кассир, пассажир и администратор.
Клиент — человек, который хочет воспользоваться услугами ломбарда;
- Кассир организации, который обслуживает клиентов при получении кредита;
- Товаровед-оценщик — сотрудник организации, занимающийся оценкой товара.
2.2 Создание диаграммы последовательности
Диаграмма последовательности — диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.
На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно — слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни. Внутри прямоугольника записываются имя объекта и имя класса, разделенные двоеточием. При этом вся запись подчеркивается, что является признаком объекта, который, как известно, представляет собой экземпляр класса.
Таким образом, диаграмма последовательностей всегда создается в привязке к варианту использования. Каждый вариант использования может содержать несколько диаграмм последовательностей, на тот случай, если они описывают несколько альтернативных вариантов развития событий.
Диаграмма последовательностей, так же, как и вариант использования, может быть реализована как в терминах бизнес-объектов, так и в терминах физических сущностей, таких как компоненты или классы.
На диаграмме последовательности изображено упорядоченное во времени взаимодействие объектов.
Рисунок 2 Диаграмма последовательности ломбарда
Последовательность действий выглядит следующим образом:
Клиент приходит в ломбард и изучает условия ломбарда.
После обращается к оценщику для того, чтобы тот оценил предоставленный товар.
После оценки товара, если клиент согласен с суммой кредита за предоставленный товар, оценщик заносит в базу данных всю информацию о клиенте.
Отправляет кассиру запрос о выдаче кредита с указанной суммой.
При этом кассир вносит в базу данных о сумме.
После клиент получает свой кредит.
Товаровед оценщик отправляет товар на хранение.
2.3 Создание диаграммы состояний
State Machine (автомат) в языке UML представляет собой некоторый формализм для моделирования поведения элементов модели и системы в целом. В метамодели UML автомат является пакетом, в котором определено множество понятий, необходимых для представления поведения моделируемой сущности в виде дискретного пространства с конечным числом состояний и переходов. С другой стороны, автомат описывает поведение отдельного объекта в форме последовательности состояний, которые охватывают все этапы его жизненного цикла, начиная от создания объекта и заканчивая его уничтожением. Каждая диаграмма состояний представляет некоторый автомат.
Шаг 11.1. Определяем эффективность инвестиций в проект: производим ...
... пресловутые риски изменения ставки дисконтирования) можно наблюдать, если нажать кнопку "Построить диаграмму зависимости NPV от ставки дисконтирования ". Если чистая приведенная стоимость проекта положительна, ... Конструктором значение IRR вы сможете проверить графически, нажав на кнопку " Построить диаграмму зависимости NPV от ставки дисконтирования ", а также подставив вычисленный показатель вместо ...
Основными понятиями, входящими в формализм автомата, являются со стояние и переход. Главное различие между ними заключается в том, что длительность нахождения системы в отдельном состоянии существенно превышает время, которое затрачивается на переход из одного состояния в другое. Предполагается, что в пределе время перехода из одного состояния в другое равно нулю (если дополнительно ничего не сказано).
Другими словами, переход объекта из состояния в состояние происходит мгновенно.
Рисунок 3 Диаграмма состояний при получении кредита
На данной диаграмме представлена модель жизненного цикла состояния «Машина исправная». Модель состоит из состояний. Состояния связаны между собой переходами. Причем длительность нахождения системы в определенном состоянии значительно превышает время, которое затрачивается на переход из одного состояния в другое.
Рисунок 4 Диаграмма состояний при возврате кредита
2.4 Диаграмма классов
Диаграмма классов — статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.
Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
- концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
- точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;
- точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
Каждый класс имеет свое название и свои атрибуты и операции, которые впоследствии будут реализованы в программном коде. На рисунке видны связи между классами. Данные связи были выявлены после просмотра и анализа диаграмм последовательности, а также на данной диаграмме добавлены множественности. На основе диаграммы классов, будет построен фрагмент кода программы, будут проанализированы и выявлены алгоритмы наследия классов. Эти классы непосредственно будут фигурировать в программном коде.
Для более наглядного и понятного взаимодействия классов между собой, нужно объединить классы в пакеты. Таким образом, мы сгруппируем все наши классы в модули. И при кодогенерации каждый пакет выведется в отдельный модуль, согласно той группировке, которую мы произвели. Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью нашей системы.
Рисунок 5 Диаграмма классов
2.5 Диаграмма развертывания
Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения. При этом представляются только компоненты экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются.
Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Эта диаграмма, по сути, завершает процесс ООАП для конкретной программной системы и ее разработка, как правило, является последним этапом спецификации модели.
Узел представляет собой некоторый физически существующий элемент системы, обладающий некоторым вычислительным ресурсом. В качестве вычислительного ресурса узла может рассматриваться наличие по меньшей мере некоторого объема электронной или магнитооптической памяти и/или процессора.
Кроме собственно изображений узлов на диаграмме развертывания указываются отношения между ними. В качестве отношений выступают физические соединения между узлами и зависимости между узлами и компонентами, изображения которых тоже могут присутствовать на диаграммах развертывания.
Соединения являются разновидностью ассоциации и изображаются отрезками линий без стрелок. Наличие такой линии указывает на необходимость организации физического канала для обмена информацией между соответствующими узлами.
На нашей диаграмме развертывания указана зависимость компонента реализации сервера приложения от рабочих станций.
2.6 Генерация кода
После создания компонентов и отображения классов, следующим шагом является установка свойств генерации программного кода для классов, компонентов, операций и других элементов модели. На основании созданных моделей компонентов, представленных в проекте, была произведена генерация программного кода на языке Visual C#.
Рисунок 6 Генерация кода
Заключение
В результате выполнения курсового проекта была разработана объектно-ориентированная модель информационной подсистемы для ломбарда. Работа написана с помощью языка UML, с использованием среды разработки Microsoft Visual Studio 2010. Общий объем разработанной подсистемы и сгенерированных файлов С# составляет 2,53 Мбайт.
В результате работы созданы следующие диаграммы:
- прецедентов;
- последовательности;
- сотрудничества;
- классов;
- состояния для классов;
- компонентов;
- Данная информационная подсистема построена на технологии «клиент-сервер».
Модель, разработанная в данном курсовом проекте, позволяет добавлять новых клиентов в базу данных, изменять ранее веденную информацию.
Дальнейшим развитием работы над созданной подсистемой будет наполнение ее программным кодом.
Список исполдьзованной литературы
[Электронный ресурс]//URL: https://ddmfo.ru/kursovaya/s-dlya-lombarda/
1. Леффингуал, Дин, Ундри, Дон. Принципы работы с требованиями к ПО. Унифицированный подход. М., 2002г.
2. Сэм Канер и др. Тестирования программного обеспечения. Киев, 2000 г.
3. Сербин В.В. Реализация адаптивных обучающих систем. — Алматы: РУМЦДО, 2005, 110 с.
4. Жуков Д.О. Математические модели управления знаниями в информационных обучающих системах. — Москва: МГУ, 2006.
5. Жоголев Е.А.. Введение в технологию программирования (конспект лекций).
— М.: «ДИАЛОГ-МГУ», 2005.
6. В.Турский. Методология программирования. — Москва.: Мир, 1981.
диаграмма проектирование visual
Приложение А
Листинги кода приложения, сгенерированные для разработанной информационной подсистемы:
- using System;
- using System.Collections.Generic;
- using System.ComponentModel;
- using System.Data;
- using System.Drawing;
- using System.Linq;
- using System.Text;
- using System.Windows.Forms;
namespace WindowsFormsApplication1
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void ломбардBindingNavigatorSaveItem_Click(object sender, EventArgs e)
{
this.Validate();
- this.ломбардBindingSource.EndEdit();
- this.tableAdapterManager.UpdateAll(this.ломбардDataSet);
}
private void Form1_Load(object sender, EventArgs e)
{
// TODO: данная строка кода позволяет загрузить данные в таблицу «ломбардDataSet.Ломбард». При необходимости она может быть перемещена или удалена.
this.ломбардTableAdapter.Fill(this.ломбардDataSet.Ломбард);
}
private void button1_Click(object sender, EventArgs e)
{
Close();
}
}
}
