Размещено на http://allbest.ru

Введение

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

Один из путей решения задачи эффективной жизнедеятельности в рамках безгранично сложного окружающего нас мира - это создание упрощенных моделей, их анализ и прогнозирование. В данном курсовом проекте мы обратимся к вопросу построению и анализу определенной информационной системы. В качестве предметной области мы рассмотрим «Гостиничный комплекс». Первой задачей данной работы является построение соответствующих диаграмм и схем. Этот анализ будет производится с помощью специализированного программного обеспечения. IBM Rational Rose - программный пакет для создания диаграмм нотации UML (англ. Unified Modeling Language -- унифицированный язык моделирования), мощный инструмент построения и анализа различных диаграмм и средств с полным набором графических средств и инструментов.

1. Цель разработки

Целью данной курсовой работы является проектирование информационной системы «Гостиничный комплекс» с помощью программного пакета «Rational Rose» и языка UML, для облегчения понимания системы работы Гостиницы, взаимодействия всех его составляющих, как по отдельности, так и в целом, а также последующего использования для создания действующей системы.

1.1 Описание основных функций информационной системы

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

1) Получение лицензии;

2) Сотрудничество с поставщиками:

- Поиск;

- Составление договоров;

- Формирование заказов;

- Получение заказов;

- Перечисление средств на банковский счет;

3) Сотрудничество с магазином специализированной фирменной одежды:

- Перечисление средств магазину;

- Получение фирменной одежды;

4) Прием на работу администраторов:

- Проверка документов;

- Составление договоров;

- Назначение в гостиницу;

- Работа администраторов в гостиницах;

- Выдача заработной платы;

5) Составление отчетности по гостинице:

- Обработка проделанной работы;

- Составление отчета о проделанной работе;

- Составление отчета в налоговую службу;

- Составление отчета в ОРЛЛ.

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

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

2. Описание языка UML

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

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

UML дает общее соглашение между разработчиками, что такое класс, компоненты и т.д.

2.1 История UML

В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания нового языка объектно-ориентированного моделирования. За основу языка ими были взяты методы моделирования, разработанные Бучем и Рамбо (Object-Modeling Technique, OMT). OMT был ориентирован на анализ, а Booch -- на проектирование программных систем. В октябре 1995 года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). Осенью 1995 года к компании Rational присоединился Айвар Якобсон, автор метода Object-Oriented Software Engineering -- OOSE. OOSE обеспечивал превосходные возможности для спецификации бизнес-процессов и анализа требований при помощи сценариев использования. OOSE был также интегрирован в унифицированный метод.

На этом этапе основная роль в организации процесса разработки UML перешла к консорциуму OMG (Object Management Group). Группа разработчиков в OMG, в которую также входили Буч, Рамбо и Якобсон, выпустила спецификации UML версий 0.9 и 0.91 в июне и октябре 1996 года.

На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments и Unisys. Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе 1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики.

Последующие релизы UML включали версии 1.3, 1.4 и 1.5, опубликованные, соответственно в июне 1999, сентябре 2001 и марте 2003 года.

Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development -- MDD (англ.). Последняя версия UML 2.3 опубликована в мае 2010 года.

UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005.

2.2 Основные диаграммы языка UML

Ниже приведен список наиболее использующих диаграмм.

Структурные диаграммы:

- Классов

- Компонентов

- Кооперации (UML2.0)

- Развёртывания

- Пакетов

Диаграммы поведения:

- Деятельности

- Состояний

- Вариантов использования

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

- Коммуникации (UML2.0) / Кооперации (UML1.x)

- Последовательности.

Диаграмма Use Case(прецедентов)

Диаграмма прецедентов (англ. use case diagram, диаграмма вариантов использования) -- диаграмма, на которой отражены отношения, существующие между актерами и прецедентами.

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

При работе с вариантами использования важно помнить несколько простых правил:

§ каждый прецедент относится как минимум к одному действующему лицу;

§ каждый прецедент имеет инициатора;

§ каждый прецедент приводит к соответствующему результату (результату с «бизнес-значением»).

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

Диаграмма классов (Class diagram) -- статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.

Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:

§ концептуальная точка зрения -- диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;

§ точка зрения спецификации -- диаграмма классов применяется при проектировании информационных систем;

§ точка зрения реализации -- диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).

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

Диаграмма объектов (Object diagram) -- демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

Диаграммы коммуникации и последовательности

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

Диаграмма коммуникации (Communication diagram, в UML 1.x -- диаграмма кооперации, collaboration diagram) -- диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

Диаграмма последовательности (Sequence diagram) -- диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.

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

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

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

Диаграмма компонентов (Component diagram) -- статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

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

Диаграмма пакетов (Package diagram) -- структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.

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

Диаграмма деятельности (Activity diagram) -- диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов -- вложенных видов деятельности и отдельных действий(англ. action), соединённых между собой потоками, которые идут от выходов одного узла к входам другого.

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

2.3 Достоинства UML

1. UML объектно-ориентированный язык, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных ОО-языках;

2. UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

3. Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

4. Сокращение числа возможных ошибок таких как: несогласованные параметры подпрограмм, несогласованное изменение атрибутов;

5. Повторное использование. Предполагается какой-либо вариант многократного использования уже существующего проекта или его части в новом проекте;

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

7. UML получил широкое распространение и динамично развивается.

2.4 Недостатки UML

Несмотря на то, что UML достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:

1. Избыточность языка. UML часто критикуется, как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше компромиссов.

2. Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений -- формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.

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

4. Только код отражает код. Ещё одно мнение -- что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»). В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.

5. Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки -- термин из теории системного анализа для обозначения неспособности входа системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).

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

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

3. Характеристики используемого Case Средства (Rational Rose)

Аббревиатура CASE расшифровывается как Computer Aided Software Engineering (Автоматизированная Разработка Программного Обеспечения). CASE средства подразумевают процесс разработки сложных ИС в целом: создание и сопровождение ИС, анализ, формулировка требований, проектирование прикладного ПО и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. Таким образом, CASE-технологии образуют целую среду разработки ИС.

Большинство существующих CASE-средств основано на методологиях структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. Главные составляющие CASE-продукта таковы:

· методология (Method Diagrams), которая задает единый графический язык и правила работы с ним.

· графические редакторы (Graphic Editors), которые помогают рисовать диаграммы; возникли с распространением PC и GUI, так называемых «upper case технологий

· генератор: по графическому представлению модели можно сгенерировать исходный код для различных платформ (так называемая low case часть CASE-технологии).

· репозиторий, своеобразная база данных для хранения результатов работы программистов.

Разумеется, существуют свои недостатки применения технологий, значимыми являются недостатки со стороны аспектов бизнеса:

· CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

· реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

Ряд преимуществ созданной системы:

· высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

· положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;

· приемлемый уровень отдачи от инвестиций в CASE-средства.

Rational Rose - CASE-средство фирмы Rational Software Corporation - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

4. Разработка программного обеспечения информационной системы “Гостиничный комплекс”

Диаграмма Use Case (диаграмма вариантов использования, сценариев, прецедентов). Диаграммы позволяют наглядно представить ожидаемое поведение системы. Элементы, используемые на диаграмме:

· Сценарий. (Определяет один фрагмент поведения системы, без раскрытия внутреннего содержания)

· Актер. (Внешняя по отношению к главной системе сущность, которая участвует в сценариях, является инициатором, источником или приемником информации, внутреннее содержание не рассматривается.)

· Интерфейс

· Комментарий

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

Расчет оценки диаграммы.

S_diagr= ,

где S_obj-оценка элемента на диаграмме, S_link- оценка связей, Оbj- кол-во объектов на диаграмме, T_obj -количество типов объектов, T_link- количество типов связи.

S _diagram=

Рисунок 4.1.1. Общая USE-CASE диаграмма.

4.1 Диаграмма Классов

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

· концептуальная точка зрения -- диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;

· точка зрения спецификации -- диаграмма классов применяется при проектировании информационных систем;

· точка зрения реализации -- диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).

Элементы:

1) Класс - множество объектов, обладающие одинаковой структурой, поведением и отношением с другими классами.

Атрибуты-параметры класса(переменные).

Операции(методы)- функции, которые может выполнить класс или которые можно выполнить относительно него.

2) Связи между классами - поведенческие сущности, взаимодействие объектов. (Зависимость, обобщение, ассоциация, агрегирование, композиция, реализация.)

Расчет оценки диаграммы.

S_diagr= ,

где S_obj-оценка элемента на диаграмме, S_link- оценка связей, Оbj- кол-во объектов на диаграмме, T_obj -количество типов объектов, T_link- количество типов связи.

S_{clas =} ,

где Op- количество операций, Atr- количество атрибутов.



Рисунок 4.2.1. Диаграмма классов.

S _diagram=

S(Administrator)=

S(Sostav_gostinnici)=

S(Spisok_gostinnic)=

S(Upravlyaushiy)=

S(Spisok_postavchikov)=

S(Otdel_kadrov)=

S(Bankovskiy_schet)=

S(Zakazchik)=

S(Director_gostinnici)=

S(gostinnica)=

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

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

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

На данной диаграмме объекты располагаются слева направо.

Рисунок 4.3.1. Диаграмма последовательностей для сценария “Назначение в гостинницу”.

S _diagram=



Рисунок 4.3.2. Диаграмма последовательностей для сценария “Выдача ЗП”.

S _diagram=

Рисунок 4.3.3. Диаграмма последовательностей для сценария “Отчет в налоговую”.

S _diagram=



Рисунок 4.3.4. Диаграмма последовательностей для сценария “Отчет в ОРЛЛ”.

S _diagram=

Рисунок 4.3.5. Диаграмма последовательностей для сценария “Отчет о проделанной работе”.

S _diagram=

Рисунок 4.3.6. Диаграмма последовательностей для сценария “Перечисление средств”.

S _diagram=

Рисунок 4.3.7. Диаграмма последовательностей для сценария “Подписание договоров”.

S _diagram=

Рисунок 4.3.8. Диаграмма последовательностей для сценария “Получение заказа”.

S _diagram=

Рисунок 4.3.9. Диаграмма последовательностей для сценария “Получение лицензии”.

S _diagram=

Рисунок 4.3.10. Диаграмма последовательностей для сценария “Предоставление формы”.

S _diagram=



Рисунок 4.3.11. Диаграмма последовательностей для сценария “Прием на работу”.

S _diagram=

Рисунок 4.3.10. Диаграмма последовательностей для сценария “Формирование заказа”.

S _diagram=

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

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

Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой.

На диаграмме имеются два специальных состояния - начальное (start) и конечное (stop). Начальное состояние выделено черной точкой, оно соответствует состоянию объекта, когда он только что был создан. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объекта непосредственно перед его уничтожением. На диаграмме состояний может быть одно и только одно начальное состояние. В то же время, может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще. Когда объект находится в каком-то конкретном состоянии, могут выполняться различные процессы. Процессы, происходящие, когда объект находится в определенном состоянии, называются действиями (actions).

С состоянием можно связывать данные пяти типов: деятельность, входное действие, выходное действие, событие и история состояния.

Рисунок 4.4.1. Диаграмма состояний для класса “Otdel_kadrov”.

S _diagram=



Рисунок 4.4.2. Диаграмма состояний для класса Administrator“”.

S _diagram=

Рисунок 4.4.3. Диаграмма состояний для класса “Sostav_gostinnici”.

S _diagram=



Рисунок 4.4.4. Диаграмма состояний для класса “Spisok_gostinnic”.

S _diagram=

Рисунок 4.4.5. Диаграмма состояний для класса “gostinnica”.

S _diagram=



Рисунок 4.4.6. Диаграмма состояний для класса “Spisok_postavchikov”.

S _diagram=

Рисунок 4.4.7. Диаграмма состояний для класса “Postavchik”.

S _diagram=



Рисунок 4.4.8. Диаграмма состояний для класса “Director_gostinnicy”.

S _diagram=

Рисунок 4.4.9. Диаграмма состояний для класса “Upravlyaushiy”.

S _diagram=

Рисунок 4.4.6. Диаграмма состояний для класса “Bankovskiy_schet”.

S _diagram=

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

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

Рисунок 4.5.1. Диаграмма пакетов.

S _diagram=

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

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



Рисунок 4.6.1. Диаграмма размещения.

S =

Заключение

В данной курсовой работе спроектирована информационная система «Гостиничный комплекс» в нотации UML с использованием Сase-средства IBM Rational Rose EnterPrise Edition. Стоит отметить, что данные диаграммы отражают проектируемую систему, только на начальном этапе. В целом данная система является начальным наглядным макетом для дальнейшего усовершенствования, как каждого ее элемента в отдельности, так и всей модели в целом. После усовершенствования и уточнения, а именно после еще одного цикла проектирования, можно сказать, что будет создана основная база данных, которую, конечно, можно будет впоследствии доработать и еще, но уже можно будет приступить к началу разработки.

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

Список литературы

1. Леоненков А. Самоучитель UML -СПб.;БХВ-Петербург, 2007

2. БоггсУ., БоггсМ. UMLиRationalRose - М.: Лори, 2010

3. Трофимов С.А. Практическая работа в RationalRose - М.: Бином-Пресс, 2006

4. Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. CASE-технологии, практикум - М.: Горячая линия, 2005

5. Фаулер М., Скотт К. UML. Основы - СПб.:Символ-Плюс, 2008

Приложение

информационный гостиница программный

Результаты автоматической генерации текстов программ

ЦЕЛЬ РАБОТЫ

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

ЗАДАНИЕ

Разработать диаграмму классов (не менее 3 классов) для некоторой программы и провести автоматическую кодогенерацию при помощи Rational Rose.

ДИАГРАММЫ КЛАССОВ

Диаграмма классов показывает структуру головного офиса какого-либо предприятия. В состав головного офиса входят: отдел кадров, отдел по работе с персоналом, СБ (служба безопасности).

На диаграмме представлены следующие классы:

Office - Головной офис;

Сadr - отдел кадров;

Personal - отдел по работе с персоналом;

SB - служба безопасности.

СГЕНЕРИРОВАННЫЙ КОД

В результате генерации кода для каждого класса будут получены 2 файла: .h и .cpp. Файл с расширением .h содержит объявление функций. Файл с расширением .срр содержит исходные коды классов.

Ниже представлена библиотека для работы с классом «головной офис» (Office) приспособленная к дальнейшему написанию кода программы на c++, содержащая в себе заголовки функций и набор комментариев к этому классу.

Office.h

#ifndef OFFICE_H_HEADER_INCLUDED_ABB1AE0D

#define OFFICE_H_HEADER_INCLUDED_ABB1AE0D

//##ModelId=544E4882026B

class Office

{

public:

// ФИО Начальника

//##ModelId=544E4B09006E

string Boss;

private:

// Приказы о приеме на работу

//##ModelId=544E4C1A01F6

bool priem();

// Приказы о увольнении

//##ModelId=544E4C630259

bool uvolen();

// Состав штата сотрудников

//##ModelId=544E4BC60337

integer State;

};

#endif /* OFFICE_H_HEADER_INCLUDED_ABB1AE0D */

Ниже представлен шаблон кода для класса «головной офис» (Office), сгенерированный на языке C++ и предназначенный для дальнейшей реализации функций и написания программы.

Office. cpp

#include "Office.h"

//##ModelId=544E4C1A01F6

bool Office::priem()

{

}

//##ModelId=544E4C630259

bool Office::uvolen()

{

}

Ниже представлена библиотека для работы с классом «отдел кадров» (Сadr), приспособленная к дальнейшему написанию кода программы на c++, содержащая в себе заголовки функций для данного класса и набор комментариев к этому классу.

Cadr.h

#ifndef CADR_H_HEADER_INCLUDED_ABB1BF8E

#define CADR_H_HEADER_INCLUDED_ABB1BF8E

//##ModelId=544E4C9A01B5

class Cadr

{

public:

// Документооборот

//##ModelId=544E4D440034

docrotetion();

//##ModelId=544E4D6B032A

otpusk();

// ФИО Начальника

//##ModelId=544E4CD000ED

srting Boss;

private:

// Состав штата сотрудников

//##ModelId=544E4CEF02D4

integer preState;

};

#endif /* CADR_H_HEADER_INCLUDED_ABB1BF8E */

Ниже представлен шаблон кода для класса «отдел кадров» (Сadr), сгенерированный на языке C++ и предназначенный для дальнейшей реализации функций и написания программы.

Cadr.cpp

#include "Cadr.h"

//##ModelId=544E4D440034

Cadr::docrotetion()

{

}

//##ModelId=544E4D6B032A

Cadr::otpusk()

{

}

Ниже представлена библиотека для работы с классом «отдел по работе с персоналом» (Personal), приспособленная к дальнейшему написанию кода программы на c++, содержащая в себе заголовки функций для данного класса и набор комментариев к этому классу.

Personal.h

#ifndef PERSONAL_H_HEADER_INCLUDED_ABB189F2

#define PERSONAL_H_HEADER_INCLUDED_ABB189F2

//##ModelId=544E4DCE005B

class Personal

{

public:

// Распределение сотрудников

//##ModelId=544E4E1F0050

raspredelenie();

// Перевод сотрудников

//##ModelId=544E4E3002EA

peremechenie();

// ФИО Начальника

//##ModelId=544E4DE1037B

string Boss;

private:

// Состав штата сотрудников

//##ModelId=544E4E020260

integer preState;

};

#endif /* PERSONAL_H_HEADER_INCLUDED_ABB189F2 */

Ниже представлен шаблон кода для класса «отдел по работе с персоналом» (Personal)), сгенерированный на языке C++ и предназначенный для дальнейшей реализации функций и написания программы.

Personal.cpp

#include "Personal.h"

//##ModelId=544E4E1F0050

Personal::raspredelenie()

{

}

//##ModelId=544E4E3002EA

Personal::peremechenie()

{

}

Ниже представлена библиотека для работы с классом «служба безопасности» (SB), приспособленная к дальнейшему написанию кода программы на c++, содержащая в себе заголовки функций для данного класса и набор комментариев к этому классу.

SB.h

#ifndef SB_H_HEADER_INCLUDED_ABB1AD85

#define SB_H_HEADER_INCLUDED_ABB1AD85

//##ModelId=544E4E650081

class SB

{

public:

// Наблюдение за товарооборотом

//##ModelId=544E4EC701EC

nabludenie();

// Реакция на нарушение

//##ModelId=544E4ED203B4

reaksiya();

// ФИО Начальника

//##ModelId=544E4E8B01A3

sting Boss;

private:

// Состав штата сотрудников

//##ModelId=544E4EA003BA

integer preState;

};

#endif /* SB_H_HEADER_INCLUDED_ABB1AD85 */

Ниже представлен шаблон кода для класса «служба безопасности» (SB), сгенерированный на языке C++ и предназначенный для дальнейшей реализации функций и написания программы.

SB.cpp

#include "SB.h"

//##ModelId=544E4EC701EC

SB::nabludenie()

{

}

//##ModelId=544E4ED203B4

SB::reaksiya()

{

}

Размещено на Allbest.ru

...