Преподаватель который помогает студентам и школьникам в учёбе.

Применение объектно-ориентированного подхода при проектировании информационной системы (Базовые понятия объектно-ориентированного программирования)

Содержание:

Введение

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

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

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

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

Цель работы: создание системы обработки заказов с помощью объектно-ориентированного подхода к проектированию информационных систем.

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

Предмет исследования – проектирование информационной системы обработки заказов на основе объектно-ориентированного подхода (ООП).

В соответствии с объектом и предметом исследования были поставлены следующие задачи: изучить базовые понятия объектно-ориентированного подхода к моделированию информационных систем (ИС) и основные части унифицированного языка моделирования (UML); проанализировать требования к информационной системе путем концептуального и логического моделирования; разработать проект информационной системы средствами объектно-ориентированного подхода; определить наиболее подходящую модель жизненного цикла разработки проектируемой информационной системы.

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

1 Объектно-ориентированный подход к анализу и проектированию информационной системы

1.1 Базовые понятия объектно-ориентированного программирования

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

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

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

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

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

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

1.2 Унифицированный язык моделирования UML

Отдельные языки объектно-ориентированного моделирования стали появляться в период между серединой 1970-х и концом 1980-х годов, когда различные исследователи и программисты предлагали свои подходы к ООАП. В период между 1989-1994 гг. общее число наиболее известных языков моделирования возросло с 10 до более чем 50. Многие пользователи испытывали серьезные затруднения при выборе языка ООАП, поскольку ни один из них не удовлетворял всем требованиям, предъявляемым к построению моделей сложных систем. Принятие отдельных методик и графических нотаций в качестве стандартов (IDEF0, IDEF1X) не смогло изменить сложившуюся ситуацию непримиримой конкуренции между ними в начале 90-х годов, которая тоже получила название "войны методов".

К середине 1990-х некоторые из методов были существенно улучшены и приобрели самостоятельное значение при решении различных задач ООАП. Наиболее известными в этот период становятся:

Метод Г. Буча (Grady Booch), получивший условное название Booch или Booch'91, Booch'93.
Метод Дж. Рамбау (James Rumbaugh), получивший название Object Modeling Technique - ОМТ (позже - ОМТ-2).
Метод А. Джекобсона (Ivar Jacobson), получивший название Object-Oriented Software Engineering - OOSE.

Каждый из этих методов был ориентирован на поддержку отдельных этапов ООАП.

История развития языка UML (Unified Modeling Language) берет начало с октября 1994 года, когда Г.Буч и Дж. Рамбау из Rational Software Corporation начали работу по унификации методов Booch и ОМТ. Хотя сами по себе эти методы были достаточно популярны, совместная работа была направлена на изучение всех известных объектно-ориентированных методов с целью объединения их достоинств. При этом Г. Буч и Дж. Рамбау сосредоточили усилия на полной унификации результатов своей работы. Позже к ним присоединился А. Джекобсон, главный технолог из компании Objectory AB (Швеция), с целью интеграции своего метода OOSE с двумя предыдущими.

Вначале авторы методов Booch, ОМТ и OOSE предполагали разработать унифицированный язык моделирования только для этих трех методик. С одной стороны, каждый из этих методов был проверен на практике и показал свою конструктивность при решении отдельных задач ООАП. Это давало основание для дальнейшей их модификации на основе устранения имеющегося несоответствия отдельных понятий и обозначений. С другой стороны, унификация семантики и нотации должна была обеспечить некоторую стабильность на рынке объектно-ориентированных CASE-средств, которая необходима для успешного продвижения соответствующих программных инструментариев. Наконец, совместная работа давала надежду на существенное улучшение всех трех методов.

Начиная работу по унификации своих методов, Г. Буч, Дж. Рамбау и А. Джекобсон сформулировали следующие требования к языку моделирования. Он должен:

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

Усилия Г. Буча, Дж. Рамбау и А. Джекобсона привели к появлению первых документов, содержащих описание собственно языка UML версии 0.9 (июнь 1996 г.) и версии 0.91 (октябрь 1996 г.). Имевшие статус запроса предложений RTP (Request For Proposals), эти документы послужили своеобразным катализатором для широкого обсуждения языка UML различными категориями специалистов. Первые отзывы и реакция на язык UML указывали на необходимость его дополнения отдельными понятиями и конструкциями.

В это же время стало ясно, что некоторые компании и организации видят в языке UML линию стратегических интересов для своего бизнеса. Компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально вошли такие компании, как Digital Equipment Corp., HP, i-Logics, Intellicorp, IBM, ICON Computing, MCI System house, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей работы по более точному и строгому определению нотации, что привело к появлению версии 1.0 языка UML. В январе 1997 года был опубликован документ с описанием языка UML 1.0, как начальный вариант ответа на запрос предложений RTP. Эта версия языка моделирования была достаточно хорошо определена, обеспечивала требуемую выразительность и мощность и предполагала решение широкого класса задач.

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

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

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

На основе технологии UML Microsoft, Rational Software и другие поставщики средств разработки программных систем разработали единую информационную модель, которая получила название UML Information Model. Предполагается, что эта модель даст возможность различным программам, поддерживающим идеологию UML, обмениваться между собой компонентами и описаниями. Все это позволит создать стандартный интерфейс между средствами разработки приложений и средствами визуального моделирования.

Уже в настоящее время разработаны средства визуального программирования на основе UML, обеспечивающие интеграцию, включая прямую и обратную генерацию кода программ, с наиболее распространенными языками и средами программирования, такими как MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic и другие. Поскольку при разработке языка UML были приняты во внимание многие передовые идеи и методы, можно ожидать, что на очередные версии языка UML также окажут влияние и другие перспективные технологии и концепции. Кроме того, на основе языка UML могут быть определены многие новые перспективные методы. Язык UML может быть расширен без переопределения его ядра.

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

Информационные системы масштаба предприятия
Банковские и финансовые услуги
Телекоммуникации и транспорт
Распределенные web-системы

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

Подводя итог анализу методологии ООАП и исторических предпосылок появления UML, можно утверждать следующее. Имеются все основания предполагать, что в ближайшие годы язык UML в его современном виде станет основой для разработки и реализации во многих перспективных инструментальных средствах: в RAD-средствах визуального и имитационного моделирования, а также в CASE-средствах самого различного целевого назначения. Более того, заложенные в языке UML потенциальные возможности могут быть использованы не только для объектно-ориентированного моделирования систем, но и для представления знаний в интеллектуальных системах, которыми, по существу, станут перспективные сложные программно-технологические комплексы.

В данной работе с помощью языка UML проводится моделирование информационной системы обработки заказов.

1.3 Составные части языка UML

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

Словарь языка UML включает три вида строительных блоков:

сущности;
отношения;
диаграммы.

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

В UML имеется четыре типа сущностей: структурные, поведенческие, группирующие, аннотационные.

Сущности являются основными объектно-ориентированными блоками языка. С их помощью можно создавать определенные модели.

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

Класс (Class) – это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой.

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

Прецедент (Use Case) – это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (Actor). Прецедент применяется для структурирования поведенческих сущностей модели. Прецеденты реализуются посредством кооперации.

Три другие сущности – активные классы, компоненты и узлы – подобны классам: они описывают совокупности объектов с общими атрибутами, операциями, отношениями и семантикой.

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

Поведенческие сущности (Behavioral things) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует два основных типа поведенческих сущностей:

Взаимодействие (Interaction) – это поведение, суть которого заключается в обмене сообщениями между объектами в рамках конкретного контекста для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов.
Автомат (State machine) – это алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события. С помощью автомата можно описать поведение отдельного класса или кооперации классов.

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

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Есть только одна первичная группирующая сущность – пакет.

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

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

В языке UML также определены четыре типа отношений:

зависимость;
ассоциация;
обобщение;
реализация.

Эти отношения являются основными связующими строительными блоками в UML и применяются для создания корректных моделей.

Зависимость (Dependency) – это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой.

Ассоциация (Association) – структурное отношение, описывающее совокупность связей; связь – это соединение между объектами.

Обобщение (Generalization) – это отношение «специализация/ обобщение», при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка).

Реализация (Realization) – это семантическое отношение между классификаторами, при котором один классификатор определяет «контракт», а другой гарантирует его выполнение.

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

диаграммы классов (Class Diagrams);
диаграммы объектов (Object Diagrams);
диаграммы прецедентов/ вариантов использования (Use Case Diagrams);
диаграммы последовательностей (Sequence Diagrams);
диаграммы кооперации/ сотрудничества (Collaboration Diagrams);
диаграммы состояний (Statechart Diagrams);
диаграммы деятельности (Activity Diagrams);
диаграммы компонентов (Component Diagrams);
диаграммы развертывания/ размещения (Deployment Diagrams).

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

1. Диаграмма прецедентов или вариантов использования (Use Case Diagram) – для представления системы с точки зрения прецедентов и выявления требований к ней.
2. Диаграмма классов (Class Diagram) – для моделирования статической структуры системы и взаимосвязи между классами.
3. Диаграмма последовательности (Sequence Diagram) – для моделирования процессов сообщения между объектами.
4. Диаграмма компонентов (Component Diagram) – для моделирования иерархии элементов системы.
5. Диаграмма развертывания или размещения (Deployment Diagram) – для моделирования физической архитектуры системы.

2 Анализ информационной системы обработки заказов на основе объектно-ориентированного подхода

2.1 Создание диаграмм вариантов использования

В результате предшествующего проекту исследования было составлено следующее описание предметной области:

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

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

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

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

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

В данном случае роль Актера (Actor) будут играть Компания-посредник, Клиент, Транспортная компания, Банк, Сайт. Каждый вариант использования показывает, как конкретный актер использует систему. Необходимо рассмотреть и виды отношений, которыми они связаны.

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

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

Сотрудник транспортной компании – обладает следующими полномочиями: доставляет товары по адресам клиентов, информирует компанию-посредника о доставке.

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

include

include Сайт

Компания-посредник

include

include Клиент

include

Транспортная компания Информационная система

Банк

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

Краткое описание вариантов использования, изображенных на рисунке.

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

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

Вариант использования «Сформировать заказ» подразумевает, что компания-посредник посылает необходимую информацию о клиенте и сам заказ в транспортную компанию.

Вариант использования «Доставить заказ» и «Информировать о доставке» позволяет транспортной компании доставить заказ по адресу клиента в заданный срок, а затем информировать компанию-посредника о результате доставки заказа клиентам.

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

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

2.2 Моделирование системы с использованием диаграммы классов

Диаграммой классов (Class Diagram) называют диаграмму, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Класс – это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой.

В рамках данной системы будут присутствовать 3 класса: Клиент, Транспортная компания и Заказ.

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

Чтобы заказ был получен клиентом, необходимо его доставить по определенному адресу и в определенные сроки. Следовательно, на диаграмме необходимо указать класс «Транспортная компания», который будет также иметь соответствующие атрибуты, и выполнять определенные операции.

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

Атрибут – это именованное свойство класса, включающее описание множества значений, которые могут принимать его отдельные экземпляры. Имя атрибута – это строка текста, однозначно его идентифицирующая. Оно является обязательным и выражается, как правило, в форме имени существительного. Важным аспектом при описании атрибута является его тип. Он представляет собой выражение, семантика которого определяется языком описания соответствующей модели. Общепринятые типы атрибутов – текстовый, целочисленный, логический (String, Integer, Boolean).

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

Таким образом, класс «Клиент» будет иметь следующие атрибуты:

№ Заказа: Integer
ФИО: String
Дата_рождения: Integer
Телефон: Integer
Адрес: Integer

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

public (общий). Атрибут с таким квантором доступен из любого другого класса пакета, в котором определена данная диаграмма.
protected (защищенный). Такой атрибут недоступен для всех классов за исключением подклассов данного класса.
private (закрытый). Данный атрибут недоступен для всех без исключения классификаторов.

Класс «Клиент» на фрагменте диаграммы классов будет представлен следующим образом (рис. 2):

Клиент

+ № Заказа: Integer

+ ФИО: String

+ Дата_рождения: Integer

+ Телефон: Integer

+ Адрес: Integer

+ Оформлять_заказ()

+ Получать_заказ()

+ Возвращать_заказ()

Рисунок 2 – Класс «Клиент»

При логическом моделировании статической структуры информационной системы обработки заказов, диаграмма классов будет выглядеть следующим образом (рис.3):

Клиент

+ № Заказа: Integer

+ ФИО: String

+ Дата_рождения: Integer

+ Телефон: Integer

+ Адрес: Integer

+ Оформлять_заказ()

+ Получать_заказ()

+ Возвращать_заказ()

Транспортная компания

+ Название_фирмы: String

+ Телефон: Integer

+ Адрес: Integer

+ Срок доставки: Integer

+ Дата отправки: Integer

+ Доставлять_заказ()

+ Информировать_о_доставке()

оформляет доставляет

Заказ

+ № Заказа: Integer

+ Список_товаров: String

+ Стоимость_заказа: Integer

+ Оплата_заказа: String

+ Дата_оплаты: Integer

+ Дата_доставки: Integer

+ Информация_о_возвращенных_товарах: String

+ Выполняться()

Рисунок 3 – Диаграмма классов

3 Проектирование информационной системы обработки заказов

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

Диаграммы последовательности относятся к числу пяти видов диаграмм, применяемых в UML для моделирования динамических аспектов системы.

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

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

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

Большая часть объектов существует на протяжении всего взаимодействия, но они могут уничтожаться и во время взаимодействий; в таком случае их линии жизни заканчиваются получением сообщения со стереотипом destroy. В данном случае этот тип сообщения не используется.

На данной диаграмме последовательности будет отображаться вариант использования «Информировать о доставке». Тем самым объектами взаимодействия будут являться Транспортная компания, Форма информационной системы, БД заказов. Эти объекты выполняют определенные действия (инициированные сообщениями) в хронологическом порядке. Таким образом, при логическом моделировании поведения информационной системы бронирования туров, диаграмма последовательности будет выглядеть следующим образом (рис.4):

БД заказов

Форма

Тр. компания

открыть

указать № заказа

найти заказ по номеру

предоставить информацию о заказе

вписать новую информацию

создать новую запись

подтвердить создание

указать месяц доставки

указать день доставки

указать время доставки

завершить ввод

сохранить запись

Рисунок 4 – Диаграмма последовательности

3.2 Разработка физической модели проектируемой системы

Представление системы с точки зрения компонентов

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

В UML определены 5 стандартных стереотипов, применимых к компонентам:

executable (исполняемый) – определяет компонент, который может исполняться в узле;
library (библиотека) – определяет статическую или динамическую объектную библиотеку;
table (таблица) – определяет компонент, представляющий таблицу базы данных;
file (файл) – определяет компонент, представляющий документ, который содержит исходный текст или данные;
document (документ) – определяет компонент, представляющий документ.

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

- - - Client.exe;
    - Posrednik.exe;
    - Catalog.htm;
    - Zakaz.mdb;
    - Address.mdb;
    - Money.mdb;
    - Dostavka.mdb.

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

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

Catalog.exe

Client.exe

Posrednic.exe

Money.mdb

Dostavka.mdb

Address.mdb

Zakaz.mdb

БД компании-посредника

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

Таким образом, рассмотрев диаграмму можно понять, что сотрудник компании-посредника Posrednic.exe использует базу данных, содержащую информацию о заказах Zakaz.mdb, сделанных клиентами, адресах клиентов Address.mdb, по которым нужно доставить товар. А также с базой данных банка Money.mdb, чтобы узнать достоверность информации об оплате заказа клиентом, и базой данных транспортных компаний Dostavka.mdb, услугами которых используется при доставке заказов клиентам.

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

Представление системы с точки зрения размещения

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

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

В данном случае узлы представлены сервером компании-посредника, компьютером клиента и компьютером менеджера компании, а также сервер, на котором находится сайт компании. На данном сервере будет размещен компонент Catalog.htm.

На сервере компании-посредника будут размещены следующие компоненты: Zakaz.mdb, Address.mdb, Money.mdb, Dostavka.mdb. Каждый из вышеперечисленных компонентов выполняет определенную функцию: компонент Zakaz.mdb, который представляет собой базу данных с информацией о заказах и их конфигурации; компонент Money.mdb – база данных, в которой содержится информация об оплате заказов; компонент Address.mdb – база данных, в которой содержится информация об адресах клиентов; Dostavka.mdb – база данных, содержащая информацию о доставке заказов клиентам.

На узлах ПК Клиента и ПК Менеджера будет размещаться исполняемый модуль Client.exe и Posrednic.exe. ПК Клиента и сервер, на котором расположен сайт компании подключены к Интернет. А ПК менеджера компании и сервер объединены в локальную сеть, через которую можно получать информацию, выходить в Internet и вносить изменения в базы данных. При физическом моделировании информационной системы обработки заказов, диаграмма развертывания (размещения) будет выглядеть следующим образом (рис. 6):

Сервер Host

Internet

ПК Клиента

Сервер компании-посредника

ПК Менеджера

Локальная сеть компании

Address.mdb

Money.mdb

Dostavka.mdb

Zakaz.mdb

Klient.exe

Catalog.htm

Posrednik.exe

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

4 Выбор модели жизненного цикла разработки информационной системы

4.1 Модели и стандарты жизненного цикл информационных систем

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

Существует несколько моделей и стандартов, в той или иной степени регламентирующих жизненный цикл, большинство из них относятся к заказному ПО и кроме непосредственно ЖЦ регламентируют также и процессы разработки:

ГОСТ 34.601-90 распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.
ISO/IEC 12207:1995 стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий, этапов.
Custom Development Method (и методика Oracle) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle.
Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования.

Прохождение через четыре основные фазы называется циклом разработки. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей, а не бумажных документов, поэтому этот процесс привязан к использованию конкретных средств моделирования (UML), а так же конкретной технологии проектирования и разработки (объектно-ориентированный анализ, object-oriented analysis, OOA, объектно-ориентированное программирование, object-oriented programming, OOP).

Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

Приведенный перечень далеко не полный, разработчики крупных информационных систем и компании-интеграторы так же предлагают свои методологии внедрения. Так, компания IBM внесла значительный вклад в теорию проектирования и разработки информационных систем, предложив еще в середине 1970-х годов методологию BSP (Business System Planning, система организационного планирования).

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

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

4.2 Характеристика и оценка основных моделей жизненного цикла информационных систем

Различают две основные формальные модели ЖЦ: каскадную (последовательную) и спиральную (итерационную).

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

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

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

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

Модель доступна для понимания, проста и удобна в применении, ей может руководствоваться даже персонал, не имеющий специальной подготовки. Нужно отметить, что этот аспект будет являться немаловажным, так как разработанная информационная система предназначена для пользователей, не имеющих глубоких познаний в данной сфере.
Данная модель отличается стабильностью требований. Здесь необходимо учесть тот факт, что определенные для информационно-предметной области системы требования, ее назначение, линии поведения и интерфейсы заранее оговорены и конкретны. Их изменение в процессе выполнения проекта маловероятно.
В некоторых областях спиральная модель не может применяться, поскольку невозможно использование/тестирование продукта, обладающего неполной функциональностью. Трудозатраты при поэтапном итерационном внедрении оказываются значительно выше, а управление проектом требует настоящего искусства. Предвидя указанные сложности, заказчики выбирают каскадную модель, чтобы «внедрять систему один раз».
Вывод системы из эксплуатации осуществляется путем прекращения работы с ней и замены ее на новую. В данном конкретном случае это удобно, поскольку если система перестанет удовлетворять потребности ее пользователей ее можно безболезненно заменить на более подходящую.

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

Заключение

Для достижения цели проекта были решены четыре задачи.

В ходе решения первой задачи были выявлены области, в которых использование UML наиболее эффективно.

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

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

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

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

Список использованных источников

Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. Слинкин А.А. – Учебное пособие – М.: ДМК Пресс, 2000. - 432 с.
Вендров А.М. Проектирование программного обеспечения экономических информационных систем. – М.:Финансы и статистика, 2000.-187с.
Калянов Г.Н. CASE-технологии. Консалтинг при автоматизации предприятий.-М.:СИНТЕГ, 1997.-276с.
Леонтьев А.В. Самоучитель UML – Учебное пособие – СПб.: БХВ-Петербург, 2001. – 304с.
Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования; Пер.с.англ. – М.:Мир, 1999.-236с.
Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. – Киев: Диалектика, 1993.-193с.
www.rational.com
www.interface.ru
www.intuit.ru