Файл: Генерация программного кода C++.pdf

Введение

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

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

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

В качестве среды разработки информационной подсистемы был использован программный продукт Rational Rose 2000 Enterprise v6.5.

Глава 1. Характеристика предметной области

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

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

Обоснование актуальности разработки объектно-ориентрованной модели информационной подсистемы. Актуальность разработки объектно-ориентированной модели информационной подсистемы для учета движения товаров на складе обуславливается применением языка UML (Unified Modeling Language).

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

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

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

В качестве среды разработки информационной подсистемы был использован программный продукт Rational Rose Enterprise v6.5.

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

• диаграмму вариантов использования;
• диаграмму последовательности;
• диаграмму сотрудничества;
• диаграмму классов;
• диаграмму состояний;
• диаграмму компонентов;
• диаграмму размещения;
• программный код на языке С++.

1.1. Создание диаграммы прецедентов

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

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

Элементы диаграммы:

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

Ри?сунок 1.1 - Ди?аграмма пр?ецедентовВ ка?честве ак?теров на ди?аграмме (р?исунок 1.1) ис?пользуются об?ъекты:

• «z?av_sklad» (з?аведующий складом), ко?торый уп?равляет ва?риантами ис?пользования:
• «o?borot_mes» (о?борот за ме?сяц);
• «r?eviziya» (р?евизия);
• «k?lad» (кладовщик), уп?равляющий сл?едующими ва?риантами ис?пользования:
• «g?et_tovar» (п?ринять то?вар);
• «s?end_tovar» (о?тправить то?вар);
• «i?nventar» (инвентаризация).

Ме?жду ва?риантами ис?пользования и де?йствующими ли?цами ис?пользуется вя?зь ко?ммуникации (communication). На?правление ст?релки по?зволяет понять, кт?о ин?ициирует коммуникацию.

Дл?я по?строения ос?тальных диаграмм, вы?бран пр?ецедент «g?et_tovar» (п?ринять товар), ко?торый оп?исывает по?лучение но?вого то?вара от по?ставщика и со?здание ка?рточки ск?ладского учета.

1.2. Создание диаграммы последовательности

Ди?аграмма по?следовательности (s?equence di?agram) - эт?о ди?аграмма взаимодействий, ак?центирующая вн?имание на вр?еменной уп?орядоченности сообщений. Он?а от?ражают по?ток событий, пр?оисходящих в ра?мках ва?рианта использования. Ко?нкретный эк?земпляр по?тока со?бытий на?зывается сценарием.

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

На ди?аграмме по?следовательности об?ъект из?ображается в ви?де пр?ямоугольника на ве?ршине пу?нктирной ве?ртикальной линии. Эт?а ве?ртикальная ли?ния на?зывается ли?нией жи?зни (l?ifeline) объекта. Он?а пр?едставляет со?бой фр?агмент жи?зненного ци?кла об?ъекта в пр?оцессе взаимодействия.

Ка?ждое со?общение из?ображается в ви?де ст?релки ме?жду ли?ниями жи?зни дв?ух объектов. Со?общения по?являются в то?м порядке, ка?к он?и по?казаны на странице, св?ерху вниз. Ка?ждое со?общение по?мечается ка?к ми?нимум им?енем со?общения; пр?и же?лании мо?жно до?бавить та?кже ар?гументы и не?которую уп?равляющую ин?формацию и, кр?оме того, по?казать са?моделегирование (s?elf-delegation) -сообщение, ко?торое об?ъект по?сылает са?мому себе, пр?и эт?ом ст?релка со?общения ук?азывает на ту же са?мую ли?нию жизни.

В да?нной мо?дели дл?я со?здания ди?аграммы по?следовательности бы?л ис?пользован ва?риант ис?пользования «g?et_tovar» (п?ринять товар), вз?ятый из пр?едыдущей ди?аграммы пр?ецедентов (р?исунок 1.2).

Ри?сунок 1.?2 - Ди?аграмма по?следовательности «g?et_tovar» (п?ринять то?вар)

На да?нную ди?аграмму по?мещены сл?едующие об?ъекты:

«k?lad» (к?ладовщик) - де?йствующее ли?цо;

«A?dd/Select To?var Fo?rm» - со?держит фо?рму вв?ода ил?и вы?бора то?вара;

«A?dd/Select Po?stav Fo?rm» - со?держит фо?рму вв?ода ил?и вы?бора по?ставщика то?вара;

«C?ard Sk?lad_Uchet» - фо?рма ка?рты ск?ладского учета, ко?торая со?здается по?сле вв?ода вс?ех да?нных и яв?ляется ит?оговым до?кументом;

«D?ataBase» - со?держит ин?формацию о по?ставщиках и товарах, на ос?новании ин?формации эт?ого об?ъекта фо?рмируется ка?рта ск?ладского уч?ета

Со?общения ме?жду об?ъектами на ди?аграмме:

«O?pen» - от?крыть фо?рму;

«C?ancel» - от?мена де?йствия;

«Q?uery to Da?taBase» - за?прос к ба?зе да?нных на вы?бор то?вара;

«A?nswer fr?om Da?taBase» - на?именование то?вара;

«Q?uery to Da?taBase on ge?neration Sk?lad_Uchet ca?rd» - за?прос к ба?зе да?нных на вы?бор по?ставщика и ге?нерацию ка?рты ск?ладского уч?ета;

«G?enerate» - ка?рта ск?ладского учета.

По?сле со?здания об?ъектов и со?общений ме?жду ни?ми бы?ло вы?полнено со?отнесение об?ъектов с классами, а со?общений с операциями. Вс?е на?звания об?ъектов и со?общений со?впадают с на?званиями кл?ассов и оп?ераций соответственно.

Выводы

1.? На ди?аграмме по?следовательности «g?et_tovar» (п?ринять товар), ра?змещены пя?ть об?ъектов и де?вять со?общений ме?жду ними.

2.? Каждый об?ъект бы?л со?отнесен с классом, а со?общение с операцией.

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

Вт?орым ви?дом ди?аграммы вз?аимодействия яв?ляется ко?оперативная ди?аграмма (c?ollaboration diagram).

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

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

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

Со?гласно со?зданной вы?ше ди?аграмме «g?et_tovar» (п?ринять товар), бы?ла со?здана ди?аграмма со?трудничества (р?исунок 1.3).

На ди?аграмме ра?сположены об?ъекты:

«sklad»;

«A?dd/Select To?var Fo?rm»;

«A?dd/Select Po?stav Fo?rm»;

«C?ard Sk?lad_Uchet»;

«DataBase».

На?значение да?нных об?ъектов ан?алогично со?ответствующим об?ъектам ди?аграммы последовательности.

Ри?сунок 1.?3 - Ди?аграмма со?трудничества дл?я ва?рианта ис?пользования «g?et_tovar» (п?ринять то?вар)

Выводы

Бы?ла со?здана ди?аграмма со?трудничества «g?et_tovar» (п?ринять товар), на ко?торой пр?едставлена вс?я та информация, ко?торая бы?ла и на ди?аграмме последовательности, но ко?оперативная ди?аграмма по?-другому оп?исывает по?ток событий. Из не?е ле?гче по?нять св?язи ме?жду объектами, од?нако тр?уднее ра?зобраться в по?следовательности событий.

1.4. Создание диаграммы классов

Ди?аграммы кл?ассов (c?lass di?agram) по?зволяет со?здавать ло?гическое пр?едставление системы, на ос?нове ко?торого со?здается ис?ходный ко?д оп?исанных классов. Зн?ачки ди?аграммы по?зволяют от?ображать сл?ожную ие?рархию систем, вз?аимосвязи кл?ассов (с?lasses) и ин?терфейсов (interfaces). На ди?аграммах кл?ассов из?ображаются та?кже ат?рибуты классов, оп?ерации кл?ассов и ограничения, ко?торые на?кладываются на св?язи ме?жду кл?ассами Да?нный ти?п ди?аграмм пр?отивоположен по со?держанию ди?аграмме сотрудничества, на ко?торой от?ображаются об?ъекты системы.

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

Об?ычно дл?я оп?исания си?стемы со?здают не?сколько ди?аграмм классов. На од?них по?казывают не?которое по?дмножество кл?ассов и от?ношения ме?жду кл?ассами подмножества. На др?угих от?ображают то же подмножество, но вм?есте с ат?рибутами и оп?ерациями классов. Тр?етьи со?ответствуют то?лько па?кетам кл?ассов и от?ношениям ме?жду ними. По ум?олчанию су?ществует од?на ди?аграмма классов, на?зываемая Гл?авной (Main), на ко?торой по?казывают па?кеты кл?ассов мо?дели (р?исунок 1.4).

Ри?сунок 1.?4 - Гл?авная ди?аграмма кл?ассов ин?формационной по?дсистемы

Вн?утри ка?ждого па?кета та?кже им?еется «г?лавная диаграмма», вк?лючающая в се?бя вс?е кл?ассы эт?ого па?кета (р?исунок 1.5, 1.6).