Моделирование предметной области «Учёт продаж» с помощью UML

Содержание:

ВВЕДЕНИЕ

Различные сферы человеческой деятельности развиваются с применением компьютерной техники и создания различных информационных систем.

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

Чтобы успешно реализовать какой-либо объект проектирования информационной системы, необходимо адекватно описать, полно и непротиворечиво описать функциональные и информационные модели информационной системы.

В современное время число автомобилей растёт в геометрической прогрессии, следовательно, растет на них и спрос. Автомобиль - самое популярное средство передвижения. Существует огромное количество автосалонов по продаже автомобилей. При продаже автомобиля необходимо учитывать, что клиент хочет “немедленно” получить автомобиль, т.е. без ожидания. Если этот факт не учитывать, популярность автосалона резко упадет. А ведь главное для автосалона - это клиент, нет клиента, нет и автосалона. Чтобы избежать такую ситуацию, нужно внедрять быструю и качественную информационную систему. Многие фирмы имеют информационные системы, оставляющие желать лучшего. А некоторые и вовсе её не имеют. Чтобы работа автосалона была прибыльной, нужно внедрять только качественные программные продукты, и набирать соответствующий персонал. Бесспорно, в РФ отечественный автомобиль занимает более половины рынка всех автомобилей, значит, на него существует хороший спрос.

Объект исследования: Автосалон по продаже автомобилей.

Предмет исследования: Обеспечение продаж автосалона.

Методы исследования в данной курсовой работе:

Анализ. Он представляет собой процесс разложения объектной модели на составные части (его свойства, признаки и т.д.). 

- Моделирование – это метод, при котором исследуется не сам объект, а его заменитель – модель. Полученные при изучении свойств модели результаты переносят и на сам объект исследования Автосалон по продаже автомобилей.

Работа выполнена на материалах Уэнди и Майкла Боггс [1], Буча Г., Рамбо Д., Джекобсона А. [2], Грехема И. [3], Федотовой Д., Семенова Ю., Чижик К. [5], Маклаковa С.В. [6], Марка Д.А., МакГоуэн К. [7] и других.

При выполнении работы были использованы следующие программно-аппаратные средства: Rational Rose - CASE-средство фирмы Rational Software Corporation.

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

Задачи исследования:

• Собрать требования и их проанализировать;
• Построить концептуальную модель программного обеспечения;
• Провести уточнение требований, сформулированных на предыдущем этапе. Построить аналитическую модель, позволяющую судить о внутренней структуре системы;
• Провести оформление технического проекта системы;
• Выбрать методологию проектирования ИС;
• Построить объектно-ориентированные модели системы.

В теоретической части курсовой работы описана предметная область, разработка объектно-ориентированной модели системы средствами Rational Rose.

В практической части будут решены следующие вопросы:

1. построена диаграмма прецедентов (вариантов использования) для выбранной информационной системы;
2. выполнена реализация вариантов использования в терминах взаимодействующих объектов и представляющую собой набор диаграмм:

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

ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

Структурный подход к проектированию информационной системы

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

Все наиболее распространенные методологии структурного подхода [9,11,12,13] базируются на ряде общих принципов [3]. В качестве двух базовых принципов используются следующие:

• принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
• принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

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

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

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

• SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
• DFD (Data Flow Diagrams) диаграммы потоков данных;
• ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

Объектно-ориентированный подход к проектированию программного обеспечения

В 1990 х годах словосочетание “объектно-ориентированный” в контексте информационных технологий стало синонимом слов “современность”, “высокое качество”, “ценность”.

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

ООП основан на представлении предметной области задачи в виде множества моделей для независимой от языка разработки программной системы на основе ее прагматики.

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

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

Объектно-ориентированный подход помогает справиться с такими сложными проблемами, как • уменьшение сложности программного обеспечения; • повышение надежности программного обеспечения; • обеспечение возможности модификации отдельных компонентов программного обеспечения без изменения остальных его компонентов. • обеспечение возможности повторного использования отдельных компонентов программного обеспечения. Более детально преимущества и недостатки объектно-ориентированного программирования будут рассмотрены в конце главы, так как для их понимания необходимо знание основных понятий и положений ООП. Систематическое применение объектно-ориентированного подхода позволяет разрабатывать хорошо структурированные, надежные в эксплуатации, достаточно просто модифицируемые программные системы. Этим объясняется интерес программистов к объектно-ориентированному подходу и объектно-ориентированным языкам программирования. ООП является одним из наиболее интенсивно развивающихся направлений теоретического и прикладного программирования.

Особенности языка моделирования UML

Rational Rose – программный продукт, визуализирующий объектно-ориентированное моделирование систем на основе классов и их взаимодействия, а если еще более упрощенно, это визуальный редактор, моделирующий информационные системы любой сложности с использованием диаграмм языка UML (Unified Modeling Language). Язык предназначен, чтобы описывать модели, существует несколько специальных редакторов диаграмм, работающих с этим языком, одним из которых является Rational Rose (рис.1).

Рисунок 1 - Программный продукт Rational Rose

Всем разработчикам, работающим над проектом, понятны созданные на UML диаграммы, и, что немаловажно, не только во время разработки, но и спустя длительное время. Язык UML открыт и имеет средства расширения базового ядра. На языке UML можно содержательно описывать такие элементы, как класс, объект и компонент различных предметных областей, которые могут сильно отличаться друг от друга. Но программный продукт Rational Rose поддерживает не только язык UML, но и другие нотации создания диаграмм - ОМТ или Booch.

На сегодняшний день среди других CASE-средств Rational Rose является лидирующим. Не только проектировщики систем, но и программисты-разработчики интересуются этим пакетом, позволяющим создавать сложные программные системы от замысла до создания исходного кода. Главным отличием Rational Rose от других CASE-средств является то, что этим продуктом пользуются не только проектировщики систем, но и разработчики программного кодаНовый специалист, приходящий в проект, без труда ознакамливается с диаграммами Rational Rose и входит в курс дела.

И самое главное, Rational Rose не создает готовый исходный код. Пакет может создать основу для информационной системы, заготовку классов вместе с их взаимодействием, а наполнением методов содержанием будет все-таки программист. Испраляя что-либо даже в структуре классов, программист видит сразу визуальное отражение этих изменений в Rational Rose.

Преимуществами применения Rational Rose заключаются в том, что программный продукт может:

• сократить цикл разработки приложения «заказчик – программист – заказчик». Теперь заказчик может не ждать первой альфаверсии, чтобы убедиться, что все делается совсем не так, как он ожидал;
• увеличить продуктивность работы программистов;
• уменьшить ручное кодирование – меньше ошибок, а как следствие – меньше отладки, а значит – больше продуктивность;
• улучшить потребительские качества создаваемых программ, ориентируясь на пользователей и бизнес;
• вести большой проект или группу проектов;
• повторно использовать уже созданное программное обеспечение за счет упора на разбор их архитектуры и компонентов;
• язык UML - универсальный «мостик» между разработчиками из разных отделов.

UML – это диаграммы, которые позволяющие создавать модели сложных информационных систем. [9]

Диаграммы языка UML

В UML используются следующие виды диаграмм:

• Диаграмма использования

• Диаграмма классов

• Диаграмма объектов

• Диаграмма состояний

• Диаграмма деятельности

• Диаграмма последовательности

• Диаграмма кооперации

• Диаграмма компонентов

• Диаграмма размещения

Канонические диаграммы отнюдь не образуют полного ортогонального набора: они пересекаются как по включенным в них средствам, так и по области применения. Более того, некоторые из них являются частными случаями других, есть просто семантические эквивалентные пары, можно привести примеры допустимых диаграмм, для которых затруднительно указать однозначно, к какому именно из канонических типов диаграмма относится.

Сказанное можно проиллюстрировать условной классификацией диаграмм, приведенной на рис. 2.

Рисунок 2 - Иерархия типов диаграмм

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

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

• обобщение между действующими лицами;

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

• зависимости (различных типов) между вариантами использования.

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

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

Рисунок 3 - Нотация диаграммы использования

Диаграмма классов — основной способ описания структуры системы. Это не удивительно, поскольку UML сильно объектно-ориентированный язык, и классы являются основным (если не единственным) "строительным материалом" системы. На диаграмме классов применяются один основной тип сущностей: классы (включая многочисленные частные случаи классов: интерфейсы, типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений:

• ассоциация между классами (с множеством дополнительных подробностей);

• обобщение между классами;

• зависимости (различных типов) между классами и интерфейсами.

Основные элементы нотации, применяемые на диаграмме классов, показаны на рис. 4.

Рисунок 4 - Нотация диаграммы классов

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

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

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

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

Диаграмма последовательности — это способ описать поведение системы "на примерах". Фактически, диаграмма последовательности — это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является посылка сообщений взаимодействующими объектами. Именно последовательность посылки сообщений отображается на данной диаграмме, отсюда и название.

Диаграмма кооперации, которая в UML 2 переименована в диаграмму коммуникации, семантически эквивалентна диаграмме последовательности. Фактически, это такое же описание последовательности обмена сообщениями взаимодействующих объектов, только выраженное другими графическими средствами. Более того, большинство инструментов умеет автоматически преобразовывать диаграммы последовательности в диаграммы кооперации и обратно. Такое преобразование является взаимно-однозначным.

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

• реализации между компонентами и интерфейсами (компонент реализует

интерфейс);

• зависимости между компонентами и интерфейсами (компонент использует интерфейс);

• зависимости между объектами и компонентами (объект входит в компонент).

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

Достоинства и недостатки объектно-ориентированного подхода

Рассмотрим достоинства объектно-ориентированного программирования.

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

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

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

4. ООП дает возможность создавать расширяемые системы. Компоненты могут быть добавлены на этапе исполнения программы.

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

6. Изменение поведения во время исполнения. На этапе исполнения один объект может быть заменен другим, что позволяет легко, без изменения кода, адаптировать алгоритм в зависимости от того, какой используется объект.

7. Реализация работы с наследниками. Алгоритмы можно обобщить настолько, что они уже смогут работать более чем с одним видом объектов.

8. Создание «каркаса». Независимые от приложения части предметной области могут быть реализованы в виде набора универсальных классов, или каркаса (framework).

9. Сокращается время на разработку.

Компоненты многоразового использования обычно содержат гораздо меньше ошибок, чем вновь разработанные.

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

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

Одако ООП имеет и недостатки.

1. Документирование классов — ресурсоёмкая задача.

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

2. Методы, как правило, короче процедур, зато их намного больше. В коротких методах легче разобраться, но они неудобны тем, что код для обработки сообщения иногда «размазан» по многим маленьким методам.

3. Злоупотребление инкапсуляцией данных. Чем больше логики и данных скрыто в недрах класса, тем сложнее его расширять.

4. Неэффективность на этапе выполнения, в т.ч. инкапсуляция данных.

5. Неэффективность в смысле распределения памяти.

6. Излишняя универсальность.

ПРАКТИЧЕСКАЯ ЧАСТЬ

Спецификация требований к «Учёт продаж»

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

При выборе состава и структуры предметной области возможны два подхода: функциональный и предметный.

Функциональный подход реализует принцип движения «от задач» и применяется, когда определен комплекс задач, для обслуживания которых создается информационная система. В этом случае можно выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.

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

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

В данной курсовой работе предметной областью является работа автосалона.

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

Диаграмма вариантов использования

Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors)

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

Диаграмма вариантов использования (рис.5) показывает структуру и движение информационных потоков между актерами автосалона: новыми покупателями, постоянными покупателями, оптовыми покупателями и сотрудниками.

Рисунок 5 - Диаграмма вариантов использования автосалона

Данная диаграмма представляет собой совокупность актеров, вариантов использования и связей между ними. Каждый актер ­– это некая отдельная роль относительно конкретного варианта использования. Актерами выступают конкретные сотрудники, а также действующие клиенты. На диаграмме отображается поведение системы, то есть что система будет делать.

Главный актером является Сотрудник, так как он взаимодействует со всеми покупателями, напрямую или через посредников.

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

Диаграмма взаимодействия

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Диаграмма Классов должна выглядеть как на рисунке 6.

Рисунок 6 - Диаграмма классов

Диаграмма последовательности действий

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

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

Рисунок 7 - Диаграмма последовательности действий Ввод заказа

Диаграмма последовательности действий Ввод заказа (рис.8 обеспечивает возможность добавления новых заказов. Изменения старых, выполнения заказов, проверки и возобновления инвентарных описей. При получении заказа система также должна послать сообщение расчетной системе, которая выписывает счет. Если требуемого автомобиля нет в автосалоне, заказ должен быть отклонен. Диаграмма наглядно и визуально просто описывает последовательность событий в алгоритме.

На диаграмме последовательности неявно присутствует ось времени, что позволяет визуализировать временные отношения между передаваемыми сообщениями.

Рисунок 8 - Диаграмма последовательности действий Ввод заказа

Диаграмма сотрудничества

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

По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

Диаграмма сотрудничества Ввод заказа (рис.9) моделирует последовательность действий при оформлении заказа сотрудником магазина.

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

Рисунок 9 - Диаграмма сотрудничества Подача заявления

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

Логическая модель информационной системы

Модель «сущность-связь» или ER-модель опубликована американским исследователем в области баз данных Питером Ченом в1976 году. С тех пор она расширялась и модифицировалась как самим Ченом, так и многими другими исследователями. В различных вариантах она вошла в состав многих CASE-средств поддержки проектирования информационных систем.

Базовыми понятиями ER-модели являются сущность, атрибут, идентификатор и связь.

Сущность (entity) — это некоторый объект, выделяемый (идентифицируемый) пользователем в предметной области. Нечто, зачем пользователь хотел бы наблюдать и сохранять результаты наблюдений(данные).

ER-диаграмма базы данных, приведена на рисунке 10.

Диаграмма выполнена в нотациях IDEF1X.

Рисунок 10 - ER-диаграмма БД Автосалон

Диаграмма FA-уровня должна содержать все, что содержит диаграмма КВ-уровня и, кроме того, все неключевые атрибуты.

Диаграмма выполнена в нотациях IDEF1X.

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

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

Все сущности на FA-диаграмме удовлетворяют по требованиям НФБК^[1]. (Определение НФБК. Отношение находится в НФБК, если и только если каждый его детерминант является возможным ключом^[2].)

Диаграммы FA-уровня модели, выполненные в нотациях стандарта IDEF1X, представлена на рисунке 11.

Рисунок 11 - FA-уровень модели данных

Глоссарий сущностей представлен в таблице 1.

Таблица 1. Глоссарий сущностей

Сущность	Описание
Автомобили	Список автомобилей
Клиенты	Список клиентов
Кузова	Описание кузовов
Менеджеры	Список менеджеров
Партия	Список партий
Поставщики	Список поставщиков
Продажа	Список продаж
Сборка	Описание сборки

Физическая модель информационной системы

Создана схема в MS Access 2010.

Рисунок 12 - Схема БД Автосалон в MS Access 2010

Свойства столбцов таблицы «Автомобили» представлены в таблице 5:

Таблица 5. Свойства столбцов таблицы Автомобили

Наименование поля	Тип данных	Ключевое поле	Размер поля	Примечание
kod avto	счетчик	Да	Длинное целое	Подпись: код автомобиля.
kod post	числовой	Нет	Длинное целое	Подпись: код поставщика; обязательное; подстановка из таблицы «поставщики».
tip sb	числовой	Нет	Длинное целое	Подпись: тип сборки; обязательное; подстановка из таблицы «сборка».
tip kuz	Числовой	Нет	Длинное целое	Подпись: тип кузова; обязательное; подстановка из таблицы «кузова».
marka	текстовый	Нет	15	Подпись: марка; обязательное; маска ввода: ????????.
model	текстовый	Нет	15	Подпись: модель; обязательное.
kol	числовой	Нет	Целое	Подпись: количество; обязательное; условие на значение: >=0; сообщение об ошибке: количество не может быть отрицательным.
nal	логический	Нет	Да/нет	Подпись: наличие.

Свойства столбцов таблицы «Клиенты» представлены в таблице 6:

Таблица 6. Свойства столбцов таблицы Клиенты

Наименование поля	Тип данных	Ключевое поле	Размер поля	Примечание
Kod kli	Счетчик	Да	Длинное целое	Подпись: код клиента;
Fio	Текстовый	Нет	255	Подпись: фамилия, имя, отчество клиента; обязательное; маска ввода: ?????.
City	Текстовый	Нет	15	Подпись: город; обязательное; маска ввода:??????.
Address.	Текстовый	Нет	30	Подпись: адрес; обязательное.
Tel	Текстовый	Нет	16	Подпись: телефон; обязательное; маска ввода: \(#\-####\)##\-##\-##.

Свойства столбцов таблицы «Кузова» представлены в таблице 7:

Таблица 7. Свойства столбцов таблицы Кузова

Наименование товара	Тип данных	Ключевое поле	Размер поля	Примечание.
Kod kuz	Счетчик	Да	Длинное целое	Подпись: код кузова.
Tip kuz	Текстовый	Нет	15	Подпись: тип кузова; обязательное.

Свойства столбцов таблицы «Менеджеры» представлены в таблице 8:

Таблица 8. Свойства столбцов таблицы Менеджеры

Наименование поля.	Тип данных.	Ключевое поле	Размер поля.	Примечание.
Kod men	Счетчик	Да	Длинное целое	Подпись: код менеджера.
Fio	Текстовый	Нет	25	Подпись: фамилия, имя, отчество менеджера; обязательное; маска ввода: ???????.
Data	Дата/ время	Нет	Краткий формат даты.	Подпись: дата принятия менеджера на работу; обязательное.
Oklad	Денежный	Нет	# ##0,0	Подпись: должностной оклад; обязательное;
Adress	Текстовый	Нет	30	Подпись: адрес; обязательное.

Свойства столбцов таблицы «Партия» представлены в таблице 9:

Таблица 9. Свойства столбцов таблицы Партия

Наименование поля.	Тип данных.	Ключевое поле	Размер поля	Примечание.
Kod part	Счетчик	Да	Длинное целое	Подпись: код партии;
Kod post	Числовой	Нет	Длинное целое	Подпись: код поставщика; обязательное;
		Нет		Подстановка из таблицы «поставщики».
Tip sb	Числовой	Нет	Длинное целое	Подпись: тип сборки; обязательное; подстановка из таблицы « сборка».
Tip kuz	Числовой	Нет	Длинное целое	Подпись: тип кузова; обязательное; подстановка из таблицы « кузова».
Marka	Текстовый	Нет	255	Подпись: марка; обязательное; подстановка из таблицы « автомобили».
Model	Числовой	Нет	Длинное целое	Подпись: модель; обязательное; подстановка из таблицы « автомобили».
Kol	Числовой	Нет	Целое	Подпись: количество; обязательное.
Cena	Денежный	Нет	# ##0,0	Подпись: цена партии; обязательное.

Свойства столбцов таблицы «Поставщики» представлены в таблице 10:

Таблица 10. Свойства столбцов таблицы Поставщики

Наименование поля.	Тип данных.	Ключевое поле	Размер поля.	Примечание.
Kod post	Счетчик	Да	Длинное целое	Подпись: код поставщика.
Firma	Текстовый	Нет	25	Подпись: наименование фирма; обязательное.
City	Текстовый	Нет	15	Подпись: город; обязательное; маска ввода:???????.
Address	Текстовый	Нет	30	Подпись: адрес;
Tel	Текстовый	Нет	16	Подпись: телефон фирмы;

Свойства столбцов таблицы «Продажа» представлены в таблице 11

Таблица 11. Свойства столбцов таблицы Продажа

Наименование поля.	Тип данных.	Ключевое поле	Размер поля.	Примечание.
Kod pr.	Счетчик.	Да	длинное целое.	подпись: код продажи.
Kod kli.	Числовой.	Нет	Длинное целое.	Подпись: код клиента; обязательное; подстановка из таблицы « клиенты».
Kod men	Числовой	Нет	Длинное целое	Подпись: код менеджера; обязательное.
Kod part	Числовой	Нет	Длинное целое	Подпись: код партии; обязательное; подстановка из таблицы « партия».
Kod avto	Числовой	Нет	Длинное целое	Подпись автомобиль; обязательное; подстановка из таблицы « автомобили».
Tip sb	Числовой	Нет	Длинное целое	Подпись: сборка; обязательное; подстановка из таблицы «сборка».
Data	Дата/время	Нет	Краткий формат времени	Подпись: дата оформления; обязательное; маска ввода: ##.##.####.
Summa	Денежный	Нет		Подпись: сумма; обязательное.
Otmetka	Логический	Нет	Да/нет	Подпись: отметка о выплате.

Свойства столбцов таблицы «Сборка» представлены в таблице 12:

Таблица 12. Свойства столбцов таблицы Сборка

Наименование поля.	тип данных	Ключевое поле	Размер поля	Примечание.
Kod sb	Счетчик	Да	Длинное целое	Подпись: код сборки.
Tip sb	Текстовый	Нет	10	Подпись: тип сборки; обязательное.
Opisanie	Текстовый	Нет	255	Подпись: описание; обязательное.

Основные элементы главного окна показаны на рисунке 13.

Рисунок 13 - Окно БД Access 2010

Заключение

В результате проектирования была разработана информационная система автосалона. В качестве среды разработки были приняты CASE-средства для проектирования и документирования баз данных Rational Rose.

После изучения универсального языка моделирования UML и принципов использования среды Rational Rose, была построена объектно-ориентированная модель информационной системы, которая дала развернутое представление о системе.

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

• изучены структура автосалона и управление оформлением заказа, основная и поддерживающая деятельности;
• исследованы методы определения экономической эффективности и разработок аппаратных и программных средств;
• построена объектно-ориентированная модель ИС;
• произведен выбор методологии проектирования ИС;

При написании курсовой работы были применены и закреплены теоретические знания, полученные во время обучения, а также приобретен опыт работы и освоены новые знания.

В процессе проектирования был изучен теоретический материал, на основе которого разработана информационной системы «Учёт продаж». Был проведен анализ сред разработки автоматизированных систем.

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

Данный курсовой проект может быть использован при разработке (программировании) информационной системы «Учёт продаж».

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Боггс У., Боггс М. UML и Rational Rose. – М.: Лори, 2000 – 582 с.
2. Буч Г., Рамбо Д., Джекобсон А., Язык UML. Руководство пользователя: Пер. с англ. – М.: ДМК, 2000 - 432с.
3. Грехем И. Объектно-ориентированные методы. Принципы и практика – М.: "Вильямс", 2004 – 880 с.
4. Федотова Д., Семенов Ю., Чижик К., «CASE-технологии. Практикум», 2005 г – 129 с.
5. Маклаков С.В., BPwin и ERwin: CASE-средства для разработки инофрмационных систем, 2002
6. Марка Д.А., МакГоуэн К., Методология структурного анализа и проек-тирования. – М.: «Мир», 1998 – 128 с.
7. Скодорова Л.К., Константинова Ю.С., Проектирование информационных систем, 2011 – 104 с.
8. Трофимов С.А., CASE-технологии: Практическая работа в Rational Rose. – 2-е изд. – М.: Бином-Пресс, 2002 – 288 с.
9. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп. – [Текст] / А.М. Ведеров. – М.: Финансы и статистика, 2006. – 544 с.
10. Максаков С.А. Достоинства и недостатки ООП: [Электронный документ]. – Режим доступа: http://www.maksakov-sa.ru/TehProgram/ObOrientProgr/DosNedOOP/index.html – Загл. с экрана.
11. Нотация и семантика языка UML: [Электронный документ]. – Режим доступа: http://www.intuit.ru/studies/courses/32/32/lecture/1000 – Загл. с экрана.
12. Объектно-ориентированный подход в программировании: [Электронный документ]. – Режим доступа: http://www.object.newmail.ru/obj1.html – Загл. с экрана.
13. Объектно-ориентированный подход к проектированию программного обеспечения: [Электронный документ]. – Режим доступа: http://www.scriru.com/14/27/75972817962.php – Загл. с экрана.
14. Рябышева И.В. Unified Modeling Language – Унифицированный Язык Моделирования: [Электронный документ]. – Режим доступа: http://www.ict.nsc.ru/ws/YM2004/8666/index.htm – Загл. с экрана.
15. UML: [Электронный документ]. – Режим доступа: https://ru.wikipedia.org/wiki/UML – Загл. с экрана.
16. Unified Modeling Language – Унифицированный Язык Моделирования: [Электронный документ]. – Режим доступа: http://2programmer.ru/uml – Загл. с экрана.
17. Буч Г., Рамбо, Д., Джекобсон А., Язык UML Руководство пользователя: [Электронный документ]. – Режим доступа: http://dit.isuct.ru/ivt/books/CASE/case11/content.htm – Загл. с экрана.

1. Нормальная форма Бойса-Кодда (англ. Boyce-Codd normal form; сокращённо BCNF) — одна из возможных нормальных форм отношения в реляционной модели данных. ↑

2. Сибилев В.Д. Проектирование баз данных стр. 97 ↑