Введение. 
Моделирование деятельности работы интернет-магазина

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

Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE).

Объектно-ориентированная методология (ООМ) создания автоматизированных систем состоит из следующих частей:

• · объектно-ориентированный анализ (OOA),
• · объектно-ориентированное проектирование (OOD),
• · объектно-ориентированное программирование (OOР).

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

OOР — совокупность идей и понятий, определяющая стиль написания программ, в которой основными концепциями являются понятия объектов и классов.

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

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

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

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

Атрибут — поименованное свойство класса, определяющее диапазон допустимых значений, которые могут принимать экземпляры данного свойства. Атрибуты могут быть скрыты от других классов, это определяет видимость атрибута: рublic (общий, открытый); private (закрытый, секретный); protected (защищенный).

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

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

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

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

Между элементами объектной модели существуют различные виды связей:

• · ассоциация — это семантическая связь между классами;
• · агрегация — более сильный тип связи между целым и его частями;
• · зависимость — связь между двумя элементами модели, при которой изменения в спецификации одного элемента могут повлечь за собой изменения в другом элементе;
• · обобщение — связь «тип — подтип».

Метод объектно-ориентированного проектирования основывается на:

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

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

Инкапсуляция.

Концепция сокрытия в как бы «капсуле» всей информации об объекте, то есть объединение в некое целое данных и процедур (методов) их обработки. Единицей инкапсуляции в OOD является объект, в котором содержатся и данные состояния объекта и сообщения, которые объект может обрабатывать. Т. е. инкапсуляция означает сочетание структур данных с методами их обработки в абстрактных типах данных — классах объектов.

Наследование.

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

Полиморфизм.

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

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

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

Выделено четыре этапа объектно-ориентированного проектирования:

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

Развитие методик и языков ООАП. Назначение языка UML, причины его возникновения.

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

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

Наиболее известными в этот период становятся:

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

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

Усилия Г. Буча, Дж. Румбаха и А. Джекобсона привели к появлению первых документов, содержащих описание собственно языка UML (Unified Modeling Language), эти документы послужили своеобразным катализатором для широкого обсуждения языка UML различными категориями специалистов. Первые отзывы и реакция на язык UML указывали на необходимость его дополнения отдельными понятиями и конструкциями.

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

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

В настоящее время все вопросы дальнейшей разработки языка UML сконцентрированы в рамках консорциума OMG (Object Management Group). Соответствующая группа специалистов обеспечивает публикацию материалов, содержащих описание последующих версий языка UML и запросов предложений RFP (Request for Proposal) по его стандартизации. Очередной этап развития данного языка закончился в марте 1999 года, когда консорциумом OMG было опубликовано описание языка UML 1.3.

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

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

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

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

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

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

Унифицированный язык моделирования UML стал основой для целого спектра различных средств поддержки разработки программного обеспечения — CASE-средств (Computer-Aided Software Engineering).

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

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

К появлению CASE-технологии способствовали и такие факторы, как:

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

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

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

Все современные CASE-средства можно классифицировать по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла. Помимо этого, CASE-средства можно классифицировать по категориям, применяемым методологиям и моделям систем и БД; степени интегрированности с СУБД; доступным платформам.

К основным достоинствам CASE-средств можно отнести:

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

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

Но все же грамотное, продуманное и обоснованное использование CASE-технологии способно принести следующие выгоды:

• · высокий уровень технологической поддержки процессов разработки и сопровождения ПО;
• · положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;
• · приемлемый уровень отдачи от инвестиций в CASE-средства.

Rational Rose — CASE-средство фирмы Rational Software Corporation (США) — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации.

IBM Rational Rose — популярное средство визуального моделирования, которое считается стандартом де-факто среди средств визуального проектирования приложений. Этот продукт входит в состав пакета IBM Rational Suite и предназначен для моделирования программных систем с использованием широкого круга инструментальных средств и платформ. Инструментальное средство IBM Rational Rose расширяет возможности моделирования программных систем, выходящих за рамки платформы J2EE и инструментальных средств моделирования в составе IBM Rational Professional Bundle.

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

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

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

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

Достоинства продукта Rational Rose.

• · мощный графический язык моделирования предметной области, обладающий высоким уровнем формализации и поддерживающий объектно-ориентированную методологию;
• · удобная навигация между элементами модели при помощи «инспектора проекта» ;
• · хранение результатов проектирования в виде единой модели;
• · поддержка работы над проектом группы разработчиков;
• · данное CASE средство может быть применено для создания разнообразного объектно-ориентированного программного обеспечения, в первую очередь для платформы Windows, а также на языке Java;
• · на всех этапах разработки применяется язык UML, и проект программного средства представляет собой единую модель;
• · возможность конфигурирования системы с помощью модулей расширения;
• · в наибольшей степени подходит для разработки крупных информационных систем, так как реализует большую часть функций ARIS и ERwin/BPwin. И т.д.

Недостатки продукта Rational Rose.

• · слабо реализована поддержка проектирования ПО для других операционных систем, почти все стандартные рабочие среды ориентированны на построение Windows-приложений, единственным способом написания приложения для не-Windows операционной системы является использование языка Java, производительность которого, пока, оставляет желать лучшего.
• · сложность самого языка UML также накладывает определенные ограничения на привлечение к работам над проектами непрофессионалов,
• · нельзя показать и удалить неиспользуемые объекты в отличие от BPWin;
• · недостаточно функциональная графика (нельзя менять толщину линий, надписи не центрируются, текст не всегда можно поместить целиком, иногда он обрезается);
• · не поддерживает функционально-стоимостной анализ;
• · нет возможности отобразить потоки данных между объектами или процессами.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

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