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

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

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

· объектно-ориентированный анализ (OOA),

· объектно-ориентированное проектирование (OOD),

· объектно-ориентированное программирование (OOР).

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

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

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

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

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

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

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

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

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

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

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

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

· ассоциация - это семантическая связь между классами;

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

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

· обобщение - связь «тип - подтип».

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

· модели построения системы как совокупности объектов абстрактного типа данных;

· модульной структуре программ;

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

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

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

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

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

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

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

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

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

К середине 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, эти документы послужили своеобразным катализатором для широкого обсуждения языка 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. Эта версия языка моделирования была достаточно хорошо определена, обеспечивала требуемую выразительность и мощность и предполагала решение широкого класса задач.

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

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

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

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

Подводя итог анализу методологии ООАП и исторических предпосылок появления UML, можно утверждать следующее. Имеются все основания предполагать, что в ближайшие годы язык UML в его современном виде станет основой для разработки и реализации во многих перспективных инструментальных средствах: в RAD-средствах визуального и имитационного моделирования, а также в 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 формируются следующие документы:

· диаграммы классов;

· диаграммы состояний;

· диаграммы сценариев;

· диаграммы модулей;

· диаграммы процессов;

· спецификации классов, объектов, атрибутов и операций

· заготовки текстов программ;

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

1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ