Построение UML-модели для информационной системы "Авиа-кассы"

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

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

1. Аннотация

информационный модель касса клиентский

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

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

В качестве сред проектирования используются BPWin, Rational Rose. Для описания модели используется язык UML.

В качестве языка программирования используется Delphi.

Конечным результатом работы является клиентское приложение, модели BPWin и Rational Rose.

2. Введение

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

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

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

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

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

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

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

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

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

* SADT (Structured Analysis and Design Technique) - модели и соответствующие функциональные диаграммы;

* DFD (Data Flow Diagrams) - диаграммы потоков данных;

* ERD (Entity-Relationship Diagrams) - диаграммы «сущность-связь».

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

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

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

3.1 BPWin

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

Поддерживаемые операционные системы Windows 95, 98, NT 4.0 и Windows 2000.

3.2 Методологии моделирования, поддерживаемые BPWin

BPWin совмещает в одном инструменте средства моделирования функций (IDEF0), потоков данных (DFD) и потоков работ (IDEF3).

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

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

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

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

3.3 Диаграммы IDEF0 (A0) и дерево узлов для модели «Услуги авиа-кассы»

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

Имя модели - Услуги кассы.

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

Рис. 1. Контекстная диаграмма IDEF0 (A0) «Услуги кассы»

Рис.2. Диаграмма декомпозиции IDEF0 (A0) «Услуги кассы»

Рис.3. Диаграмма декомпозиции IDEF0 (A0) «Предоставление информации»

Рис.4. Диаграмма декомпозиции IDEF0 (A0) «Продажа билетов»

Рис.5. Диаграмма декомпозиции IDEF0 (A0) «Изменение билетов»

Рис.6. Диаграмма декомпозиции IDEF0 (A0) «Перерасчет денег»

Рис. 7. Дерево узлов

4. Построение UML-модели для информационной системы «Авиа-кассы»

4.1 Rational Rose и язык UML

Rational Rose - семейство объектно-ориентированных CASE-средств

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

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

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

разрабатываемой программной системы;

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

- заготовки текстов программ.

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

Взаимодействие с другими средствами и организация групповой работы. Для поддержки командной работы над проектом на каждой стадии жизненного цикла ПО имеется интегрированный набор продуктов Rational Suite.

Среда функционирования. Rational Rose функционирует на различных платформах: IBM PC (Windows 95/98/NT), Sun SPARCstations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

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

- диаграммы вариантов использования (use case diagrams) - для моделирования бизнес-процессов организации и требований к создаваемой системе);

- диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;

- диаграммы поведения системы (behavior diagrams)

- диаграммы взаимодействия (interaction diagrams)

-?диаграммы последовательности (sequence diagrams)

-?кооперативные диаграммы (collaboration diagrams) - для моделирования процесса обмена сообщениями между объектами;

-?диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;

- ?диаграммы деятельностей (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;

- диаграммы реализации (implementation diagrams)

-? диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;

- ?диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы.

4.2 Диаграмма вариантов использования

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

Рис. 8. Диаграмма вариантов использования для модели Услуги авиа-кассы

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

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

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

между вариантами использования и действующими лицами. Она отражает

требования к системе с точки зрения пользователя.

Такие диаграммы показывают, какие действующие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. Данная диаграмма, например, отражает взаимодействие между вариантами использования и действующими лицами системы АТМ. В сущности, диаграмма вариантов использования иллюстрирует требования к системе. В нашем примере, клиент банка инициирует 3 варианта использования: «Покупка билета», «Изменение билета», «Запрос информации».

Все варианты использования, так или иначе, связаны с внешними

требованиями к функциональности системы. Варианты использования

всегда следует анализировать вместе с действующими лицами системы,

определяя при этом реальные задачи пользователей и рассматривая

альтернативные способы решения этих задач.

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

4.3 Диаграммы последовательности

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

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

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

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

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

4.4 Кооперативные диаграммы

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

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

Рис. 10. Диаграмма кооперации для модели Услуги авиа-кассы

Как видно из рисунка, здесь представлена вся та информация, которая

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

4.5 Диаграмма классов

Диаграмма классов определяет типы классов системы и различного

рода статические связи, которые существуют между ними. На диаграммах

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

Рис. 11. Диаграмма классов для модели Услуги авиа-кассы

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

5. Разработка бизнес-модели для инфомационной системы «Авиа-кассы»

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

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



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

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

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

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

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

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

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

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

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

6. Разработка клиентской части информационной системы «Авиа-кассы»

Клиентская часть для информационной системы «Авиа-кассы» реализована на языке Delphi

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

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

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

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

Для просмотра клиентов, купивших билет, необходимо ввести пароль.

Список литературы

Майкл Богс «UML и Rational Rose»

Вендров A.M. Проектирование программного обеспечения экономических информационных систем

Вендров А.М., Малышко В.В. Объектно-ориентированный анализ и проектирование с использованием языка UML

Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. CASE-технологии: Практикум. - М.: Горячая линия-Телеком 2005.-160 с: ил.

Маклаков С.В. Моделирование бизнес-процессов с BPwin 4

Калянов. CASE-технологии. Консалтинг в автоматизации бизнес-процессов

Приложение 1

Листинг программы

unit Unit1;

interface

uses

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

Dialogs, Menus;

type

TForm1 = class(TForm)

MainMenu1: TMainMenu;

N1: TMenuItem;

N2: TMenuItem;

N5: TMenuItem;

N6: TMenuItem;

N7: TMenuItem;

N3: TMenuItem;

N4: TMenuItem;

N9: TMenuItem;

N10: TMenuItem;

procedure N2Click(Sender: TObject);

procedure N8Click(Sender: TObject);

procedure N6Click(Sender: TObject);

procedure N7Click(Sender: TObject);

procedure N9Click(Sender: TObject);

procedure N3Click(Sender: TObject);

procedure N10Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

implementation

uses Unit2, Unit3, Unit4, Unit5, Unit7, Unit8;

{$R *.dfm}

procedure TForm1.N2Click(Sender: TObject);

begin

form2.show;

end;

procedure TForm1.N8Click(Sender: TObject);

begin

form3.show;

end;

procedure TForm1.N6Click(Sender: TObject);

begin

form4.show;

end;

procedure TForm1.N7Click(Sender: TObject);

begin

form4.show;

end;

procedure TForm1.N9Click(Sender: TObject);

begin

form1.Close;

end;

procedure TForm1.N3Click(Sender: TObject);

begin

form7.show;

end;

procedure TForm1.N10Click(Sender: TObject);

begin

form8.show;

end;

end.

unit Unit2;

interface

uses

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

Dialogs, StdCtrls, DBCtrls, DB, DBTables, Grids, DBGrids, Mask;

type

TForm2 = class(TForm)

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Label4: TLabel;

Label5: TLabel;

Label6: TLabel;

Label7: TLabel;

Label9: TLabel;

Label10: TLabel;

Label11: TLabel;

Label12: TLabel;

Button2: TButton;

DataSource1: TDataSource;

Table1: TTable;

Table1Fam: TStringField;

Table1Im9: TStringField;

Table1Ot4est: TStringField;

Table1Ceria: TIntegerField;

Table1Num: TIntegerField;

Table1Propika: TStringField;

Table1Dr: TDateField;

Table1reisa: TIntegerField;

Button3: TButton;

Button4: TButton;

Table2: TTable;

DataSource2: TDataSource;

Table2reisa: TIntegerField;

Table2Data: TDateField;

Table2Napr: TStringField;

Table2Busin: TIntegerField;

Table2Econom: TIntegerField;

Edit4: TEdit;

Edit5: TEdit;

Edit6: TEdit;

Edit7: TEdit;

ComboBox1: TComboBox;

ComboBox2: TComboBox;

ComboBox4: TComboBox;

Edit1: TEdit;

Edit2: TEdit;

Edit3: TEdit;

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

procedure FormCreate(Sender: TObject);

procedure Button4Click(Sender: TObject);

procedure Button3Click(Sender: TObject);

procedure ComboBox1Change(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form2: TForm2;

implementation

uses Unit3, Unit1, unit6;

{$R *.dfm}

procedure TForm2.FormCreate(Sender: TObject);

var i:integer;

z:string;

begin

edit1.Clear;

edit2.Clear;

edit3.Clear;

edit4.Clear;

edit5.Clear;

edit6.Clear;

edit7.Clear;

combobox2.Clear;

combobox4.Clear;

combobox1.Text:=table2.Fields[2].Value ;

for i:=1 to table2.RecordCount do begin

z:=table2.Fields[2].Value;

combobox1.Items.Add(z);

table2.Next;

end;

table2.Next;

end;

procedure TForm2.Button1Click(Sender: TObject);

begin

form3.show;

end;

procedure TForm2.Button2Click(Sender: TObject);

begin

table1.Insert;

table1.Fields[0].Text:=edit1.Text;

table1.Fields[1].Text:=edit2.Text;

table1.Fields[2].Text:=edit3.Text;

table1.Fields[3].Text:=edit4.Text;

table1.Fields[4].Text:=edit5.Text;

table1.Fields[5].Text:=edit6.Text;

table1.Fields[6].Text:=edit7.Text;

table1.Fields[7].Text:=combobox2.Text;

form6.Edit1.Text:=edit1.Text;

form6.Edit2.Text:=edit2.Text;

form6.Edit3.Text:=edit3.Text;

form6.Edit4.Text:=edit4.Text;

form6.Edit5.Text:=edit5.Text;

form6.Edit6.Text:=edit6.Text;

form6.Edit7.Text:=edit7.Text;

form6.Edit8.Text:=combobox1.Text;

form6.Edit9.Text:=combobox2.Text;

form6.Edit10.Text:=combobox4.Text;

form6.Show;

form2.Close;

end;

procedure TForm2.Button4Click(Sender: TObject);

begin

form2.Close;

form1.close;

end;

procedure TForm2.Button3Click(Sender: TObject);

begin

form2.Close;

form1.show;

end;

procedure TForm2.ComboBox1Change(Sender: TObject);

var i:integer;

s,s2,s3,s4:string;

begin

s2:=combobox1.Text;

table2.First;

for i:=1 to table2.RecordCount do begin

s3:=table2.Fields[2].Value;

if s2=s3 then begin

combobox2.Clear;

combobox4.Clear;

s:=table2.Fields[0].Value;

s4:=table2.Fields[1].Value;

combobox2.Items.Add(s);

combobox4.Items.Add(s4);

end;

table2.Next;

end;

end;

end.

unit Unit3;

interface

uses

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

Dialogs, DB, DBTables, Grids, DBGrids, StdCtrls;

type

TForm3 = class(TForm)

Button4: TButton;

DataSource1: TDataSource;

Table1: TTable;

Table1Nomer: TIntegerField;

Table1A: TIntegerField;

Table1B: TIntegerField;

Table1C: TIntegerField;

Table1D: TIntegerField;

Table1E: TIntegerField;

DBGrid1: TDBGrid;

Button1: TButton;

Edit1: TEdit;

Table1q: TIntegerField;

procedure Button4Click(Sender: TObject);

procedure DBGrid1CellClick(Column: TColumn);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form3: TForm3;

i,q:integer;

implementation

uses Unit5, Unit1, Unit2;

{$R *.dfm}

procedure TForm3.Button4Click(Sender: TObject);

begin

form1.close;

end;

procedure TForm3.DBGrid1CellClick(Column: TColumn);

begin

i:= Column.Field.DataSet.FieldByName('b').AsInteger;

if i=1 then i:=0 else messagedlg('место занято',mtConfirmation,[mbok],0);

table1.Insert; Column.Field.DataSet.FieldByName('b').AsInteger:=i;

end;

end.

unit Unit4;

interface

uses

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

Dialogs, StdCtrls, Grids, DBGrids;

type

TForm4 = class(TForm)

DBGrid1: TDBGrid;

Button1: TButton;

Button2: TButton;

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form4: TForm4;

implementation

uses Unit1, Unit2;

{$R *.dfm}

procedure TForm4.Button1Click(Sender: TObject);

begin

form4.Close;

form1.show;

end;

procedure TForm4.Button2Click(Sender: TObject);

begin

form1.Close;

end;

end.

unit Unit5;

interface

uses

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

Dialogs, DB, DBTables, Grids, DBGrids, StdCtrls, Mask, DBCtrls;

type

TForm5 = class(TForm)

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Label4: TLabel;

Label5: TLabel;

Label6: TLabel;

Label7: TLabel;

Label9: TLabel;

Label10: TLabel;

Label11: TLabel;

Label12: TLabel;

Button2: TButton;

DataSource1: TDataSource;

Table1: TTable;

Table1Fam: TStringField;

Table1Im9: TStringField;

Table1Ot4est: TStringField;

Table1Ceria: TIntegerField;

Table1Num: TIntegerField;

Table1Propika: TStringField;

Table1Dr: TDateField;

Table1reisa: TIntegerField;

Button3: TButton;

Button4: TButton;

Table2: TTable;

Table2reisa: TIntegerField;

Table2Data: TDateField;

Table2Napr: TStringField;

Table2Busin: TIntegerField;

Table2Econom: TIntegerField;

DataSource2: TDataSource;

Edit1: TEdit;

Edit2: TEdit;

Edit3: TEdit;

Edit4: TEdit;

Edit5: TEdit;

Edit6: TEdit;

ComboBox1: TComboBox;

ComboBox2: TComboBox;

ComboBox4: TComboBox;

Edit7: TEdit;

procedure FormCreate(Sender: TObject);

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

procedure Button4Click(Sender: TObject);

procedure Button3Click(Sender: TObject);

procedure ComboBox1Change(Sender: TObject);

procedure FormShow(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form5: TForm5;

implementation

uses Unit3, Unit1, Unit2, Unit7;

{$R *.dfm}

procedure TForm5.FormCreate(Sender: TObject);

var i:integer;

z:string;

begin

edit1.Clear;

edit2.Clear;

edit3.Clear;

edit4.Clear;

edit6.Clear;

edit7.Clear;

combobox2.Clear;

combobox4.Clear;

combobox1.Text:=table2.Fields[2].Value;

for i:=1 to table2.RecordCount do begin

z:=table2.Fields[2].Value;

combobox1.Items.Add(z);

table2.Next;

end;

table2.Next;

end;

procedure TForm5.Button1Click(Sender: TObject);

begin

form3.show;

end;

procedure TForm5.Button2Click(Sender: TObject);

var i:integer;

s,s2,s3:string;

begin

s2:=edit5.Text;

table1.First;

for i:=1 to table1.RecordCount do begin

s3:=table1.Fields[4].Value;

if s2=s3 then begin

table1.Insert;

table1.Fields[0].Value:=edit1.Text;

table1.Fields[1].Value:=edit2.Text;

table1.Fields[2].Value:=edit3.Text;

table1.Fields[3].Value:=edit4.Text;

table1.Fields[4].Value:=edit5.Text;

table1.Fields[5].Value:=edit6.Text;

table1.Fields[6].Value:=edit7.Text;

table1.Fields[7].Value:=combobox4.Text;

end;

table1.Next;

end;

form5.Close;

end;

procedure TForm5.Button4Click(Sender: TObject);

begin

form5.Close;

form1.close;

end;

procedure TForm5.Button3Click(Sender: TObject);

begin

form5.Close;

form1.show;

end;

procedure TForm5.ComboBox1Change(Sender: TObject);

var i:integer;

s,s2,s3,s4:string;

begin

s2:=combobox1.Text;

table2.First;

for i:=1 to table2.RecordCount do begin

s3:=table2.Fields[2].Value;

if s2=s3 then begin

combobox2.Clear;

combobox4.Clear;

s:=table2.Fields[0].Value;

s4:=table2.Fields[1].Value;

combobox2.Items.Add(s4);

combobox4.Items.Add(s);

end;

table2.Next;

end;

end;

procedure TForm5.FormShow(Sender: TObject);

var s,s2,s3,s4:string;

begin

edit5.Text:=form7.Edit2.Text;

if Table1.Locate('Num', Edit5.Text, []) then begin

edit1.Text:=table1.Fields[0].Value;

edit2.Text:=table1.Fields[1].Value;

edit3.Text:=table1.Fields[2].Value;

edit4.Text:=table1.Fields[3].Value;

edit5.Text:=table1.Fields[4].Value;

edit6.Text:=table1.Fields[5].Value;

edit7.Text:=table1.Fields[6].Value;

end;

end;

end.

unit Unit6;

interface

uses

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

Dialogs, StdCtrls, ExtCtrls, Mask;

type

TForm6 = class(TForm)

Label2: TLabel;

Edit1: TEdit;

Label1: TLabel;

Label3: TLabel;

Label4: TLabel;

Label5: TLabel;

Label9: TLabel;

Label11: TLabel;

Label12: TLabel;

Label10: TLabel;

Label13: TLabel;

Label15: TLabel;

Edit2: TEdit;

Edit3: TEdit;

Edit4: TEdit;

Edit5: TEdit;

Edit6: TEdit;

Edit7: TEdit;

Edit8: TEdit;

Edit9: TEdit;

Edit10: TEdit;

Button1: TButton;

Button2: TButton;

Button3: TButton;

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

procedure Button3Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form6: TForm6;

implementation

uses Unit2, Unit1;

{$R *.dfm}

procedure TForm6.Button1Click(Sender: TObject);

begin

form6.Close;

form2.show;

end;

procedure TForm6.Button2Click(Sender: TObject);

begin

form6.Close;

form1.show;

end;

procedure TForm6.Button3Click(Sender: TObject);

begin

form1.close;

end;

end.

unit Unit7;

interface

uses

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

Dialogs, StdCtrls;

type

TForm7 = class(TForm)

Label1: TLabel;

Label7: TLabel;

Label9: TLabel;

Button1: TButton;

Edit1: TEdit;

Edit2: TEdit;

Button2: TButton;

procedure Button1Click(Sender: TObject);

procedure FormCreate(Sender: TObject);

procedure Button2Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form7: TForm7;

implementation

uses Unit2, Unit5, Unit1;

{$R *.dfm}

procedure TForm7.FormCreate(Sender: TObject);

begin

edit1.Clear;

edit2.Clear;

end;

procedure TForm7.Button1Click(Sender: TObject);

var z,x:string;

begin

z:=edit2.Text;

x:=edit1.Text;

if form2.Table1.Locate('Num', Edit2.Text, []) then begin form5.show;

end else

messagedlg('введенные вами данные не были найдены', mtConfirmation, [mbok], 0);

end;

procedure TForm7.Button2Click(Sender: TObject);

begin

form7.Close;

form1.show;

end;

end.

unit Unit8;

interface

uses

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

Dialogs, StdCtrls;

type

TForm8 = class(TForm)

Label1: TLabel;

Edit1: TEdit;

Button1: TButton;

procedure Button1Click(Sender: TObject);

procedure FormCreate(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form8: TForm8;

implementation

uses Unit9;

{$R *.dfm}

procedure TForm8.FormCreate(Sender: TObject);

begin

edit1.Clear;

end;

procedure TForm8.Button1Click(Sender: TObject);

begin

if edit1.Text='' then begin form9.show; form8.Close; end else messagedlg('введен неверный пароль',mtConfirmation,[mbok],0);;

end;

end.

unit Unit9;

interface

uses

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

Dialogs, StdCtrls, DB, DBTables, Grids, DBGrids;

type

TForm9 = class(TForm)

DataSource1: TDataSource;

DBGrid1: TDBGrid;

Table1: TTable;

Button1: TButton;

Button2: TButton;

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form9: TForm9;

implementation

uses Unit1;

{$R *.dfm}

procedure TForm9.Button1Click(Sender: TObject);

begin

form9.Close;

form1.show;

end;

procedure TForm9.Button2Click(Sender: TObject);

begin

form1.close;

end;

end.

Размещено на Allbest.ru

...