Построение объектной модели. Объекты характеризуются атрибутами

Построение объектной модели предметной области "организация процессов спортивного клуба" с применением языка моделирования UML

1. ОСНОВНЫЕ ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ МЕТОДОЛОГИИ

1.1 Основные понятия объектно-ориентированного подхода

предметный язык программирование модель

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

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

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

Важными понятиями программирования являются процедурно-ориентированное программирование и объектно-ориентированное программирование.

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

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

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

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

Между ООП и процедурно-ориентированным программированием существуют два важных различия:

1. В ООП программист сначала выделяет классы из описания предметной области, затем строится объектная модель решения задачи и только после этого переходит к анализу их методов и свойств.

2. Методы и свойства ассоциируются с классом, предназначенным для выполнения соответствующих операций.

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

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

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

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

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

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

В основе объектно-ориентированной технологии программирования лежат «три кита»: инкапсуляция, наследование и полиморфизм.

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

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

Полиморфизм (polymorphism) («много форм») - возможность использовать одинаковые выражения для обозначения разных операций, возможность классов-наследников по-разному реализовывать метод, описанный для класса-предка, т.е. возможность во время выполнения программы с помощью одного и того же имени выполнять разные действия или обращаться к объектам разного типа. Полиморфизм реализуется через переопределение метода в классах-наследниках (метод имеет одно имя и одинаковые параметры, но работает по-разному) - это механизм виртуальных методов через динамическое связывание (dynamic binding). Также полиморфизм реализуется как «перегрузка» методов (метод имеет одно имя и разные параметры) - это, например, использование знака + для обозначения сложения в классе вещественных или целых чисел и классе строк: похожие сообщения дают совершенно разные результаты. Полиморфизм обеспечивает возможность абстрагирования общих свойств.

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

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

Типизация - это способ защититься от использования объектов одного класса вместо другого, или по крайней мере управлять таким использованием.

Параллелизм - это свойство, отличающее активные объекты от пассивных.

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

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

Таким образом, в процессе разработки объектно-ориентированных программ необходимо:

1. определить множество образующих ее классов объектов (декомпозиция);

2. для каждого класса объектов задать набор необходимых данных (полей);

3. для каждого класса объектов задать набор действий (методов), выполняемых объектами;

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

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

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

Членами класса могут быть:

1. поля, используемые для хранения данных;

2. свойства, как средства обращения к закрытым полям;

3. методы, задающие функциональность объектов;

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

Автоматизация решения задач управления деятельностью ООО "Мир Компьютеров"

Построение концептуальной модели информационной системы МУП "РПКХБ"

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

Построение объектной модели предметной области "организация процессов спортивного клуба" с применением языка моделирования UML

Программирование в Delphi математических процессов

Проект системы учета заказов на грузоперевозку автотранспортной компании "ТрансАвто"

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

Проектирование информационных систем средствами BPwin

Разработка информационной системы автоматизации рабочего места библиотекаря

Разработка объектно-ориентированной модели информационной подсистемы для деканата ВУЗа (учет успеваемости студентов)

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

Разработка объектно-ориентированной модели информационной системы учебной библиотеки

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

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

Разработка схемы базы данных задачи "Учет фонда библиотеки" для Харьковского колледжа текстиля и дизайна

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

ВВЕДЕНИЕ

1.1 Основные теоретические положения объектно-ориентированной технологии программирования; Основные понятия объектно-ориентированного подхода

1.2 Понятие объект

2. построение объектной модели предметной области «организация процессов спортивного клуба» с применением языка моделирования uml

2.1 Характеристика языка моделирования UML

2.1.1 Краткая история UML

2.1.2 Язык UML

2.1.3 Словарь UML

2.1.4 Представление управления моделью.

3.1 Описание структуры приложения

ЗАКЛЮЧЕНИЕ

СПИСОК ИСТОЧНИКОВ

Приложение А

ВВЕДЕНИЕ

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

При использовании ЭВМ этот процесс становится гораздо более точным и быстрым, лишенным множества накладок, которые возникают при его организации вручную.

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

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

Целью данного исследования, является изучение объектно-ориентированной методологии и технологии программирования на примере языка Object Pascal, методов и инструментов построения объектных моделей предметных областей, применение полученных знаний для построения объектной модели предметной области «Организация работы спортивного клуба».

Для достижения цели данного исследования поставлены следующие задачи:

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

· Рассмотреть язык UML и построить объектную модель предметной области с применением данного языка;

· Разработать приложение, использующее набор классов для представления информации о спортсменах.

Объектом исследования настоящей курсовой работы является объектно-ориентированная методология проектирования.

Предметом исследования настоящего исследования являются объектная модель предметной области «Организация работы спортивного клуба» и её основные свойства.

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

На этапе анализа предметной области и проектирования структуры приложения необходимо построить UML диаграмму классов.

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

· Описательный метод применяется при изложении теоретических аспектов проблемы и краткой характеристике объекта исследования;

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

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

1. ОСНОВНЫЕ ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ МЕТОДОЛОГИИ

1.1 Основные понятия объектно-ориентированного подхода

предметный язык программирование модель

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

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

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

Важными понятиями программирования являются процедурно-ориентированное программирование и объектно-ориентированное программирование.

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

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

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

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

Между ООП и процедурно-ориентированным программированием существуют два важных различия:

1. В ООП программист сначала выделяет классы из описания предметной области, затем строится объектная модель решения задачи и только после этого переходит к анализу их методов и свойств.

2. Методы и свойства ассоциируются с классом, предназначенным для выполнения соответствующих операций.

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

В основе объектно-ориентированной технологии программирования лежат «три кита»: инкапсуляция, наследование и полиморфизм.

Типизация - это способ защититься от использования объектов одного класса вместо другого, или по крайней мере управлять таким использованием.

Параллелизм - это свойство, отличающее активные объекты от пассивных.

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

Таким образом, в процессе разработки объектно-ориентированных программ необходимо:

1. определить множество образующих ее классов объектов (декомпозиция);

2. для каждого класса объектов задать набор необходимых данных (полей);

3. для каждого класса объектов задать набор действий (методов), выполняемых объектами;

Членами класса могут быть:

1. поля, используемые для хранения данных;

2. свойства, как средства обращения к закрытым полям;

3. методы, задающие функциональность объектов;

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

1.2 Понятие объект

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

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

1. методом - это функция или процедура, которая реализует возможные с объектом действия;

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

3. состоянием - каждый объект всегда находится в определенном состоянии, которое характеризуется набором свойств объекта. Под воздействием событий объект переходит в другие состояния. При этом объект может сам генерировать события при переходе в другое состояние;

4. свойством - признак, некоторое отдельное качество (параметр) объекта.

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

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

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

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

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

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

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

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

Рис.1.2.1 Семантика.

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

Таким образом, объектно-ориентированный подход помогает справиться с такими сложными проблемами, как

· уменьшение сложности программного обеспечения;

· повышение надежности программного обеспечения;

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

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

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

1.3 Средства реализации объектно-ориентированной технологии программирования

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

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

· принцип модульности

· принцип «от общего к частному»

· принцип пошаговости

· принцип структурирования

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

1. размер модуля должен быть ограничен;

2. модуль должен выполнять логически целостное и завершенное действие;

3. модуль должен быть универсальным, то есть по возможности параметризованным: все изменяемые характеристики выполняемого действия должны передаваться через параметры;

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

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

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

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

· простой последовательности действий;

· конструкции выбора или оператора if;

· конструкции повторения или цикла.

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

· первоначально программа формулируется в виде некоторого неформального действия на естественном языке;

· первоначально определяются входные параметры и результат действия;

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

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

· необходимые структуры данных проектируются одновременно с детализацией программы.

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

То, что этот принцип выделен отдельно, говорит о необходимости предотвратить соблазн детализации программы сразу от начала до конца и развивать умение выделять и сосредоточивать внимание на главных, а не второстепенных деталях алгоритма.

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

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

Структурное программирование - модульное нисходящее пошаговое проектирование алгоритма и структур данных.

Объектно-ориентированный подход к программированию включает в себя 3 основные компоненты:

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

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

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

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

· удовлетворяет заданным (возможно, неформальным) функциональным спецификациям;

· согласована с ограничениями, накладываемыми оборудованием;

· удовлетворяет явным и неявным требованиям по эксплуатационным качествам и потреблению ресурсов;

· удовлетворяет явным и неявным критериям дизайна продукта;

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

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

Программа - это числовая модель проектируемой системы.(рис. 1.3.1.)

Рис. 1.3.1. Структура программы.

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

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

· условные обозначения - язык для описания каждой модели;

· процесс - правила проектирования модели;

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

Хороший метод проектирования базируется на прочной теоретической основе и при этом дает программисту известную степень свободы самовыражения.

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

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

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

Рис. 1.3.2 Объектно-ориентированные модели.

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

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

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

PagesCount: integer;

function CompareWithBook(OtherBook: TBook): integer;

procedure ShowTitle;

constructor Create(NewTitle, New

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

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

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

2. ПОСТРОЕНИЕ ОБЪЕКТНОЙ МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ «ОРГАНИЗАЦИЯ ПРОЦЕССОВ СПОРТИВНОГО КЛУБА» С ПРИМЕНЕНИЕМ ЯЗЫКА МОДЕЛИРОВАНИЯ UML

2.1 Понятие языка UML

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

2.1.1 Краткая история UML

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

По запросу Object Management Group (OMG) - организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных объектно-ориентированных методов - Г.Бучем, Д.Рамбо и А.Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта.

На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments и Unisys. Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе 1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики. UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005.

Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development -- MDD. Последняя версия UML 2.4.1 опубликована в августе 2011 года. UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2.

2.1.2 Язык UML

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

Следует подчеркнуть, что UML - это именно язык, а не метод. Он объясняет, из каких элементов создавать модели и как их читать, но ничего не говорит о том, какие модели и в каких случаях следует разрабатывать. Чтобы создать метод на базе UML, надо дополнить его описанием процесса разработки ПС. Примером такого процесса является Rational Unified Process, который будет рассматриваться в последующих статьях.

2.1.3 Словарь UML

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

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

Отношения показывают различные связи между сущностями. В UML определены следующие типы отношений:

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

· Ассоциация - это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности. Ассоциации служат для осуществления навигации между объектами. Например, ассоциация между классами «Заказ» и «Товар» может быть использована для нахождения всех товаров, указанных в конкретном заказе - с одной стороны, или для нахождения всех заказов в которых есть данный товар, - с другой. Понятно, что в соответствующих программах должен быть реализован механизм, обеспечивающий такую навигацию. Если требуется навигация только в одном направлении, оно показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование - отношение вида «целое» - «часть». Графически оно выделяется с помощью ромбика на конце около сущности-целого.

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

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

Диаграммы. В UML предусмотрены следующие диаграммы:

· Диаграммы, описывающие поведение системы:

· Диаграммы состояний (State diagrams),

· Диаграммы деятельностей (Activity diagrams),

· Диаграммы объектов (Object diagrams),

· Диаграммы последовательностей (Sequence diagrams),

· Диаграммы взаимодействия (Collaboration diagrams);

· Диаграммы, описывающие физическую реализацию системы:

· Диаграммы компонент (Component diagrams);

· Диаграммы развертывания (Deployment diagrams).

2.1.4 Структура управления моделью

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

UML обеспечивает.

· иерархическое описание сложной системы путем выделения пакетов;

· формализацию функциональных требований к системе с помощью аппарата вариантов использования;

· детализацию требований к системе путем построения диаграмм деятельностей и сценариев;

· выделение классов данных и построение концептуальной модели данных в виде диаграмм классов;

· выделение классов, описывающих пользовательский интерфейс, и создание схемы навигации экранов;

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

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

· описание программных компонент и их взаимодействия через интерфейсы;

· описание физической архитектуры системы.

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

2.2 Описание функционирования предметной области «Организация работы спортивного клуба»

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

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

Спортивный клуб решает следующие задачи:

· вовлечение молодежи и членов их семей в систематические занятия физической культурой и спортом;

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

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

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

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

Спортивный клуб выполняет следующие функции:

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

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

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

· всемерно развивает общественные начала в массовой физкультурно-оздоровительной и спортивной работе;

· оказывает помощь общеобразовательным школам, колледжам в организации массовой оздоровительной, физкультурной и спортивной работы;

· организует учебно-тренировочный процесс в спортивных секциях (сборных командах);

· разрабатывает и реализует календарные планы массовых оздоровительных, физкультурных и спортивных мероприятий, обеспечивает безопасность их проведения;

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

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

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

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

· может иметь флаг, эмблему, спортивную форму, штамп, бланк;

· проводит массовые соревнования, спартакиады (универсиады), учебно-тренировочные сборы;

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

· выдает соответствующие удостоверения (значки) членам сборных команд вуза;

2.3 Построение диаграммы классов предметной области «Организация процессов спортивного клуба»

В спортивном клубе работают четыре сеции на базе клуба:

· Баскетбол

· Волейбол

· Теннис.

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

· Данные о спортсменах заносятся в таблицу с указанием 5 полей: Фамилия, Имя, Возраст, Телефон, Секция.

· Спортсмены распределяются по секциям, в которые подана заявка.

· Родителям спортсменов предоставляется расписание секций спортивного клуба.

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

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

Для наглядного представления процессов работы спортивного клуба была построена UML диаграмма (Рис 2.3.1).

Рис. 2.3.1 Объектно-ориентированная модель спортивного клуба.

3. ПОСТРОЕНИЕ ОБЪЕКТНОЙ МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ «ОРГАНИЗАЦИЯ РАБОТЫ СПОРТИВНОГО КЛУБА» С ПРИМЕНЕНИЕМ ВИЗУАЛЬНОЙ СРЕДЫ ПРОГРАММИРОВАНИЯ DELPHI

3.1 Описание структуры приложения

Данное приложение входит в состав пакета Sport. Оно состоит из класса: class TPeople.

Класс «TPeople» позволяет создавать и накапливать информацию о детях, занимающихся в данном спортивном клубе, который получил название «Огонек». Он имеет пять полей: Имя задается строкой (string) «Name»; Фамилия задается строкой (string) «Famil»; Возраст хранится в числовой переменной (int) «Age»; телефон задается строкой (string) «Tel»; Секция в которой занимается спортсмен задается строкой (string) «Sekc».

TPeople = class

Name: String;

Famil: String;

Age: Integer;

tel: String;

sekc: String;

constructor Create(AName: String);

end;

При этом ввод полей используется двумя способами:

Загрузка значения из сохраненного файла с расширением LST. (Рис 3.1.1.)

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

var F: TextFile;

i: Integer;

begin

try

with OpenDlg, PersonsList.Items do

begin

if Not Execute then Exit;

LoadFromFile(FileName);

AssignFile(F, Copy(FileName,1,Length(FileName)-4)+".lso");

Reset(F);

i:= 0;

while Not EOF(F) do

begin

Objects[i] := TPeople.Create("");

Readln(F, (Objects[i] as TPeople).Name);

Readln(F, (Objects[i] as TPeople).Famil);

Readln(F, (Objects[i] as TPeople).Age);

Readln(F, (Objects[i] as TPeople).tel);

Readln(F, (Objects[i] as TPeople).sekc);

Inc(i);

end;

CloseFile(F);

end;

except

on E: EFOpenError do ShowMessage("Ошибка открытия файла");

end;end;

Рис. 3.1.1 Загрузка файла.

Вторым методом заполнения таблицы является ввод с помощью компонентов Edit.(Рис. 3.1.2.)

Рис. 3.1.2 Заполнение таблицы путем компонента Edit.

Причем значение поля «Секция» выбирается из значений компонента Combobox и присваивается строке «Sekc». (Рис.3.1.3)

Рис. 3.1.3 Компонент Combobox.

Введенные значения могут корректироваться путем выбора нужного значения и нажатия кнопки «Изменить» (Рис. 3.1.4)

Рис. 3.1.4 Изменение значений.

В программе предусмотрено удаление значение путем удаление одной записи (Рис. 3.1.5) и удаления всех записей (Рис. 3.1.6).

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

Рис. 3.1.5 Удаление одной записи.

Для того, чтобы очистить все записи нужно нажать кнопку «Очистить».

Рис. 3.1.6 Кнопка «Очистить».

Оба способа удаления осуществлены следующими методами:

procedure TMainForm.ToolButton4Click(Sender: TObject);

begin

with PersonsList do Items.Delete(ItemIndex);

end;

procedure TMainForm.ToolButton5Click(Sender: TObject);

begin

PersonsList.Items.Clear;

end;

После заполнения таблицы спортсменов появляется необходимость сохранить ее для дальнейшего использования. Это осуществляется нажатием кнопки «Сохранить» (Рис. 3.1.7). После нажатия этой кнопки осуществляется открытие диалогового окна, куда указывается папка хранения файла и его название. (Рис. 3.1.8).

Подобные документы

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

курсовая работа , добавлен 01.06.2009

Разработка объектно-ориентированной подсистемы складского учета для фирмы "КавказЮгАвто". Краткая характеристика предметной области. Построение диаграмм размещения, прецедентов, последовательности, компонентов и классов. Генерация программного кода C++.

курсовая работа , добавлен 26.06.2011

Основные элементы объектной модели. Сущность и преимущества объектно-ориентированного подхода, понятие объекта и класса. Унифицированный язык моделирования UML. Диаграммы классов и взаимодействия: назначение, построение и примеры использования.

реферат , добавлен 09.06.2009

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

курсовая работа , добавлен 15.06.2014

Актуальность и практическая значимость программных систем компьютерного клуба. Анализ предметной области. Диаграмма классов, физическая модель системы. Разработка визуального проекта ИС, с использованием языка UML2.0 и среды моделирования Microsoft Visio.

курсовая работа , добавлен 21.06.2014

Анализ предметной области "Конкурс поэтов" на основе объектно-ориентированного подхода. Разработка оконного приложения и описание информационной модели предметной области. Описание разработанных процедур С++ и результатов тестирования приложения.

курсовая работа , добавлен 18.06.2013

Функциональное моделирование IDEF0. Описание всех процессов работы отдела техподдержки. Декомпозиция контекстной диаграммы и основных процессов. Построение модели процессов предметной области в стандарте IDEF1Х. Интерфейс программы контроля трафика.

отчет по практике , добавлен 22.11.2014

Построение инфологической модели предметной области методом ER- диаграммы. Создание отношений БД с помощью языка SQL. Заполнение базы данных. Создание запросов к базе данных компьютерного клуба. Создание отчета с помощью Microsoft Word и Microsoft Excel.

курсовая работа , добавлен 26.02.2009

Краткая характеристика предметной области. Создание диаграммы прецедентов, последовательности, сотрудничества, классов, размещения, компонентов. Добавление деталей к описаниям операций и определение атрибутов КЛАССОВ. Генерация программного кода C++.

курсовая работа , добавлен 29.06.2011

Общая характеристика склада как объекта хозяйственной деятельности. Создание диаграммы прецедентов и последовательности. Построение корпоративной диаграммы сотрудничества. Предназначение диаграммы классов и компонентов. Генерация программного кода C++.

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Атрибут объекта - это значение, характеризующее объект в его классе. Примеры атрибутов: марка, год выпуска, цвет (атрибуты объектов класса автомобиль) и т.д.

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

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

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

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

Дискриминатор - это атрибут типа "перечисление", показывающий, по какому из свойств объектов сделано данное обобщение.

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

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

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

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

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

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

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

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

Переопределение может преследовать одну из следующих целей:

расширение: новая операция расширяет унаследованную операцию, учитывая влияние атрибутов подкласса;

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

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

удобство.

Целесообразно придерживаться следующих семантических правил наследования:

все операции-запросы (операции, которые используют значения атрибутов, но не изменяют их) должны наследоваться всеми подклассами;

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

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

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

унаследованные операции можно уточнять, добавляя дополнительные действия.

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

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

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

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

Метаданными называются данные, описывающие другие данные. Например, определение класса - это метаданные, так как класс описывает другие данные - объекты этого класса. Модели являются метаданными, так как они описывают моделируемые объекты. Еще одним примером метаданных является абстрактный класс.

Актеры – это роли, исполняемые сущностями, непосредственно взаимодействующими с системой.

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

Мне очень понравилось описание понятия «актер» в работе Джима Арлоу и Айла Нейштадта «UML 2 и Унифицированный процесс»: «Для понимания актеров важно понимать концепцию ролей. Роль можно рассматривать как шляпу, которую надевают в определенной ситуации.» (стр 92).

Когда известны основные понятия, можно рассматривать построение самой модели

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

Определение классов

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

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

избыточные классы: если два или несколько классов выражают одинаковую информацию, следует сохранить только один из них;

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

нечетко определенные (с точки зрения рассматриваемой проблемы) классы;

атрибуты: некоторым существительным больше соответствуют не классы, а атрибуты; такие существительные, как правило, описывают свойства объектов (например, имя, возраст, вес, адрес и т.п.);

операции: некоторым существительным больше соответствуют не классы, а имена операций (например, телефонный_вызов вряд ли означает какой-либо класс);

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

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

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

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

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

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

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

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

Затем следует убрать ненужные или неправильные зависимости, используя следующие критерии:

зависимости между исключенными классами должны быть исключены, либо переформулированы в терминах оставшихся классов;

нерелевантные зависимости и зависимости, связанные с реализацией, должны быть исключены;

действия: зависимость должна описывать структурные свойства прикладной области, а не малосущественные события;

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

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

Удалив избыточные зависимости, нужно уточнить семантику оставшихся зависимостей следующим образом:

неверно названные зависимости: их следует переименовать, чтобы смысл их стал понятен;

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

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

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

неучтенные зависимости должны быть выявлены и добавлены в модель.

2.4. Уточнение атрибутов

На следующем этапе уточняется система атрибутов: корректируются атрибуты классов, вводятся, в случае необходимости, новые атрибуты. Атрибуты выражают свойства объектов рассматриваемого класса, либо определяют их текущее состояние.

Атрибуты обычно соответствуют существительным; например цвет_автомобиля (свойство объекта), позиция_курсора (состояние объекта). Атрибуты, как правило, слабо влияют на структуру объектной модели.

Наряду с атрибутами объектов необходимо ввести и атрибуты зависимостей между классами (связей между объектами).

При уточнении атрибутов руководствуются следующими критериями:

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

Квалификаторы. Если значение атрибута зависит от конкретного контекста, его следует сделать квалификатором.

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

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

Атрибуты связей. Если некоторое свойство характеризует не объект сам по себе, а его связь с другим объектом (объектами), то это атрибут связи, а не атрибут объекта.

Внутренние значения. Атрибуты, определяющие лишь внутреннее состояние объекта, незаметное вне объекта, следует исключить из рассмотрения.

Несущественные детали. Атрибуты, не влияющие на выполнение большей части операций, рекомендуется опустить.

2.5. Выделение подсистем

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

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

и т.д.................

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

РАБОТА ВЫПОЛНЯЕТСЯ в StarUML

Время выполнения:

2 – 3 занятия

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

ПРИМЕР ЗАДАНИЯ:

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

- информация о студентах

o Ф.И.О.,

o адрес,

o паспортные данные,

o номер зачетки,

o дата рождения,

o группа);

- информация о специальностях

o наименование специальности,

o шифр;

- информация о группах

o специальность,

o год поступления,

o номер группы.

Обеспечить выдачу документа “Список группы”, содержащего поля:

· порядковый номер,

· Ф.И.О.,

· номер зачетки.

Порядок выполнения работы

Построение объектной модели выполняется в пакете Rational Rose. Для этого создадим пустой проект. Начинать выполнение работы следует с диаграммы прецедентов. Ее строят в области Main секции Use Case View, как показано на рис.9.

Перед началом построения диаграммы необходимо определить роли пользователей системы (актеров) и их функции (прецеденты). В нашем случае с системой работают два актера – это «Работник учебного отдела» и «Работник деканата». В функции работника учебного отдела входит ведение списка специальностей (под ведением списка мы будем понимать добавление записей, их корректировку и удаление). Функции работника деканата включают в себя ведение списка студентов и ведение списка групп.

Построенная диаграмма изображена на рис. 10.

Далее в секции Logical View следует создать две диаграммы классов. Для этого можно создать два пакета. Первая диаграмма должна содержать классы интерфейса проектируемого приложения (см. рис. 11). На данном рисунке в классах «Список групп» и «Список студентов» опущены операции добавления, изменения и удаления во избежание загромождения рисунка. Список группы (нижний класс) является выходным документом (перед ним следует класс «Выбор группы», т.к. необходимо получить список студентов определенной группы). Вторая диаграмма – сущности базы данных (см. рис. 12).

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

Следует проставить ключевые поля и установить связь (из контекстного меню стрелки - Multiplicity).

Следующий этап построения объектной модели – создание диаграмм последовательностей. Диаграммы последовательностей создаются для каждого прецедента на диаграмме прецедентов. Чтобы добавить диаграмму последовательностей к прецеденту необходимо выбрать его в дереве и вызвать на нем контекстное меню (NewàSequence Diagram) как показано на рис. 13.

Пример диаграммы последовательностей для прецедента «Ведение списка специальностей» представлен на рис. 14.

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

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

Модели помогают:

Проверить работоспособность разрабатываемой системы на ранних этапах ее разработки;

Общаться с заказчиком системы, уточняя его требования к системе;

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

В настоящее время существует несколько технологий объектно-ориентированной разработки прикладных программных систем, в основе которых лежит построение и интерпретация на компьютере моделей этих систем. В данном проекте применена одна из них - OMT (Object Modeling Techniques). Кроме того построена диаграмма объектной модели на языке UML.

Определение классов объектной модели

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

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

В результате получаем следующий список возможных имён классов:

Другой proxy;

Документ;

Удалённый Web сервер;

Конфигурация;

Информация о документе;

Информация об удалённом Web сервере;

Заголовок запроса;

Заголовок ответа.