Жизненный цикл разработки информационной системы

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

1. Исследование и анализ. Главной задачей информационной системы является удовлетворение информационных потребностей бизнеса. Поэтому на первом этапе важно разобраться как протекают бизнес-процессы внутри организации, на какие потоки информации они опираются. Чаще всего это происходит в виде интервью с представителями разных отделов предприятия. На этом этапе важно получить исчерпывающую картину работы предприятия в формате который будет с одной стороны понятен разработчикам, а с другой - представителям бизнеса. На этом этапе нам на помощь могут прийти методологии IDEF0 и DFD, которые будут рассмотрены в этой лекции.
2. Прототипирование . На этом этапе моделируется структура информационной системы, структура хранилищ данных, пользовательские интерфейсы.
3. Построение и документирование. На этом этапе происходит согласование прототипа системы с требованиями заказчика. Поведение информационной системы детально документируется, для того чтобы в дальнейшем можно было сравнить ожидаемое и полученное поведение системы.
4. Внедрение. На этом этапе выполняется верификация соответствия реального и ожидаемого поведения системы. Зачастую это происходит в виде пиремо-сдаточных испытаний.
5. Использование. Этот этап разработки информационной системы рассматривается дисциплиной Техническая поддержка программных решений (Technical Solution Support). Он характеризуется гарантийным и послегарантийным обслуживанием информационной системы. Примером такого обслуживания может быть исправление ошибок, внесение новых функций, повышение производительности, обучение персонала и прочее.

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

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

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

При этом «концептуальная модель» это:

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

Методология IDEF0

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

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

IDEF0 - это подмножество SADT (Structured Analisys and Design Technique). Методология SADT разрабатывалась Дугласом Т. Россом в 1969-1973 годах и изначально применялась для проектирования систем общего назначения. В данной методологии ключевым является в какую из сторон процесса направлен поток управления.

Поясним суть методологии IDEF0 на примере производства товара. Процесс производства условно изображен на слайде.

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

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

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

Правила интерпретации модели:

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

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

Анализ объекта на основе построения его IDEF0-модели является этапом, который должен предварять разработку информационной системы по целому ряду причин. Во-первых, при ознакомлении с объектом строят модель "КАК ЕСТЬ". Такая модель фиксирует бизнес процессы и используемые ими информационные потоки. Во-вторых, функциональная модель "КАК ЕСТЬ" позволяет увидеть информационно перегруженные бизнес процессы - "узкие" места обследуемого объекта. В-третьих, на основании модель "КАК ЕСТЬ" можно построить модель "КАК БУДЕТ". То есть предложить более совершенную структуру организации объекта. Но это уже вопросы реинжиниринга и мы их не будем касаться. Можно только отметить, что реинжиниринг подчеркивает важную роль информационных технологий в жизни общества. В-четвертых, в процессе построения модели "КАК ЕСТЬ" выявляются бизнес-правила - положения, которые регламентируют процесс функционирования моделируемого объекта. Например, представленный на слайде фрагмент функциональной модели должен быть зафиксирован бизнес-правилом: "служба снабжения обязана определять потребности в материалах для производства готовой продукции только на основании плана выпуска".

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

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

Методология Data Flow Diagram

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

Основы методологии построения диаграмм потоков данных DFD были описаны в 1979 году C. Gane и T. Sarson в книге "Structured Systems Analysis".

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

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

• External Entity ( Внешняя сущность ) представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом, расположенным как бы "над" диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений.
• Process ( Процессы , Системы и подсистемы) - при построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.
• Datastore ( Хранилище данных ) представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
• Dataflow ( Поток данны х) определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д. и т.п.

Аналогично IDEF0, для удобства DF-диаграммы разделяют на уровни.

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

На 1 уровне выделяются основные компоненты системы. С 0-го уровня сюда переносятся все потоки данных. Диаграмма дополняется потоками данных внутри системы и хранилищами данных.

Внешние сущности:

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

Процессы:

• описывают действия с информацией;
• должны быть представлены на всех уровнях диаграммы:
• Уровень 0 - один процесс, описывающий систему;
• Уровень 1+ -рекомендуется размещать не более 7 процессов;
• дубликаты (процессы с одинаковым именем или содержанием) не допускаются.

Хранилища данных:

• указывает вид информации которые хранятся в системе (товары, накладные, персонал);
• не отображаются на уровне 0;
• все хранилища данных, которые есть в ИС должны быть указаны на уровне 1.

Потоки данных:

• отображают направление передачи данных;
• отображаются на всех уровнях диаграммы;
• должны иметь содержательное имя.

Алгоритм построения диаграммы

1. Определите входящие запросы или события, на которые должна реагировать система. Определите что система отвечает на них.
2. Определите кто формирует эти запросы и получает ответ (это внешние сущности).
3. Постройте диаграмму уровня 0 - на ней отображены только внешние сущности и главный процесс системы.
4. Постройте диаграмму уровня 1 - на ней должны быть отображены все внешние сущности, все хранилища данных, главные процессы и потоки информации между ними.
5. Проанализируйте и оптимизируйте диаграмму уровня 1. Рекомендуется на одном уровне диаграммы размещать 7±2 процесса.
6. Если требуется, детализируйте отдельные процессы на уровне 2(3,4 …).

Типичные ошибки построения DF-диаграмм

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

На DFD диаграмме не отображаются точки начала и окончания, решения(if) и циклы.

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

Внешние сущности не могут напрямую обращаться к хранилищам данных

Хранилище данных не может напрямую обращаться к другому хранилищу. Между ними должен быть процесс.

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

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

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

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

Давайте построим DF-диаграмму для информационной системы риэлтерской конторы.

Фирма функционирует следующим образом:

• Заказчики могут оставлять заявки на аренду.
• Менеджер подыскивает надвижимость и готовит проект договора.
• Клиент подписывает договор.

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

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

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

Диаграмма построена в предположении, что круг клиентов конторы относительно стабилен.

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

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

Наличие на диаграмме процесса "Подготовить договор аренды" - это следствие того, что "черновик" договора аренды готовит клерк, а менеджер принимает решение о заключении договора. Это повышает эффективность работы фирмы в целом.

Роль методологий в анализе моделируемого объекта (Выводы)

В результате анализа моделируемого информационной системой объекта на основе построения IDEF0 и DFD-диаграмм:

Определяют главную функцию проектируемой системы. Например, "сопровождать аренду недвижи­мости".

Описывают происходящие в моделируемом объекте бизнес процессы.

Например, так:

1. заключать договора аренды;
2. сопровождать хранение информации об объектах недвижимости.

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

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

Как видим назначение концептуальной модели объекта:

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

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

Использование UML для проектирования систем

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

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

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

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

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

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

State Maсhine diagram (диаграммы состояний)

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

Statechart diagram (диаграмма состояний)

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

Activity diagram (диаграммы активности)

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

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

Interaction diagram (диаграммы взаимодействия)

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

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

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

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

Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaboration diagram.

Collaboration diagram (диаграммы сотрудничества)

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

Class diagram (диаграммы классов)

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

Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. Классы имеют различные нотации. В нотации, предложенной Г. Бучем классы изображаются в виде чего-то нечеткого, похожего на облако. Таким образом Г.Буч пытается показать, что класс - это лишь шаблон, по которому в дальнейшем будет создан конкретный объект.

Component diagram (диаграммы компонентов)

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

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

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

   Отчет

   ЭЛЕКТРОННЫЙ АДМИНИСТРАТИВНЫЙ РЕГЛАМЕНТ, АДМИНИСТРАТИВНЫЙ РЕГЛАМЕНТ, ДОЛЖНОСТНОЙ РЕГЛАМЕНТ, АДМИНИСТРАТИВНО-УПРАВЛЕНЧЕСКИЙ ПРОЦЕСС, ОПИСАНИЕ АДМИНИСТРАТИВНО-УПРАВЛЕНЧЕСКИХ ПРОЦЕССОВ,

2. управление процессами

   Документ

   Позняковский Валерий Михайлович – директор НИИ биотехнологии и сертификации, зав. кафедры биотехнологии, товароведения и управления качеством Кемеровского технологического института пищевой промышленности,

3. Технологии защиты информации в сети Курс лекций Введение В данном курсе изложены теоретические основы криптографии и вопросы сетевой безопасности Предназначено для чтения курса «Технологии защиты информации в сети» Содержание

   Обзор

4. Информационные технологии в профессиональной деятельности

   Учебно-методический комплекс

   Учебно-методический комплекс по учебной дисциплине «Информационные технологии в профессиональной деятельности» для специальности 030503.52 – «Правоведение» среднего профессионального образования.

5. Учебно-методический комплекс по дисциплине «информационные технологии в бизнес-планировании»

   Учебно-методический комплекс

6. Дата

   08 Авг 2013

   Тема: Знакомство с CASE-средством разработки информационных систем BPwin

   Цель работы : познакомиться с CASE-средством BPwin фирмы Computer Associates, научиться строить модель в методологии IDEF0 .

   Порядок работы:
   1. Ознакомиться с принципами построения модели в BPwin.
   2. Ознакомиться с основной панелью инструментов.
   3. Ознакомиться с палитрой инструментов IDEF0.
   4. Научиться строить контекстную диаграмму, определять цель, точку зрения, границы модели. Освоить работу с закладками General, Purpose, Definition, Status, Numbering, Display.
   5. Научиться строить декомпозирующие диаграммы.
   6. Выполнить практическое задание.
   7. Ответить на контрольные вопросы.

   1. Краткая информация об CASE-средстве BPwin

   BPwin - CASE-средство верхнего уровня, помогающее проводить анализ и реорганизацию бизнес-процессов. Поддерживается методология IDEF0 (функциональная модель), IDEF3 (Work Flow Diagram), DFD (Data Flow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей – того, к чему надо стремиться (модель TO-BE).
   Процесс построения информационной модели в BPwin состоит из следующих шагов:
   построение контекстной диаграммы;
   проводится функциональная декомпозиция;
   после каждого сеанса декомпозиции проводится сеанс экспертизы.
   На основе модели BPwin можно построить модель данных. В программе поддерживается связь с ERwin.

   2. Инструментальная среда BPwin

   При запуске BPwin по умолчанию появляется основная панель инструментов (рис.1), палитра инструментов и навигатор модели Model Explorer (рис.2).

   Рис.1 Внешний вид панели управления BPwin4.0

   Панель инструментов представлена следующими кнопками (слева направо):
   создать модель (пункт меню File/New);
   открыть модель (пункт меню File/Open);
   сохранить модель (пункт меню File/Save);
   напечатать модель (пункт меню File/Print);
   выбор масштаба (View/Zoom);
   уменьшить модель (View/Zoom);
   увеличить модель (View/Zoom);
   проверить правописание (Tools/Spelling);
   включение и выключение навигатора модели (View/Model Explorer);
   включение и выключение дополнительной панели инструментов работы с Model Mart (Model Mart).

   

   Рис.2 Внешний вид окна навигатора модели Model Explorer

   При создании новой модели возникает диалог, в котором следует указать, будет ли модель создаваться заново, или она будет открыта из файла либо из репозитария Model Mart. Также необходимо внести имя модели и выбрать методологию, в которой будет построена модель (рис.3).

   

   Рис.3 Диалог создания модели.

   BPwin поддерживает три методологии моделирования:
   функциональное моделирование (IDEFO);
   описание бизнес-процес¬сов (IDEF3);
   диаграммы потоков дан¬ных (DFD).
   В зависимости от выбранной методологии программой автомати¬чески подбирается нужная панель инструментов BPwin Toolbox. В BPwin существует три разных панели инструментов - по числу поддерживаемых програм¬мой методологий. На рис.4 представлена палитра для IDEF0.

   

   Рис.4 Палитра инструментов IDEF0.

   Вы можете показывать или скрывать панель инструментов, используя функцию «View» на панели меню.

   3. Построение модели IDEF0. Контекстная диаграмма
   Функциональное моделирование является технологией анализа системы в целом как набора связанных между собой действий или функций. Действия системы анализируются независимо от объектов, которые обеспечивают их исполнение. Моделировать деловой про¬цесс можно исходя из различных перспектив и временных рамок. На¬пример, вы можете моделировать процесс заказа услуг клиентом так, как вы видите его в идеале, а не так, как это происходит в настоящее время. Также можно абстрагироваться от проблем физической реализации модели.
   Процесс моделирования какой-либо системы в IDEF0 начинается с определения КОНТЕКСТА, т.е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
   Под субъектом понимается сама система, при этом необходимо точно установить ГРАНИЦЫ СИСТЕМЫ, определить, что входит в систему, а что лежит за ее пределами. То есть необходимо решить, что будет рассматриваться как компоненты системы, а что как внешнее воздействие. Другими словами, первоначально необходимо определить область (Scope) моделирования.
   Наименование функции самого высокого уровня опи¬сывает систему непосредственно и, как правило, состоит из одного активного глагола в сочетании с обобщающим существительным, ко¬торое разъясняет цель деятельности с точки зрения самого общего взгляда на систему. Например «Изготовить изделие».
   Формулировка цели моделирования (Purpose) позволяет команде аналитиков сфокусировать усилия в нужном направлении. Модель не может быть построена без четко сформулированной цели.
   Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения.
   Для определения контекста модели в BPwin следует выбрать пункт меню Model/Model Properties. В закладке General указывается наименование и сведения об авторе модели, в закладку Purpose следует внести цель и точку зрения, а в закладку Definition – определение модели и описание области (рис.5).
   Для создания контекстной диаграммы необходимо сначала соз¬дать новую модель, выбрав пункт «New» в меню «File». В появившем¬ся диалоге необходимо набрать имя модели и выбрать ее тип. Этот диалог также отображается при запуске BPwin.
   После создания модели можно задать ее параметры. Кроме вышеперечисленных свойств модели (Model Properties) можно задать состоя¬ние, в котором находится модель, например «в работе» или «для публикации» (закладка Status).

   

   Рис.5 Диалог задания свойств модели.

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

   

   Рис.6 Пример контекстной диаграммы.

   4. Декомпозиция
   Декомпозиционное разложение модели используется в моделиро¬вании бизнес-процессов, для того чтобы дать более подробное описа¬ние блоков. Каждый из них может в свою очередь быть де¬композированным. При каждой декомпозиции блока создается новая диаграмма. Число декомпозиций не ограничено и полностью зависит от уровня сложности, который необходимо показать в модели.
   Чтобы выполнить декомпозицию функции, необходимо щелкнуть по кнопке . Возникает диалог Activity Box Count (рис.7), в котором следует указать нотацию новой диаграммы и количество блоков на ней. Для IDEF0 рекомендуется 3-6 блоков.

   Рис.7 Диалог Activity Box Count.

   BPwin создает новую диаграмму, которая является диаграммой разложения родительской диаграммы. Заметьте, что новые действия не связаны между собой и не поименованы - это следующая задача. Необходимо задать взаимодействие между блоками и «привязать» к но¬вым блокам стрелки, которые автоматически унаследованы от роди¬тельской диаграммы (рис.8).

   Рис.8 Пример несвязанных стрелок.

   Имя блока и другие его свойства вводятся в закладке «Name» спи¬ска свойств блока. Для вывода свойств блока на экран достаточно два¬жды щелкнуть мышью на блоке.
   Следующим шагом при создании диаграммы должно быть соеди¬нение всех использованных на диаграмме блоков с помощью стрелок, представляющих входы, результаты работы, средства управления и механизмы. Для этого достаточно соединить исходящую точку стрел¬ки с точкой ее окончания. Окончанием стрелки может быть как одна из сторон функциональных блоков, так и граница диаграммы. BPwin автоматически выделяет допустимые окончания для создаваемых стрелок. Для рисования стрелки пользуются инструментом из комплекта инструментов. Задание имени стрелки производится в закладке «Name» диалога свойств стрелок. Для вызова этого диалога достаточно дважды щелк¬нуть мышью на нужной стрелке.
   Если количества блоков на диаграмме окажется недостаточным, существует возможность добавления на нее новых блоков с использованием кнопки панели инструментов. Для добавления блока сле¬дует щелкнуть на этом инструменте, а затем - на диаграмме в том месте, где необходимо расположить новый блок. После того как до¬полнительный блок создан, вы можете связать его стрелками с други¬ми блоками и задать его название и другие свойства.
   Обра¬тите внимание на рис.9. Если действие не было декомпозирова¬но, в верхнем левом углу блока будет по¬являться символ «листа». После деком-позиции данного блока символ «листа» исчезнет.

   

   Рис.9 Пример недекомпозированного блока.

   Нумерация блоков производится автоматически при их создании. Номера могут быть относительными или постоянными, они отражают иерархическое положение блока в пределах модели. Вы можете управлять нумерацией блоков на диаграмме, используя закладку «Numbering» диалога ввода свойств модели (рис.5).
   Перемещение любых объектов на диаграмме осуществляется с по¬мощью их «захвата» мышью и перемещения в новое место. При пере¬мещении блоков одновременно перемещаются и связанные с ними стрелки. Функциональные блоки могут также быть перемещены меж¬ду диаграммами с использованием команд «Cut/Paste» из меню «Edit». При изменении взаимного расположения блоков могут меняться и их но¬мера.
   Для идентификации граничных стрелок предназначены ICOM-коды. Код содержит префикс, соответствующий типу стрелки (Input, Control, Output, Mechanism) и порядковый номер. BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes на закладке Display диалога свойств.
   Практическое задание:
   1. Согласно варианту, создайте контекстную диаграмму. Определите цель, точку зрения модели. Опишите свойства в соответствующих закладках диалога Model Properties.
   2. Задайте входы, выходы, механизмы и управление.
   3. Создайте декомпозицию контекстной диаграммы, состоящую из 2-3 блоков. Задайте автоматическую нумерацию блоков и ICOM-кодов.
   4. Установите связи между блоками. Задайте имена дуг.
   5. Сохраните проект в отдельный файл.

   Контрольные вопросы:
   1. Для чего используется методология IDEF0.
   2. Объясните необходимость задания цели и точки зрения модели?
   3. Перечислите и расскажите назначения кнопок на панели инструментов.
   4. Перечислите этапы декомпозиции блока.
   5. Расскажите, каким образом на диаграмму добавить блок, дугу.
   6. Дайте определение ICOM-кодов.
   7. Для чего используются закладки General, Purpose, Definition, Status, Numbering, Display в диалоге Model Properties.
   Варианты к практическим работам
   Вариант 1
   Система должна описывать порядок подготовки к экзамену, предполагающий получение отличной оценки.
   Вариант 2
   Система должна описывать порядок выполнения практической работы по дисциплине «Проектирование ИС».
   Вариант 3
   Система должна описывать порядок получения водительских прав.
   Вариант 4
   Система должна описывать порядок организации городского спортивного соревнования.
   Вариант 5
   Система должна описывать порядок организации общеинститутского студенческого мероприятия.
   Вариант 6
   Система составления учебного графика дисциплин, изучаемых на факультете
   Вариант 7
   Система должна описывать порядок поставок товара в систему розничных киосков.
   Вариант 8
   Система должна описывать порядок обработки заказов в службе быта.
   Вариант 9
   Система должна описывать работу одного из участков автосалона.
   Вариант 10
   Система должна описывать работу приемного покоя в больнице.
   Вариант 11
   Система должна описывать порядок приема заявки на поставку продукции на хлебокомбинате.
   Вариант 12
   Система должна описывать процесс поставки сезонных товаров в оптовой фирме.
   Вариант 13
   Система должна описывать процесс работы торгового отдела.
   Вариант 15
   Система учета в видеопрокате.
   Вариант 16
   Система учета проката на лыжной базе

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

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

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

   прокат автомобиль информационный база

   Введение

   Глоссарий проекта

   1. Техническое задание на разработку

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

   4.1 Модели вариантов использования системы

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

   4.3 Диаграмма деятельности

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

   4.5 Диаграмма кооперации

   4.6 Диаграмма состояния

   5.1 Разработка интерфейса программного продукта

   6. Тестирование программного продукта

   7. Техническая документация

   Заключение

   Библиографический список

   Приложения

   Введение

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

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

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

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

   · детализированный расчет стоимости конкретного заказа.

   Глоссарий проекта

   Таблица 1

   	Определение
   Прокат автомобилей	Это деятельность по представлению автомобилей на ограниченный срок эксплуатации
   Руководитель Прокат автомобилей	Владелец Прокат автомобилей или директор одного филиала Прокат автомобилей в крупной организации
   	Транспортные средства, являющиеся предметом аренды
   	Лицо, которое арендует ТС на ограниченный срок эксплуатации
   Доставка ТС	Подвоз ТС к месту нахождения ТС при условии предварительной оплаты срока аренды для арендуемого автомобиля
   Менеджер по аренде ТС	Работник, занимающийся оформлением договора аренды ТС
   Внешняя статистика арендуемых ТС	Статистика по аренде, получаемая из сети Прокат автомобилей
   Внутренняя статистика арендуемых ТС	Статистика по аренде, получаемая из отчетов аренды клиентам компании
   Номер автомобиля	Это государственный регистрационный знак, который присваивается каждому автомобили индивидуально во время регистрации автомобиля в конкретной стране и конкретном регионе

   1 . Техническое задание на разработку

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

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

   В процессе проектирования было создано и утверждено техническое задание на разработку ИС "Проката автомобилей", которое приведено в приложении А.

   2. Технико-экономические показатели

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

   Разработка информационной системы прокат автомобилей требует деятельности коллектива из 1-5 человек соответствующей квалификации. Длительность полного цикла создания программного продукта - 1 месяц.

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

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

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

   3. Функциональная модель информационной системы

   Контекстная диаграмма ИС "Проката автомобилей" показана на рисунке 1. Функциональная диаграмма первого уровня приведена на рисунке 2. На рисунках 3 и 4 показаны функциональные диаграммы второго уровня для функций "Обслуживание клиентов и приём прочих поступлений" и "Оплата за аренду автомобилей".

   Рисунок 1. Контекстная функциональная диаграмма информационной системы.

   Рисунок 2. Функциональная диаграмма первого уровня информационной системы".

   Рисунок 3. Функциональная диаграмма второго уровня в нотации DFD "Обслуживание клиентов и приём прочих поступлений".

   Рисунок 4 . Функциональная диаграмма второго уровня в нотации DFD "Оплата за аренду автомобилей".

   4. Объектно-ориентированное проектирование системы

   4.1 Модели вариантов использования системы

   В диаграмме вариантов использования используется сценарий взаимодействия между "Менеджером по прокату" и "Клиентом".

   В ходе анализа для данного сценария было выделено 2 действующих лица: "Клиент" и "Менеджер по прокату". Для каждого из них были выделены прецеденты.

   Полученная диаграмма вариантов использования ИС "Проката автомобилей" показана на рисунке 5.

   Рисунок 5. Диаграмма вариантов использования информационной системы.

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

   В ходе анализа для проектируемой информационной системы было выделено 5 классов: Менеджер по прокату, Центр проката, Клиенты, ИС Авто-Прокат, Автомобили проката. Для каждого из них были описаны атрибуты и операции.

   Рисунок 6. Диаграмма классов.

   5.3 Диаграмма деятельности

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

   Рисунок 7. Диаграмма деятельности.

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

   В ходе анализа для проектируемой информационной системы было выделено 5 классов:

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

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

   5.5 Диаграмма кооперации

   В ходе анализа для проектируемой информационной системы было выделено 3 классификационные роли: Менеджер компании, Клиент, Автомобиль, связанные между собой ассоциативной связью.

   Рисунок 9. Диаграмма кооперации.

   5.6 Диаграмма состояния

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

   Рисунок 10. Диаграмма состояния.

   5. Создание информационной системы

   5.1 Разработка интерфейса программного продукта

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

   Рисунок 11. Стартовое состояние.

   Если пользователь введёт неверный пароль, для него появится предупреждение (рисунок 12).

   Рисунок 12. Ошибка при авторизации.

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

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

   Рисунок 14. Предупреждение при незаполненных полях.

   Рисунок 15. Уведомление об успешном добавлении заказа.

   Рисунок 16. Внешний вид заполненной базы данных.

   5.2 Разработка программного кода системы

   C# разрабатывался как язык программирования прикладного уровня для CLR и, как таковой, зависит, прежде всего, от возможностей самой CLR. Это касается, прежде всего, системы типов C#, которая отражает BCL.

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

   В Приложении Б приведен полученный программный код проекта.

   6. Тестирование программного продукта

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

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

   Пример тестирования программы.

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

   7. Техническая документация

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

   Заключение

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

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

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

   На данный момент приложение ИС прокат автомобилей предоставляет ограниченный функционал и в дальнейшем может совершенствоваться, в качестве совершенствования можно добавить базы данных "Автомобили" и "Клиенты", а также добавить возможности подсчёта финансовых показателей "прокат автомобилей.

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

   Библиографический список

   1. Большаков А.А., Вешнева И.В., Мельников Л.А., Перова Л.Г. Новые методы математического моделирования динамики и управления формированием компетенций в процессе обучения в вузе. М.: Горячая линия-Телеком, 2014. 250 с. (ЭБС "Лань")

   2. Губарев А.В. Информационное обеспечение системы менеджмента качества. М.: Горячая линия-Телеком, 2013. 132 с. (ЭБС "Лань")

   3. Денисенко В.В. Компьютерное управление технологическими процессами, экспериментом, оборудованием. М.: Горячая линия-Телеком. 2013. 606 с. (ЭБС "Лань")

   4. Дьяконов В.П. Новые информационные технологии. М.: СОЛОН_Пресс, 2008. 640 с. (ЭБС "Лань")

   5. Кораблин М.А. Информатика поиска управленческих решений. М.: СОЛОН_Пресс, 2009. 192 с. (ЭБС "Лань")

   6. Таганов А.И., Гильман Д.В. Методологические основы анализа и аттестации уровней зрелости процессов программных проектов в условиях нечеткости. М.: Горячая линия-Телеком. 2014. 168 с. (ЭБС "Лань")

   7. Фельдман Я.А. Создаем информационные системы. М.: СОЛОН_Пресс, 2009. 120 с. (ЭБС "Лань")

   8. Гагарина Л.Г., Виснадул Б.Д., Игошин А.В. "Основы технологии разработки программных продуктов" - М.: Форум: Инфра-М, 2006. 192 с.

   9. Лаврищева Е.М. , Петрухин В.А. "Методы и средства инженерии программного обеспечения" - М.:МФТИ (ГУ), 2006. 305 с.

   Приложения

   Приложение А

   Техническое задание на разработку ИС "Проката автомобилей"

   Введение

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

   1. Назначение программы

   1.1. Наименование программы: "Разработка информационной системы прокат автомобилей"

   1.2. Назначение и область применения. Программа предназначена для автоматизации и облегчения учёта автомобилей в компании

   2. Требования к программе

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

   3. Технические требования

   3.1. Требования к функциональным характеристикам

   3.1.1. Состав выполняемых функций.

   Единый учет автомобилей в разрезе их характеристик (марка, пробег, свободен или арендован);

   Поддержка учета поступления заявок;

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

   Детализированный расчет стоимости конкретного заказа.

   4. Требования к программной документации

   4.1. предварительный состав программной документации. Состав программной документации должен включать в себя:

   4.1.1. Техническое задание

   4.1.2. Программу и методики испытаний

   4.1.3. Руководство оператора

   5. Стадии и этапы разработки.

   5.1, Стадии разработки. Разработка должна быть проведена в три стадии:

   · 1, Разработка технического задания;

   · 2, Рабочее проектирование;

   · 3, Внедрение

   5.2. Этапы разработки.

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

   1. Разработка программы

   2. Разработка программной документации

   3. Испытания программы

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

   6. Технико-экономические показатели

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

   Разработка ИС прокат автомобилей требует деятельности коллектива из менеджеров по продажам, администратора автопарка и клиентов автопарка. Длительность полного цикла создания программного продукта - 2 месяца.

   7. Порядок контроля и приемки

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

   Приложение Б

   Исходный программный код информационной системы

   using System.ComponentModel;

   using System.Data;

   using System.Drawing;

   using System.Linq;

   using System.Text;

   using System.Threading.Tasks;

   using System.Windows.Forms;

   public partial class Form1: Form

   form2 form = new form2();

   string nameP = "";

   InitializeComponent();

   if (dostup == false)

   string imenov1 = textBox3.Text;

   string imenov2 = textBox6.Text;

   string category1 = comboBox2.Text;

   string imenov3 = textBox7.Text;

   string imenov4 = textBox8.Text;

   string category2 = comboBox1.Text;

   string imenov5 = textBox5.Text;

   string imenov6 = textBox4.Text;

   if (imenov1 != "" & imenov2 != "" & category1 != "" & imenov3 != "" & imenov4 != "" & category2 != "" & imenov5 != "" & imenov6 != "")

   form.dataGridView1.Rows.Add(imenov1, imenov2, category1, imenov3, imenov4, category2, imenov5, imenov6);

   MessageBox.Show("Заказ успешно добавлен!", "Уведомление");

   MessageBox.Show("Все поля должны быть заполнены!", "Предупреждение!");

   if(textBox1.Text == "Admin")

   nameP = textBox1.Text;

   groupBox1.Visible = true; //Открываем рабочую область

   button5.Visible = true;

   groupBox2.Visible = false; //Скрываем объекты

   label1.Visible = false;

   textBox1.Visible = false;

   label6.Location = new Point(506, 12); //Меняем координаты объектов

   label7.Text = nameP;

   label7.Location = new Point(506, 29);

   MessageBox.Show("Такого менеджера не существует, возможно вы ошиблись при вводе данных!", "Предупреждение!");

   Close(); //Выход из программы

   private void button5_Click(object sender, EventArgs e)

   if (nameP != "")

   private void textBox1_TextChanged(object sender, EventArgs e)

   private void Form1_Load(object sender, EventArgs e)

   groupBox1.Visible = false;

   button5.Visible = false;

   private void groupBox1_Enter(object sender, EventArgs e)

   private void textBox3_TextChanged(object sender, EventArgs e)

   using System.Collections.Generic;

   using System.ComponentModel;

   using System.Data;

   using System.Drawing;

   using System.Linq;

   using System.Text;

   using System.Threading.Tasks;

   using System.Windows.Forms;

   public partial class form2: Form

   InitializeComponent();

   private void button2_Click(object sender, EventArgs e)

   dataGridView1.Rows.Add("01", "02", "03", "04", "05", "06", "07", "08");

   private void button1_Click(object sender, EventArgs e)

   private void dataGridView1_CellContentClick(object sender, DataGridViewCellEventArgs e)

   private void button2_Click_1(object sender, EventArgs e)

   dataGridView1.Rows.Clear(); //Удаляем все данные из таблицы БД

   private void button3_Click(object sender, EventArgs e)

   //Удаляем одну строчку из таблицы БД

   int ind = dataGridView1.SelectedCells.RowIndex;

   dataGridView1.Rows.RemoveAt(ind);

   Приложение В

   Руководство пользователя

   1. НАЗНАЧЕНИЕ ПРОГРАММЫ.

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

   2.УСЛОВИЯ ВЫПОЛНЕНИЯ ПРОГРАММЫ.

   Для работы с данным программным обеспечением необходимо наличие ПК с требуемыми техническими характеристиками, а именно:

   2.1. Требования к функциональным характеристикам.

   2.1.1. Состав выполняемых функций.

   Разрабатываемое ПО должно обеспечивать:

   поступление новых заявок на аренду;

   списание и перевод заявок в другие точки аренды;

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

   введение данных о менеджере (ФИО, стаж работы в этой области);

   перечень автомобилей в разрезе их характеристик (цвет, класс, мощность и т.д.).

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

   В конце отчетного периода система должна архивировать данные.

   2.1.2. Организация входных и выходных данных.

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

   2.2. Требования к надежности.

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

   3. ВЫПОЛНЕНИЕ ПРОГРАММЫ.

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

   4. СООБЩЕНИЯ ОПЕРАТОРУ.

   - "Заказ успешно добавлен!" - добавлена информация о заказе

   Руководство администратора

   1. ОБЩИЕ СВЕДЕНИЯ О ПРОГРАММЕ.

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

   2. СТРУКТУРА ПРОГРАММЫ.

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

   3. ДОПОЛНИТЕЛЬНЫЕ ВОЗМОЖНОСТИ.

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

   Происходит вывод из БД, в котором представлена вся необходимая информация о заказах.

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

   4. СООБЩЕНИЕ СИСТЕМНОМУ ПРОГРАММИСТУ.

   Вывод ошибок при некорректном запуске программы.

   Вывод ошибок при некорректном сохранение данных программы.

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

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

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

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

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

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

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

   Разработка информационной системы на платформе "1С:Предприятие 8.0" для автоматизации документооборота и учета по приему аварийных автомобилей и составлению заказ-нарядов. Проектирование интерфейса. Построение логической и физической моделей данных.

   дипломная работа , добавлен 14.02.2015
   

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

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

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

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

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

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

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

   дипломная работа , добавлен 02.11.2015
   

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

   дипломная работа , добавлен 08.02.2015
   

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

   дипломная работа , добавлен 02.08.2015
   

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

   Лабораторная работа № 2. Разработка моделей IDEF0

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

   1. Изучите теоретические сведения.

   2. Выполните следующие задания:

   · Создание контекстной диаграммы.

   · Создание диаграммы узлов.

   · Создание FEO диаграммы.

   · Расщепление и слияние моделей.

   3. Выполните структурный анализ задачи, определенной в ТЗ (первая лабораторная работа).

   4. Выполненный анализ задачи оформите в виде диаграмм IDEF0 (программные продукты MS Visio, BPwin).

   Теоретическая часть

   Методология функционального моделирования IDEF 0

   Лекционный материал

   Общая постановка задачи

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

   Список индивидуальных данных

   Продолжается работа над задачей, выбранной в первой лабораторной работе.

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

   Как было определено в ТЗ, входной информацией системы является:

   · бухгалтерская информация;

   · информация о нажатой кнопке RTE;

   · регистрационная информация;

   · информация о считанном идентификаторе.

   Выходной информацией системы является:

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

   · отчеты.

   Контекстная диаграмм (диаграмма А-0) разрабатываемой системы управления платной автостоянкой приведена на рис. 1.

   Рис. 1. IDEF0-диаграмма А-0 - контекстная диаграмма системы управления платной автостоянкой

   Детализация контекстной диаграммы А-0 представлена на рис. 2 (диаграмма А0). На данной диаграмме выделены три функциональных блока «Регистрация клиентов и корректировка информации о клиентах», «Пропуск клиента» и «Формирование отчетов».

   
   

   

   Рис. 2. IDEF0-диаграмма А0 – детализация контекстной диаграммы

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

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

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

   Детализация блока «Регистрация клиентов и корректировка информации о клиентах» представлена на рис. 3. Как видно из диаграммы, перед регистрацией клиента и изменением информации о клиенте осуществляется проверка соответствующих прав сотрудника автостоянки (права администратора). Права определяются на основании введенного пароля.

   Владелец" href="/text/category/vladeletc/" rel="bookmark">владельце идентификатора не осуществляется. Информация о нажатии данной кнопки сразу поступает на блок формирования управляющих воздействий.

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

   

   Рис. 4. IDEF0-диаграмма А2 – детализация блока «Пропуск клиента» диаграммы А0

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

   Детализация блока «Формирование отчетов» диаграммы А0 представлена на рис. 5. (диаграмма А3). Вначале необходимо выбрать тип отчета. Затем формируется соответствующий отчет. Все отчеты в системе можно разделить на два типа:

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

   2. Отчеты, для формирования которых нужна информация о выполненных действиях.

   

   Рис. 5. IDEF0-диаграмма А3 – детализация блока «Формирование отчетов» диаграммы А0

   
   

   К первому типу относятся следующие отчеты:

   · список клиентов;

   · задолжености клиентов.

   Ко второму типу относятся следующие отчеты:

   · активность использования машиномест;

   · список занятых и свободных машиномест;

   · список событий.

   Детализация блока «Выполнить изменение информации о клиенте» диаграммы А1 представлена на рис. 6 (диаграмма А14). Требования внесения информации о клиенте могут быть вызваны следующими причинами:

   · не произведена оплата аренды машиноместа;

   · не произведена оплата пропуска;

   · требуются изменения в договоре;

   · требуется замена пропуска (идентификатора).

   

   Рис. 6. IDEF0-диаграмма А14 – детализация блока «Выполнить изменение информации о клиенте» диаграммы А1

   Детализация блока «Изменение договора» диаграммы 14 представлена на рис. 7 (диаграмма А142). Если требуется изменение договора, то выписывается новый договор, который отдается клиенту. После подписания договора клиентом и руководством автостоянки, информации о договоре вносится в бухгалтерскую программу и в разрабатываемую систему.

   

   Рис. 7. IDEF0-диаграмма А142 – детализация блока «Изменение договора» диаграммы А14

   Детализация блока «Оплата» диаграммы А14 представлена на рис. 8 (диаграмма А143). Если требуется произвести оплату аренды машиномест или изготовления нового пропуска, то выписываются документы, на основании которых будет производиться оплата. С этими документами клиент отправляется в бухгалтерию и производит оплату. Информация об оплате фиксируется в бухгалтерской программе и передается в разрабатываемую систему.

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

   

   Рис. 8. IDEF0-диаграмма А143 – детализация блока «Оплата» диаграммы А14

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

   Контрольные вопросы:

   1. В чем суть методологии IDEF0 ?

   2. Синтаксис и семантика функциональных блоков диаграммах IDEF0 ?

   3. Синтаксис и семантика стрелок в диаграммах IDEF0:

   · стрелки входа;

   · стрелки управления;

   · стрелки выхода;

   · стрелки механизма исполнения;

   · комбинированные стрелки;

   · разбиение и соединение стрелок;

   · туннели.

   4. Основы методики построения моделей IDEF0.

   5. Основные возможности программного продукта MS Visio.

   6. Построение диаграмм IDEF0 с помощью программного продукта MS Visio.

   7. Основные возможности программного продукта BPwin.

   8. Построение диаграмм IDEF0 с помощью программного продукта BPwin.

   
   
   

← Вернуться