Построение объектной модели

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

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

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

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

 

2.6. Интерфейсы и окружения

 

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

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

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

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

 

 

3. Построение объектной модели информационной системы «Автосервис».

В качестве примера будет рассмотрена задача о построении объектной модели информационной системы «Автосервис».

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

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

  Подготовка словаря данных

Приведем часть  словаря данных, содержащую определения  классов, используемых в проекте.

Клиент —  общее название субъекта, использующего услуги автосервиса.

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

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

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

Определение зависимостей

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

Глагольные  обороты (явные и неявные):

 Мастер  - приемщик формирует заказ от клиента

 Мастер  - приемщик выдает задание начальнику смены

 Мастер  - приемщик формирует отчеты

 Начальник  смены раздает задания механикам  (различных участков)

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

 

 

 

 

 

 

 

 

 

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

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

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

Диаграмма классов  – определяет структуру предметной области в виде набора классов, находящихся между собой в определенных отношениях.

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

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

Обычно для  описания системы создают несколько  диаграмм классов.

На одних  показывают некоторое подмножество классов и отношения между классами подмножества.

На других отображают то же подмножество, но вместе с атрибутами и операциями классов.

Третьи соответствуют  только пакетам классов и отношениям между ними. По умолчанию существует одна диаграмма классов, называемая Главной На этой диаграмме показывают пакеты классов модели. Внутри каждого пакета также имеется "Главная диаграмма", включающая в себя все классы этого пакета (рисунок 5.1).

 вулканизаторщик,  аккумуляторщик, маляр

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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

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

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

Пример диаграммы последовательности для нашей задачи приведен на рис.

                                                                                                                                                                                              

                                                                                                                   

                                                                                                    

                                                                                                      

                                                                                                            

                                                                                                          

                                                                                    

                                                                                        

                                                                                       

 

 

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

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

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