 |
Задачи и особенности объектно-ориентированного проектирования
|
|
|
|
Контрольная работа №1
по учебной дисциплине
СОВРЕМЕННЫЕ ПРОБЛЕМЫ ИНФОРМАТИКИ И ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ
Вариант №10
Выполнил: Лапаевас Э.В.
Группа: 0021-08М
Проверил: Бруттан Ю.В.
Псков
Содержание
Задание. 3
Введение. 4
Задачи и особенности объектно-ориентированного проектирования. 5
Основные понятия и модели объектно-ориентированного проектирования. 12
Варианты представления моделей и средства объектно-ориентированного проектирования. 26
Вывод. 34
Список литературы.. 35
Задание
Написать реферат (объёмом не менее 20 печатных страниц формата А4) на тему в соответствии с вариантом. Варианты заданий контрольной работы представлены в таблице 1.
Введение
Цель работы – раскрыть особенности объектно-ориентированного проектирования.
В соответствии с поставленной целью решались следующие основные задачи:
- изучить задачи и особенности объектно-ориентированного проектирования;
- изучить основные понятия и модели объектно-ориентированного проектирования;
- рассмотреть варианты представления моделей и средства объектно-ориентированного проектирования.
Задачи и особенности объектно-ориентированного проектирования
Объектно-ориентированное проектирование представляет собой стратегию, в рамках которой программная система состоит из взаимодействующих объектов, имеющих собственное локальное состояние и способных выполнять определенный набор операций, определяемый состоянием объекта. Объекты скрывают информацию о представлении состояний и, следовательно, ограничивают к ним доступ. Под процессом ООП подразумевается проектирование классов объектов и взаимоотношений между этими классами. Объектно-ориентированные системы можно рассматривать как совокупность автономных и в определенной степени независимых объектов. Изменение реализации какого-нибудь объекта или добавление новых функций не влияет на другие объекты системы.
|
|
|
Общий процесс объектно-ориентированного проектирования состоит из нескольких крупных этапов:
· определение рабочего окружения системы и разработка моделей ее использования;
· проектирование архитектуры программной системы;
· определение и идентификация основных объектов системы;
· разработка модели архитектуры комплекса программ;
· определение и документирование интерфейсов объектов.
Процесс ООП нельзя представить в виде простой схемы (как при структурном проектировании), в которой предполагается четкая последовательность этапов. Фактически все перечисленные этапы в значительной мере можно выполнять параллельно, с учетом взаимного влияния друг на друга. Как только разработана архитектура системы, определяются объекты и интерфейсы. После создания моделей объектов отдельные объекты можно переопределить, а это может привести к изменениям в архитектуре системы.
Главное преимущество ООП программных средств состоит в том, что оно упрощает задачу внесения изменений в системную архитектуру, поскольку представление состояния объекта не оказывает на нее влияния. Изменение внутренних данных объекта не должно влиять на другие объекты системы. Более того, так как объекты слабо связаны между собой, обычно новые объекты просто вставляются без значительных воздействий на остальные компоненты системы.
Основные понятия ООП включают:
· при объектно-ориентированном проектировании основные компоненты программной системы представляются как объекты со своими состояниями и операциями;
· объекты предоставляют сервисы (методы) другим объектам и создаются в реальном времени на основе определения класса объектов;
|
|
|
· объекты могут быть реализованы последовательно и параллельно, параллельный объект может быть пассивным, у которого состояние изменяется только через его интерфейс, или активным, который может изменять свое состояние без вмешательства извне;
· в процессе объектно-ориентированного проектирования возможно создание ряда различных моделей, которые можно разделить на статические (модели классов, модели обобщения, модели агрегирования) и динамические (модели последовательностей, модели конечного автомата);
· важным преимуществом объектно-ориентированного проектирования является то, что он упрощает процесс модификации системы.
Одна часть общей системы занимается сбором данных, другая обобщает данные, полученные из различных источников, третья выполняет архивирование данных и, наконец, четвертая создает результаты. Система представляет собой многоуровневую архитектуру, в которой отражены все этапы обработки данных в системе, сбор и обобщение данных, архивирование данных и создание результатов. Такая многоуровневая архитектура вполне годится для проектирования, так как каждый этап основывается только на обработке данных, выполненной на предыдущем этапе.
Использование методов ООП строго регламентировано, поэтому:
· возрастает производительность труда разработчиков благодаря переходу к высокоэффективному методу на базе предварительного анализа проекта;
· запросы и объекты реального мира проще моделируются путем концентрации внимания на классах, а не на алгоритмах их функционирования;
· компоненты системы легко изменяются и применяются повторно;
· требования проще отслеживаются;
· поддерживается эффективное прототипирование;
· разработка проекта отличается непрерывностью в представлении объектов — одни и те же типы диаграмм применяются как при анализе, так и на этапе разработки;
· работа по проектированию может осуществляться с помощью универсальных технологических инструментов.
ООП - только часть объектно-ориентированного процесса разработки системы, где на протяжении всего процесса создания ПС используется объектно-ориентированный метод. Этот подход подразумевает выполнение трех этапов:
|
|
|
· Объектно-ориентированный анализ — создание модели предметной области приложения ПС, где объекты отражают реальные объекты-сущности, а также определяются операции, выполняемые объектами;
· Объектно-ориентированное проектирование — разработка модели системы ПС и системной архитектуры с учетом системных требований, в которой определение всех объектов подчинено решению конкретной задачи;
· Объектно-ориентированное программирование — реализация архитектуры (модели) системы с помощью объектно-ориентированного языка программирования (например, Java), непосредственно выполняющего отражение определенных объектов и предоставляющего средства для определения классов объектов.
Этапы могут «перетекать» друг в друга, т.е. могут не иметь четких рамок, причем на каждом этапе обычно применяется одна и та же система нотации. Переход на следующий этап приводит к усовершенствованию и конкретизации результатов предыдущего этапа путем более детального описания определенных ранее классов объектов и определения новых классов. Так как данные скрыты внутри объектов, детальные решения о содержании данных можно отложить до этапа реализации системы. В некоторых случаях можно также не спешить с принятием решений о расположении объектов и о том, будут ли эти объекты последовательными или параллельными. Если необходимы функциональные изменения, они производятся внутри объекта, что приводит к незначительным изменениям в оставшейся внешней части его процессов. Для обновления или добавления функций, оставшиеся объекты поддерживаются с помощью интерфейсов. Объектно-ориентированное проектирование отображает предметную область задачи и ответственности системы, но задерживает определение подробностей реализации объектов, переносит их на более поздний этап разработки и минимизирует влияние изменений в функциональных требованиях.
При ООП основное внимание уделяется тому, что следует делать, каким образом добиться цели, а процесс ее достижения целиком зависит от этапа разработки. Объектная декомпозиция дает возможность создавать программные комплексы визуально меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование объектного подхода повышает уровень унификации разработки и пригодность для повторного использования не только программных компонентов, но и больших комплексов программ, что ведет к созданию унифицированной среды разработки и переходу к сборочному созданию программных продуктов. Системы зачастую получаются более компактными, чем их структурные эквиваленты, что означает не только уменьшение объема программного кода, но и удешевление проекта за счет использования компонентов из предыдущих разработок. Однако структурный подход сохраняет свою высокую значимость и широко используется на практике. Взаимосвязью между структурным и объектно-ориентированным подходами является общность ряда категорий и понятий жизненного цикла ПС.
|
|
|
Объектная декомпозиция существенно отличается от функциональной, поэтому переход на новую технологию связан как с преодолением психологических трудностей, так и с дополнительными финансовыми затратами. Кроме того, диаграммы, отражающие специфику объектного подхода, гораздо менее наглядны и хуже понимаемы непрофессионалами, объектно-ориентированный подход обычно не дает немедленной отдачи. Эффект от его применения начинает сказываться после разработки нескольких проектов и накопления повторно используемых компонентов, отражающих типовые проектные решения в данной области.
В программных средствах при ООП рекомендуется выделять три уровня:
· уровень интерфейсов, который занимается всеми взаимодействиями с другими частями системы и предоставлением внешних интерфейсов системы;
· уровень сбора данных, управляющий сбором информации из внешней среды и обобщающий данные перед отправкой их в систему построения обобщенных результатов;
· уровень объектов, в котором представлены и описаны все объекты, используемые в процессе сбора исходных данных.
В общем случае рекомендуется структурировать систему на части так, чтобы архитектура была как можно проще. Согласно хорошему практическому правилу модель архитектуры должна состоять не более чем из семи-восьми основных объектов. Перед выполнением проектирования должны быть сформированы представления относительно основных объектов проектируемой системы. Вместе с тем требуется определить и документировать все другие внешние объекты системы. Определения объектов на данном этапе проектирования отражают классы объектов, и структура системы описывается в терминах этих классов. Классы объектов, определенные ранее, получают более детальное описание, поэтому иногда приходится возвращаться на данный этап проектирования для переопределения классов. Первый этап в любом процессе проектирования состоит в выявлении взаимоотношений между проектируемым ПС и его окружением. Выявление этих взаимоотношений помогает решать, как обеспечить необходимую функциональность системы и как структурировать систему, чтобы она могла эффективно взаимодействовать со своим окружением.
|
|
|
Язык UML представляет набор разработанных инженерных задач практического профиля, которые успешно испытаны при моделировании крупных и сложных систем. Поддерживается метамодель для диаграмм классов и набор семантических и синтаксических правил, определяющих суть элементов и их отношений. Модель поддерживается большим количеством автоматизированных инструментов. Основные цели использования языка UML на этапе разработки проекта ПС:
· поддержка на уровне пользователей готового к применению, выразительного визуального языка моделирования, применяемого для разработки и обмена моделями;
· поддержка спецификаций, независимых от определенных языков программирования и процессов разработки;
· поддержка формального базиса для представления языка моделирования;
· поддержка высокоуровневых понятий, таких как компоненты, элементы сотрудничества, каркасы и шаблоны;
· интеграция наилучшего опыта.
Разработчики UML установили, что даже при использовании современных передовых технологий, при сборе требований, анализе и разработке продолжается борьба с неадекватными и постоянно изменяющимися требованиями заказчиков. Варианты использования предназначены для уточнения динамических требований и выработки более четкого представления возможных изменений в поведении системы. Они позволяют реализовать функциональные усовершенствования, которые отражаются и адресуются в организованной форме. Классы и объекты языка UML демонстрируют гибкость и управляемость при использовании статично и динамично несовершенных описаний. Для оживления общения в команде специалистов ООП позволяет реализовать в группе программистов интегрированный подход с помощью общего словаря и языка; инкапсуляция данных и алгоритмов позволяет членам команды работать над компонентами в параллельном режиме. Также в этом случае можно ограничить влияние изменчивости требований; наследственные свойства функций и атрибутов являются эффективным дополнением к функциональным возможностям.
Основные понятия и модели объектно-ориентированного проектирования
Класс представляет собой абстракцию в предметной области приложения, в общем случае выраженную существительным. Абстракция может быть концептуальной или физической: она отражает возможности системы по хранению информации о ней, по взаимодействию с ней или же оба эти фактора. Класс включает: атрибуты (данные, описывающие объект, а также тот объем информации об объекте, который хранится в системе); отношения с другими классами и операциями (поведение данного объекта, которое и описывает соответствующие ответственности) (рис.1). Диаграмма класса отражает содержимое классов (набор декларативных, статичных элементов модели), и их взаимоотношения. Класс определяет интерфейсы соответствующих экземпляров объектов (таблица 8.1).
| Имя |
| Атрибуты |
| Операции() |
Рис. 1 Изображение класса
Таблица 8.1
Основные компоненты объектно-ориентированного проектирования
| Компоненты | Содержание и функции |
| Классы | Объединения однородных объектов, имеющих одинаковые атрибуты, структуру и поведение |
| Объекты | Реальности (сущности), описываемые границами, индивидуальными состояниями и поведением |
| Атрибуты | Характеристики класса, отражающие идентификацию, состояние и поведение конкретного объекта этого класса |
| Ассоциации | Отношение между классами, отражающее связи между объектами этих классов |
| Интерфейсы | Множества операций взаимодействия между объектами |
| Сообщения | Взаимодействия объектов, имеющие стимулы, отправителя и получателя |
| Операции | Возможные воздействия объекта на другой объект того же класса с целью вызвать отклик |
| Состояние | Ситуация, в течение которой объект выполняет деятельность или ожидает события |
| Инкапсуляция | Выделение и сокрытие части информации об объекте |
| Наследование | Совместное использование атрибутов и поведения объектов в пределах иерархической структуры для построения новых классов |
| Диаграмма последовательности | Диаграмма взаимодействия объектов, упорядоченных по времени их проявления |
Классы должны отличаться идентичностью структуры, иметь четко определенные ответственности и поддерживать системные функции, взаимодействуя с другими объектами посредством сообщений. Классы описываются с помощью: атрибутов (данные, свойства), операций (службы, функции, поведение, процесс, методы), жизненного цикла разработки ПС (состояние, идентичность, независимость существования) и ассоциаций (отношения, связи, соединения). Классы имеют свойства, структуру, поведение и отличаются независимостью существования. Класс может применяться для определения подклассов, которые могут быть проиллюстрированы примерами. Однако класс нельзя проиллюстрировать непосредственно, опираясь только на него самого. Классы обладают поведением, которое также называется операцией, службой, функцией или методом. Эти термины используются в спецификации UML, где операция описывает класс и объект, а метод — реализацию операции.
Существует ряд подходов к определению классов объектов:
· использование грамматического анализа естественного языкового описания системы, объекты и атрибуты — это существительные, операции и сервисы — глаголы, такой подход реализован в иерархическом методе объектно-ориентированного проектирования, который широко используется;
· использование в качестве объектов ПС событий, объектов и ситуаций реального мира из области приложения (например, самолетов, ролевых ситуаций менеджера) для реализации таких объектов, могут потребоваться специальные структуры хранения данных (абстрактные структуры данных);
· применение подхода, основанного на сценариях, в котором по очереди определяются и анализируются различные сценарии использования системы; группа, отвечающая за анализ, должна идентифицировать необходимые объекты, атрибуты и операции; метод анализа, при котором аналитики и разработчики присваивают роли объектам, отражают эффективность подхода, основанного на сценариях.
Для описания классов можно использовать информацию, полученную из разных источников. Объекты и операции, первоначально определенные на основе неформального описания системы, могут служить отправной точкой при ООП. Затем для усовершенствования и расширения описания первоначальных объектов можно использовать дополнительную информацию, полученную из области применения ПС или анализа сценариев. Дополнительную информацию также можно получить в ходе обсуждения с пользователями разрабатываемой системы или анализа имеющихся систем.
Рис.2 Диаграмма классов
Диаграмма классов служит для представления статической структуры модели системы в терминологии классов ООП. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области см. рис. 2, такими как объекты и подсистемы, а также описывает их внутреннюю структуру (поля, методы…) и типы отношений (наследование, реализация интерфейсов …). На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.
Объект является отдельным (особенным) экземпляром класса (пример на рис.3). Объекты — это исполняемые сущности с атрибутами и сервисами класса объектов. Объекты представляют собой реализацию класса, на основе одного класса можно создать много различных объектов. Обычно при разработке объектных моделей основное внимание сосредоточено на классах объектов и их отношениях. Во всех случаях применяется общее правило, согласно которому объект инкапсулирует данные о своем внутреннем строении.
Рис.3 Пример объекта
Объект — это сущность, способная пребывать в различных состояниях и имеющая определенное множество операций. Состояние определяется как набор атрибутов объекта. Операции, связанные с объектом, предоставляют сервисы (функциональные возможности) другим объектам (клиентам) для выполнения определенных вычислений. Объекты создаются в соответствии с определением класса объектов, которое служит шаблоном для создания объектов. В него включены объявления всех атрибутов и операций, связанных с объектом данного класса. Нотация, которая используется для обозначения классов объектов, определена в UML.
Все объекты из класса имеют значения атрибутов, соответствующие атрибутам из полного дескриптора классов. Эти объекты будут также поддерживать операции, описываемые дескриптором классов. Объекты являются экземплярами класса и совместно используют свойства (атрибуты и операции) данного класса. Каждый объект отличается собственной идентичностью и имеет характерный набор значений для атрибута. Он является сущностью, инкапсулированной в двух воплощениях — состояния и поведения. Состояние представлено с помощью атрибутов и связей; операции и механизмы состояния представляют поведение. Состояние сохраняет эффекты от производимых некоей сущностью операций. Диаграммы объектов отображают объекты, их ассоциации и отношения (связи) в их развитии во времени. Объектом (если он подобен сущности) может быть:
· материальный предмет (или индивидуум);
· выполняемая роль;
· событие;
· взаимодействие (контракт);
· операционная процедура (обзор);
· организационная единица;
· место (банк);
· структура.
Объект является экземпляром, который структурирован и функционирует в соответствии со своим классом. Все объекты, порожденные одним и тем же классом, структурированы одним способом, хотя каждый из них имеет свой собственный набор связей атрибутов. Каждая связь атрибута имеет ссылку на экземпляр, обычно на значение данных. Объект может порождаться несколькими классами. В этом случае объект обладает всеми свойствами, которые объявлены во всех этих классах, как структурными, так и поведенческими. К объекту можно добавлять новые классы, а старые классы отделять. Это значит, что свойства новых классов динамически добавляются к данному объекту, а свойства, объявленные ранее в классе, удаляемые из объекта, динамически также удаляются из объекта.
Интерфейсом называется набор операций, характеризующих поведение элемента. Интерфейсы можно использовать для установки атрибута, возвращения значения атрибута и для запроса объекта с целью выполнения операции. Важной частью любого процесса ООП является специфицирование интерфейсов между различными компонентами системы. Интерфейсы необходимо определять так, чтобы объекты и другие компоненты можно было проектировать параллельно. Определив интерфейс, разработчики других объектов могут считать, что интерфейс уже реализован. Один и тот же объект может иметь несколько интерфейсов, причем каждый из них предполагает свой способ поддержки методов. Проектирование интерфейсов объектов связано со спецификацией интерфейса в объекте или группе объектов. Интерфейсы можно определить подобно диаграмме классов. По мере усложнения интерфейсов такой подход оказывается более эффективным, так как для обнаружения ошибок и противоречий в описании интерфейса можно воспользоваться средствами проверки синтаксиса языка программирования.
Сообщения — содержат объект назначения (включающий операцию, предназначенную для выполнения), название выполняемого оператора и параметры, которые необходимы для выполнения операции. Эти интерфейсы определяют средства взаимодействия между объектами. Каждому объекту пересылаются сообщения других объектов. Интерфейсы относятся к общедоступным методам, поскольку они имеют отношение к другим объектам. Полезно определять интерфейсы заранее, т.е. в начале жизненного цикла ПС. В этом случае команда программистов может быть разделена с учетом границ между объектами, что может быть предпочтительнее разделения по функциональным границам. После того как интерфейсы и набор ответственностей четко определены, они могут функционировать независимо, объединяясь лишь позднее, в цикле по тестированию модели.
Сообщение является спецификацией по транспортировке информации из одного экземпляра объекта в другой, причем ожидается, что эта деятельность имеет результат (сообщение может указывать на формирование сигнала или на вызов операции). Стимул определяет передачу информации из одного экземпляра объекта в другой, например, формирование сигнала или вызов операции; получение сообщения означает обработку стимула, который передается из экземпляра отправителя. Получатель (объект) является объектом для обработки стимула, который передается из экземпляра отправителя. Отношение представляет семантическую связь между элементами модели (примеры отношений включают ассоциации и обобщения). Ответственность является контрактом или обязательством создателя классов; для пересылки сообщения стимул передается из экземпляра объекта отправителя к экземпляру получателя. Отправитель (объект) представляет собой объект, передающий стимул в объект получателя.
Атрибут представляет собой описание набора значений, которые могут вызываться экземплярами объектов данного класса. Эта информация является для объекта внутренней и имеет следующие особенности:
· представление с помощью существительного;
· описание объекта в терминах реального времени;
· возможность служить индикатором состояния;
· обладание типом данных;
· идентичность для объектов одного класса — может отличаться по значению, но не по сути;
· возможность получения значения, определенного с помощью домена пересчета (набор определенных значений).
Операция представляет собой услугу, которая может запрашиваться из объекта для оказания влияния на его поведение. Операции можно описывать согласно следующим параметрам:
· инкапсулирование внутри объекта;
· отклик на стимул-(сообщение);
· возможность действия, выполняемого объектом с помощью другого объекта;
· возможность преобразования, которому подвергается объект.
Метод является специфической реализацией операции. Операция (метод) является средством, с помощью которого объект может реализовать свою ответственность. Операция для объекта вызывается с помощью сообщения, пересылаемого из другого объекта. Все объекты имеют методы, применяемые для их инициализации и выявления в рамках модели, а также возможности для приобретения атрибутов и избавления от них. Методы представляют собой способы взаимодействия объектов между собой, сообщений для вызова (стимулирования) определенной деятельности (поведения) в пределах объекта получателя. В ходе проведения анализа для этого к каждому объекту, имеющему ссылку на другие объекты, добавляется внешний ключ. Метод представляет реализацию для операции — указывает алгоритм или процедуру, которая ассоциируется с операцией.
Главное предназначение диаграммы состояний — описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий (рис.4).
Ассоциация отражает важное соединение (связь) между понятиями или классами (объектами). Рассматриваемое понятие включает, по крайней мере, два ассоциативных конца. Свойство множественности для концов ассоциации показывает, какое число экземпляров объектов можно ассоциировать с отдельным экземпляром класса.
Процесс инкапсуляции состоит из отделения внешних аспектов объекта от последствий внутренней реализации этого объекта. Другим термином инкапсуляции является сокрытие информации. Внешние аспекты объекта доступны другим объектам с помощью методов самого объекта, в то время как внутренние реализации этих методов скрыты от внешнего объекта, пересылающего сообщения. Инкапсуляция важна для получения потенциала или для поддержки объектно-ориентированных моделей. Поскольку подробности реализации скрыты от других объектов, они содержатся в пределах объекта. Влияние изменений, вносимых в реализацию метода, минимально для всей модели.
Рис. 4 Диаграмма состояний
Потенциально все объекты являются повторно используемыми компонентами, так как они независимо инкапсулируют данные о состоянии и операции. Архитектуру ПС можно разрабатывать на базе объектов, уже созданных в предыдущих проектах. Такой подход снижает стоимость проектирования, программирования и тестирования ПС. Кроме того, появляется возможность использовать стандартные объекты, что уменьшает риск, связанный с разработкой программного средства. Однако иногда повторное использование эффективнее всего реализовать с помощью коллекций объектов (компонентов или объектных структур), а не через отдельные объекты.
Наследование определяет совместное использование атрибутов и поведение объектов в пределах иерархической структуры (суперклассов и/или подклассов). Каждый подкласс наследует все свойства — (атрибуты и операции) суперкласса (предка) и добавляет свои собственные уникальные свойства. Класс содержит описание всех атрибутов, ассоциаций и операций, входящих в объект, что является обобщением объекта. Каждый класс имеет набор наследуемых свойств — атрибутов, операций и ассоциаций. Эти структуры данных и алгоритмы немедленно становятся доступными для подклассов наследников. Класс может иметь потомков (подклассы), где потомок является специализацией предшественника. Потомок наследует (включает в себя) эту структуру и поведение общих предшественников, при этом он способен добавлять свои собственные атрибуты и операции. Такое отношение также известно, как обобщение (генерализация). Наследование/специализация/обобщение является преимуществом метода ООП, поскольку поддерживает повторное использование классов. Благодаря применению этих понятий свойства суперклассов повторяются в каждом объекте подкласса, и таким образом поддерживается высокий фактор обновления. Изменения для атрибутов или операций немедленно наследуются всеми подклассами.
Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. Взаимодействующие объекты обмениваются между собой некоторой информацией см. рис. 5. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя.
Рис.4 Диаграмма последовательности
Модели систем, разрабатываемые при формировании требований, должны отображать реальные сущности, принадлежащие классам объектов. Все объекты связаны с различными уровнями в архитектуре системы. Конкретные решения по архитектуре системы можно принимать в процессе ее реализации. Когда связи между разработчиками требований, проектировщиками и программистами не очень тесные (например, если система проектируется в одном подразделении предприятия, а реализуется в другом), требуется более детализированная модель. Следовательно, в процессе проектирования важно решить, какие требуются модели и какой должна быть степень их детализации. Это решение зависит также от типа разрабатываемой системы.
Классы не должны содержать информацию об отдельных системных объектах. Можно разработать различные типы объектных моделей, показывающие, как классы связаны друг с другом, как объекты агрегируются из других объектов, как объекты взаимодействуют с другими объектами. Эти модели расширяют понимание разрабатываемой системы. Идентификация объектов и классов объектов считается наиболее сложной задачей в процессе объектно-ориентированной разработки систем. Определение объектов — это основа для анализа и проектирования системы.
Модель окружения системы и модель использования системы представляют собой две дополняющие друг друга модели взаимоотношений между данной системой и ее окружением. Модель окружения системы — это статическая модель, которая описывает другие системы из окружения, разрабатываемого ПС. Модель использования системы — динамическая модель, которая показывает взаимодействие данной системы со своим окружением. Модель окружения системы можно представить с помощью схемы связей, которая дает простую блок-схему общей архитектуры системы. С помощью пакетов языка UML ее можно представить в развернутом виде как совокупность подсистем. Такое представление показывает, что рабочее окружение системы находится внутри подсистемы, занимающейся сбором данных. При моделировании взаимодействия проектируемой системы с ее окружением при ООП применяется абстрактный подход, который не требует больших объемов данных для описания этих взаимодействий. Подход, применяемый в UML, состоит в том, чтобы разработать модель вариантов использования, в которой каждый вариант представляет собой определенное взаимодействие с системой.
Объектные модели, разработанные для формирования требований, могут использоваться как для представления данных, так и для процессов их обработки. В этом отношении они объединяют модели потоков данных и семантические модели данных. Они также полезны для классификации системных сущностей и могут представлять сущности, состоящие из других сущностей. Для некоторых классов систем объектные модели — естественный способ отображения реально существующих объектов, которые находятся под управлением системы. Например, для систем, обрабатывающих информацию относительно конкретных объектов (таких, как автомобили, самолеты, книги), которые имеют четко определенные атрибуты. Более абстрактные высокоуровневые сущности (например, библиотеки, медицинские регистрирующие системы или текстовые редакторы) труднее моделировать в виде классов объектов, поскольку они имеют достаточно сложный интерфейс, состоящий из независимых атрибутов и методов.
Объектные модели, разработанные во время анализа требований, упрощают переход к объектно-ориентированному проектированию и программированию. Однако конечные пользователи часто считают объектные модели неестественными и трудными для понимания. Часто они предпочитают функциональные представления процессов обработки данных. Поэтому полезно дополнить их моделями потоков данных, чтобы показать сквозную обработку данных в системе.
Модели данных — больших программных систем используют информационные базы данных. В одних случаях эта база данных существует независимо от программной системы, в других — специально создается для разрабатываемой системы. Важной частью моделирования систем является определение логической формы данных, обрабатываемых системой. Наиболее широко используемой методологией моделирования данных является моделирование типа «сущность — связь — атрибут», которое показывает структуру данных, их атрибуты и отношения между ними.
Для описания структуры обрабатываемой информации модели данных часто используются совместно с моделями потоков данных. Проекты структуры ПС представляются ориентированными графами. Они состоят из набора узлов различных типов, соединенных дугами, отображающими связи между структурными узлами. В системе проектирования присутствуют средства вывода на дисплей этого графа (т.е. структурной диаграммы) и его преобразования к виду, удобному для хранения в базе данных проектов. Система редактирования выполняет преобразования структурной диаграммы из формата базы данных в формат, позволяющий отобразить ее на экране монитора в виде блок-схемы. Информация, предоставляемая редактором другим средствам анализа проекта, должна включить логическое представление графа проекта. Эти средства работают с объектами, их логическими атрибутами и связями между ни
|
|
|
