Моделирование предметной области «Управление запасами» с помощью UML (Построение объектной модели предметной области «Управление запасами» с применением языка моделирования UML)

Содержание:

Введение

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

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

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

• Изучить основные теоретические положения объектно-ориентированной методологии;
• Рассмотреть язык UML и построить объектную модель предметной области с применением данного языка.
• Объектом исследования настоящей курсовой работы является объектно–ориентированная методология проектирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стоит сразу определить базовые понятия класса и объекта:

Класс - это шаблон, описание ещё не созданного объекта. Класс содержит данные, которые описывают строение объекта и его возможности, методы работы с ним;

Объект — экземпляр класса. То, что «рождено» по «чертежу», то есть по описанию из класса. В качестве примера объекта и класса можно привести технический чертёж для изготовления детали — это класс. Выточенная же на станке по размерам и указаниям из чертежа деталь - объект.

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

На ООП-языке Java описание класса выглядит так:

// Описываем отдельный новый класс

class Circle {

// свойства класса

public double x; // абцисса центра

public double y; // ордината центра

public double y; // радиус

// методы класса

// выводит на экран параметры окружности

public void printCircle(){

System.out.println("Окружность с центром (" + x + ";" + y + ") и радиусом " + r);

}

// перемещает центр, движение окружности

public void moveCircle(double a, double b){

x = x + а;

y = y + b;

}

// масштабируем, выполняем преобразование подобия с коэффициентом k

public void zoomCircle(double k){

r = r * k;

}

}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наследование требует определения ещё одного понятия:

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

Принцип полиморфизма

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

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

На сегодняшний день самые популярные языки программирования - это объектно-ориентированные, к примеру, С++ и Java. Также существуют языки, которые не предполагают написания программных операторов, а программирование происходит в виде визуального проектирования с помощью интерфейса языка. Примером таких систем являются VisualBasic, Delphiи C++ Builder.

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

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

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

• принцип модульности
• принцип «от общего к частному»
• принцип пошаговости
• принцип структурирования

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

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

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

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

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

• объектно-ориентированный анализ (ООА),
• объектно-ориентированное проектирование (ООД),
• объектно-ориентированное программирование (ООП).

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

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

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

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

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

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

Несмотря на различия, эти методы имеют что-то общее. Их, в частности, объединяет следующее:

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

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

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

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

Так как построение моделей крайне важно при проектировании сложных систем, объектно-ориентированное проектирование предлагает богатый выбор моделей, (представлены на рис. 1.3.2)

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

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

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

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

Type

TBook = class

Public

PagesCount: integer;

Title, Author: string;

function CompareWithBook(OtherBook: TBook): integer;

procedure ShowTitle;

constructor Create(NewTitle, NewAuthor: string; NewPagesCount: integer);

end;

Глава 2. Построение объектной модели предметной области «Управление запасами» с применением языка моделирования UML

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

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

По запросу 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.

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

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

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

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

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

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

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

• Диаграммы, описывающие поведение системы:
• Диаграммы состояний (State diagrams),
• Диаграммы деятельностей (Activity diagrams),
• Диаграммы объектов (Object diagrams),
• Диаграммы последовательностей (Sequence diagrams),
• Диаграммы взаимодействия (Collaboration diagrams);
• Диаграммы, описывающие физическую реализацию системы:
• Диаграммы компонент (Component diagrams);
• Диаграммы развертывания (Deployment diagrams).

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

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

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

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

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

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

Выручка увеличилась на 9,09%, а товарные запасы на 12,12%. Соответственно, часть дохода «зависла» на складе в виде нереализованных товаров.

Just in time («точно в срок») – это наиболее распространённый и эффективный подход к ведению логистики. Его суть выражается очень просто: нужно организовать закупки товаров таким образом, чтобы:

Все материалы поступали точно в срок;

Точно в необходимом количестве, не более и не менее;

Точно в указанное место;

Точно к назначенному моменту.

При соблюдении всех факторов достигается оптимальная оборачиваемость материалов, а средства компании не простаивают в виде невостребованного товара на складах.

Исследование, проведённое Hewlett-Packard – одним из лидеров в сфере внедрения Just in Time на Западе – показывает, что концепция даёт следующие результаты:

Снижение запасов готовой продукции на 75%;

Сокращение запасов незавершённого производства на 50%;

Хранимый объём непроизводственных запасов уменьшился с расчёта на 22 дня до 1 дня;

Время реализации продукции сократилось в среднем в 2 раза;

Продолжительность производственного цикла снизилась на 50%;

Производственные издержки уменьшились на 30%, что позволяет окупить затраты на внедрение системы Just in Time в течение 5-6 месяцев.

Всё перечисленное и делает систему «Точно в срок» самой распространённой логистической концепцией в мире.

Как организовать грамотное управление запасов?

Если реализация системы Just in time пока затруднительна – или уже имеют место проблемы с избыточным наличием материальных запасов – можете воспользоваться следующими рекомендациями:

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

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

Если какие-то запасы лежат на складе больше года – или если количество материала/сырья явно превышает необходимое на один год – избавляйтесь от излишков;

Если у вашей компании широкая номенклатура материалов, начинайте работать с теми запасами, которые составляют 80% от общей стоимости остатков;

Если вам предлагают скидку за объём, всегда сравнивайте её со стоимостью задействованного капитала. Даже если речь идёт не о кредите, а просто о приобретении лишнего запаса, вы выводите из оборота собственные средства – и теряете на этом;

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

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

2.3 Построение предметной области «Управление запасами»

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

Инвентаризация означает перепись товара и по мере примерно один в течение месяцев. Для инвентаризации товара отчёт - товара, в наличие, список берётся основной БД, данные обо товаре. Затем товара на сопоставляется с из отчёта. Контроль годности - запасы имеют срок хранения и у всех В связи с определяется список срок годности истекает по определённого времени. По полученных данных мероприятия по цен на товар. Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад Проектирование бизнес процесса запасы-склад

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

Глава 3. Построение объектной модели предметной области «Управление запасами»

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

Для проведения анализа и реорганизации бизнес - процессов предназначено CASE-средство верхнего уровня All Fusion Process Modeler (BPwin), поддерживающее методологии:

▪ IDEF0 (функциональная модель);

▪ DFD (Data Flow Diagram);

▪ IDEF3 (Workflow Diagram).

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

Диаграммы потоков данных (DFD - Data flow diagram) описывают функции обработки информации, документы, объекты, а также сотрудников или отделы, которые участвуют в обработке информации. Диаграммы потоков данных обычно применяются при моделировании информационных систем, для описания документооборота и обработки информации.

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

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

Построение модели ИС начинается с описания функционирования предприятия (системы) в целом в виде контекстной диаграммы. На Рис. 4.1 представлена контекстная диаграмма ИС - «Управление торговыми запасами оптово-розничного склада»:

Рис. 9 Контекстная диаграмма IDEF0.

Управление товаром на оптово-розничном складе

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

 входа (на рис.9 это «Поставщики», «Товар» и «Первичные документы»);

 выхода (основной результат процесса - «Выходные документы», «Товар» и «Прибыль»);

 управления («Законодательство», «Нормативы складского учёта» и «Конъюнктура рынка»);

 механизмов («Материальная база», «Оборудование», «Персонал» - это ресурсы, необходимые для процесса функционирования предприятия).

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

«Законодательство», «Нормативы складского учёта» и «Конъюнктура рынка» - это правила управления процессом функционирования работы склада, а именно управления товарными запасами. Как предприятие со своими внутренними правилами, управление товаром должно выполняться согласно законодательству страны.

В оказании услуг принимает участие «Персонал» склада. Чтобы организовать хранение товара, предоставление его для продажи и получить прибыль, в деятельности управления запасами должны участвовать «Материальная база» и «Оборудование» - помещения, техника для транспортировки товара по складу, персональные компьютеры для ведения учёта товара и т.д.

После описания контекстной диаграммы проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции (Рис. 10).

Рис. 10 Диаграмма декомпозиции IDEF0. Функционирование управления запасами

Весь процесс «Функционирования управления запасами» (рис.4.3) разбивается на 4 подпроцесса:

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

«Хранение товара» представляет собой процесс сортировки закупленных товаров, их комплектацию, дробление, укрупнение партий продукции, ее стандартизацию и хранение;

«Учёт товара» - это совокупность процессов по контролю уровня товарных запасов, контролю сроков годности, инвентаризации товара, и работе с БД, содержащей все данные о продукции;

«Продажа товара» - процессы по организации продажи товара покупателям.

После дальнейшего разбиения процесса «Закупки товара» диаграммы получаем диаграмму декомпозиции второго уровня (на рис.11).

Рис. 11 Диаграмма декомпозиции IDEF0. Закупка товара

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

Выбранное предложение: Выбранное предложение при покупке товара, определённое после анализа рынка предложений данного товара.

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

Информация о приобретённом товаре: Данная информация включает сведения о купленном товаре - наименование, количество, дата изготовления, дата использования, производитель.

Кол-во: Необходимое для покупки количество товара.

Конъюнктура рынка: Занимаемое положение предприятия на рынке предоставления соответственных услуг.

Купленный товар: Доставленный товар, который прошёл проверку и готов для транспортировки на склад.

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

Наименование товара: Наименование товара, которое необходимо купить. Наименование было определено на основе данных из отчёта по продажам - количеству проданного товара и его остаткам на складе.

Нормативы складского учёта: К нормативам складского учёта относятся правила и требования ведения работы склада, примерами данных нормативов являются - правила ведения учёта товара на складе, требования к хранению товара, обязанности работников склада.

Оборудование: К оборудованию относятся, как персональные компьютеры, необходимые для занесения данных по товару, учёта товара, так и оборудование, используемое для транспортировки товара по складу.

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

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

Первичные документы: К первичным документам относятся - список товара и заявка на оформление покупаемого товара.

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

Поставщики: Список поставщиков, которые поставляют необходимый для закупки товар.

Товар: Поставленный товар, который был предварительно заказан.

После разбиения диаграммы «Хранение товара» получаем диаграмму декомпозиции второго уровня (на рис. 4.5).

Рис. 12 Диаграмма декомпозиции IDEF0. Хранение товара

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

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

На диаграмме декомпозиции в нотации IDEF3 (рис.13) иллюстрируется «Учёт товара». Учёт товара включает в себя работу с БД, контроль имеющихся товарных запасов и их срока годности.

Как только все данные по товару занесены в БД или откорректированы, выполняются последующие за перекрестком (AND) процессы:

 «Контроль сроков годности товара»;

 «Контроль уровня товарных запасов».

Эти процессы выполняются в виде запросов из БД.

Рис.13 Диаграмма декомпозиции IDEF3. Учёт товара

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

Список имеющегося в наличии товара будет использоваться при проведении инвентаризации- подсчёта товара на складе, которая проводится в назначенное время по приказу руководства данного предприятия.

После проведения инвентаризации составляется отчёт по проведённому мероприятию.

Декомпозируя процесс «Продажа товара», получаем следующую диаграмму (рис.14):

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

Отдел продаж принимает от покупателя заявку на приобретение товара;

Используя информацию об имеющемся товаре из БД, определяется наличие товара и скидка на него (скидка на товар будет в том случае, если срок годности на товар истекает через определённое ближайшее время);

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

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

При необходимости осуществляется доставка товара.

Рис.14 Диаграмма декомпозиции IDEF0. Продажа товара

Дополним cпроектированyю в BPwin ИС «Управление товаром на складе» древовидной диаграммой (Node Tree Diagrams) (рис.15).

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

Рис.15 Древовидная диаграмма

3.2 Контрольный пример реализации проекта и его описание

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

Пункт Документы предназначен для работы с новыми документами и журналами документов. При выборе Справочников становятся доступны все справочники программы для их просмотра и редактирования. Пункт Отчеты содержит все доступные отчеты.

Заполнение других справочников происходит в процессе работы.

Для ввода нового или изменения данных существующего контрагента нужно выбрать пункт меню «Справочники \ Контрагенты». В списке справочника могут быть выполнены стандартные, для 1С 8.1, действия: добавить, изменить, скопировать, удалить, отбор, сортировка, настройка списка, вывод списка на печать. Для ввода нового контрагента нужно выбрать группу в которой будет находится новый контрагент и нажать кнопку «Добавить», откроется форма для ввода данных. По бумажным документам вносится вся необходимая информация. В случае вызова данных из другого справочника, например «БанковскийСчет», в открывшейся для выбора форме можно редактировать данные этого справочника без входа в него через основное меню.

Рисунок 16 Новый контрагент

Другие справочники заполняются аналогично.

Для ввода нового документа «Поступление ТМЦ» необходимо выбрать пункт меню «Документы \ Поступление ТМЦ» или «Журналы \ Складской». В первом случае сразу откроется форма ввода нового документа, а во втором – журнал документов. В новом документе, при необходимости меняются номер и дата документа, указывается комментарий и заполняется табличная часть. Над табличной частью документа могут быть выполнены стандартные, для 1С 8.1, действия: добавить, изменить, скопировать, удалить, отбор, сортировка, настройка списка, вывод списка на печать.

Рисунок 17 Ввод нового документа «Поступление ТМЦ»

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

Рисунок 18 Отчет «Остатки»

Для окончания работы с системой необходимо выбрать пункт меню «Файл \ Выход». При этом система выполнит закрытие открытых объектов и приложение будет закрыто.

Заключение

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

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

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

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

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

Список использованной источников

1. Алгоритмические языки и программирование. Система программирования DELPHI / разраб. Т.А. Лабзина. – М.: Совр. Гум. Ун-т, 2016.
2. Ахангельский А.Я. Программирование в Delphi 7. – М.: ООО «Бином-Пресс», 2016 г. – 1152 с.
3. Голицына О.Л. и др. Языки программирования. – М.: Форум; Инфра-М, 2008.
4. Дарахвелидзе П.Г., Марков Е.П. Программирование в Delphi 7. –СПб.: БХВ-Петербург, 2016. – 784 с.
5. Семакин И.Г., Шестаков А.П. М. Основы программирования. –М.: Академия, 2017. – 438 с.
6. Сорокин А.В. Delphi. Разработка баз данных. – СПб.: Питер, 2015. – 477с.
7. Фаронов В.В. Система программирования Delphi. – СПб.: БХВ-Петербург, 2017. – 912 с.
8. Окулов, С.М. Основы программирования / С.М. Окулов. - М.: Бином. Лаборатория знаний, 2012. - 336 c.
9. Семакин, И.Г. Основы алгоритмизации и программирования: Учебник для студ. учреждений сред. проф. образования / И.Г. Семакин, А.П. Шестаков. - М.: ИЦ Академия, 2012. - 400 c.
10. Семакин, И.Г. Основы алгоритмизации и программирования. Практикум: Учебное пос. для студ. учреждений сред. проф. образования / И.Г. Семакин, А.П. Шестаков . - М.: ИЦ Академия, 2017. - 144 c.
11. Семакин, И.Г. Основы алгоритмизации и программирования: Учебник для студ. учреждений сред. проф. образования / И.Г. Семакин, А.П. Шестаков . - М.: ИЦ Академия, 2016. - 304 c.
12. Тарасов, И.А. Основы программирования Open GL / И.А. Тарасов. - М.: Горячая линия - Телеком , 2017. - 188 c.
13. Фридман, А. Основы объектно-ориентированного программирования на языке СИ++ / А. Фридман. - М.: Горячая линия -Телеком, 2016. - 234 c.
14. Фридман, А.Л. Основы объектно-ориентированного программирования на языке Си++ / А.Л. Фридман. - М.: Гор. линия-Телеком, 2017. - 234 c.
15. Черпаков, И.В. Основы программирования: Учебник и практикум для прикладного бакалавриата / И.В. Черпаков. - Люберцы: Юрайт, 2016. - 219 c.
16. Черпаков, И.В. Основы программирования: Учебник и практикум для СПО / И.В. Черпаков. - Люберцы: Юрайт, 2016. - 219 c.
17. Юдин, Д.Б. Задачи и методы линейного программирования: Математические основы и практические задачи / Д.Б. Юдин, Е.Г. Гольштейн. - М.: КД Либроком, 2017. - 320 c.

Приложение А

Код клиент-приложения главной стрницы

unit Main;

interface

uses

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,

StdCtrls, Buttons, Spin, ImgList, ComCtrls, ToolWin;

type

TMainForm = class(TForm)

PersonsList: TListBox;

GroupBox1: TGroupBox;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Label4: TLabel;

Label5: TLabel;

FNameEdit: TEdit;

LNameEdit: TEdit;

edttel: TEdit;

AgeEdit: TSpinEdit;

OpenDlg: TOpenDialog;

SaveDlg: TSaveDialog;

ToolBar1: TToolBar;

AddBtn: TToolButton;

EditBtn: TToolButton;

RestBtn: TToolButton;

DelBtn: TToolButton;

ClearBtn: TToolButton;

ToolButton6: TToolButton;

OpenBtn: TToolButton;

SaveBtn: TToolButton;

ToolButton9: TToolButton;

ImageList1: TImageList;

ComboBox1: TComboBox;

Button1: TButton;

Button2: TButton;

ComboBox2: TComboBox;

procedure ToolButton1Click(Sender: TObject);

procedure ToolButton2Click(Sender: TObject);

procedure ToolButton3Click(Sender: TObject);

procedure ToolButton4Click(Sender: TObject);

procedure ToolButton5Click(Sender: TObject);

procedure ToolButton7Click(Sender: TObject);

procedure ToolButton8Click(Sender: TObject);

procedure ToolButton9Click(Sender: TObject);

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

TPeople = class

Name: String;

Famil: String;

Age: Integer;

tel: String;

sekc: String;

constructor Create(AName: String);

end;

var

MainForm: TMainForm;

implementation

uses Unit1;

{$R *.DFM}

constructor TPeople.Create(AName: String);

begin

inherited Create;

Name:= AName;

end;

procedure TMainForm.ToolButton1Click(Sender: TObject);

begin

PersonsList.Items.AddObject('Unknown', TPeople.Create('Unknown'));

end;

procedure TMainForm.ToolButton2Click(Sender: TObject);

begin

with PersonsList, PersonsList.Items do

begin

if ItemIndex = -1

then Exit;

if not Assigned(Objects[ItemIndex])

then Objects[ItemIndex]:= TPeople.Create(Items[ItemIndex]);

with Objects[ItemIndex] as TPeople do

begin

FNameEdit.Text:= Name;

LNameEdit.Text:= Famil;

AgeEdit.Value:= Age;

edttel.Text:= tel;

Combobox1.SelText:= sekc;

end;

end;

end;

procedure TMainForm.ToolButton3Click(Sender: TObject);

begin

if PersonsList.ItemIndex = -1 then

begin

ShowMessage('Сначала выберите элемент');

Exit;

end;

with PersonsList do

with Items.Objects[ItemIndex] as TPeople do

begin

Name:= FNameEdit.Text;

Famil:= LNameEdit.Text;

Age:= AgeEdit.Value;

tel:= edttel.Text;

if

Combobox1.ItemIndex = 0 then

begin

sekc:= 'Баскетбол';

end;

if

Combobox1.ItemIndex = 1 then

begin

sekc:= 'Футбол';

end;

if

Combobox1.ItemIndex = 2 then

begin

sekc:= 'Волейбол';

end;

if

Combobox1.ItemIndex = 3 then

begin

sekc:= 'Теннис';

end;

Items[ItemIndex]:= sekc+'- '+Name+' '+Famil+' телефон:'+tel;

end;

FNameEdit.Clear;

LNameEdit.Clear;

AgeEdit.text:='0';

edttel.Clear;

ComboBox1.ItemIndex:=-1;

end;

procedure TMainForm.ToolButton4Click(Sender: TObject);

begin

with PersonsList do Items.Delete(ItemIndex);

end;

procedure TMainForm.ToolButton5Click(Sender: TObject);

begin

PersonsList.Items.Clear;

end;

procedure TMainForm.ToolButton7Click(Sender: TObject);

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;

procedure TMainForm.ToolButton8Click(Sender: TObject);

var F: TextFile;

i: Integer;

begin

try

with SaveDlg, PersonsList.Items do

begin

if Not Execute then Exit;

SaveToFile(FileName);

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

Rewrite(F);

for i:= 0 to Count - 1 do

if Objects[i] <> Nil then

begin

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

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

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

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

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

end;

CloseFile(F);

end;

except

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

end;

end;

procedure TMainForm.ToolButton9Click(Sender: TObject);

begin

Close;

end;

procedure TMainForm.Button1Click(Sender: TObject);

begin

form1.Show;

end;

procedure TMainForm.Button2Click(Sender: TObject);

var

I,J:integer;

F: TextFile;

begin

if PersonsList.ItemIndex = -1 then

begin

ShowMessage('Сначала выберите элемент');

Exit;

end;

with PersonsList do

with Items.Objects[ItemIndex] as TPeople do

begin

//PersonsList.ItemIndex:=j;

begin

if

Combobox2.ItemIndex = 0 then

begin

i:= PersonsList.Items.Count;

{программа}

// for i:=0 to PersonsList.Count -1 do

//for j:= i to PersonsList.Count -1 do

//программа ломается while i>PersonsList.ItemIndex do

// Виснет repeat

if Sekc = 'Баскетбол' then ItemIndex:=ItemIndex

else

Items.Delete(ItemIndex);

ItemIndex:=ItemIndex+1;

{repeat

Button2.Click;

until i<=ItemIndex; }

end;

end;

if

Combobox2.ItemIndex = 1 then

begin

if Sekc = 'Футбол' then ItemIndex:=ItemIndex

else

Items.Delete(ItemIndex);

ItemIndex:=ItemIndex+1;

end;

if

Combobox2.ItemIndex = 2 then

begin

if Sekc = 'Волейбол' then ItemIndex:=ItemIndex

else

Items.Delete(ItemIndex);

ItemIndex:=ItemIndex+1;

end;

if

Combobox2.ItemIndex = 3 then

begin

if Sekc = 'Теннис' then ItemIndex:=ItemIndex

else

Items.Delete(ItemIndex);

ItemIndex:=ItemIndex+1;

end;

if

Combobox2.ItemIndex = 4 then

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;

end;

end;

end.