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

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

Требования к выбираемой технологии проектирования:

- должна максимально отражать все этапы жизненного цикла проекта;

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

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

- должна способствовать росту производительности труда проектировщика;

- должна обеспечивать надежность процесса проектирования и эксплуатации проекта;

- должна способствовать простому ведению проектной документации.

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

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

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

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

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

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

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

- представление всей информации в виде графической нотации.

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

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

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

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

- оригинального (индивидуального) проектирования, т.е. проектные решения разрабатываются "с нуля" в соответствии с требованиями к ИС;

- типового проектирования, предполагающего конфигурирование ИС из готовых типовых проектных решений (программных модулей).

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

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

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

В основе методологии графического языка IDEF0 лежат четыре основных понятия.

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

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

- верхняя сторона имеет значение "Управление" (Control);

- левая сторона имеет значение "Вход" (Input);

- правая сторона имеет значение "Выход" (Output);

- нижняя сторона имеет значение "Механизм" (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

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

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

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

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

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

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

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

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

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

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

В пользу применения методологии IDEF0 для описания и классификации процессов говорит и тот факт, что данная методология является стандартом для функционального моделирования в ряде стран, включая США и Россию. Данное обстоятельство делает возможным использовать методологию IDEF0 в качестве единого языка для обмена информацией между организациями, аудиторами, экспертами.

Для поддержки моделирования в стандарте IDEF0 существуют различные компьютерные программы: WorkFlow Modeler (MetaSoftware, Corp.), AI0Win (KBS, Inc.), IDEF0. EM Tool (ИП Ориентсофт). Наиболее распространенным является ERwin Process Modeler фирмы Computer Associates International, Inc.

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

Для разработки программного продукта была выбрана платформа 1С: Предприятие 8.1.

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

Платформа "1С: Предприятие" содержит такие инструменты для выполнения поставленных задач, как визуальное описание структур данных, написание программного кода, визуальное описание запросов, визуальное описание интерфейса, описание отчетов, отладка программного кода, профилирование. В ее составе: развитая справочная система, механизм ролевой настройки прав, инструменты создания дистрибутивов, удаленного обновления приложений, сравнения и объединения приложений, ведения журналов и диагностики работы приложения, создания Web-приложений и приложений для КПК, а также поддержка коллективной разработки, версионирования и пр.

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

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

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

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

Еще одна особенность "1С: Предприятия" как предметно-ориентированной среды разработки - особое отношение к подбору технологических возможностей, предоставляемых разработчику. В "1С: Предприятии" есть возможность подключать другие (внешние) программные модули. Но платформа ориентирована на то, чтобы актуальные для задач автоматизации бизнеса технологии предоставить разработчику в готовом виде. Причем высокая степень "готовности" включает и простоту освоения, и "гладкость" интеграции с общей функциональностью и другими технологическими возможностями системы. Фактически платформа позволяет разработчику прикладных решений задействовать необходимые и современные технологии своевременно, максимально просто и без радикальных изменений в своем приложении. [14]

2. Практическая часть

2.1 Разработка функционального обеспечения

2.2.2 Характеристика нормативно-справочной и входной оперативной информации

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

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

- характеристики археологических находок;

- сотрудники археологической экспедиции;

- найденные археологические находки;

2.2.3 Характеристика результатной информации

В качестве результатной информации работы ИС:

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

- для специалистов НИИ: база данных с первичным описанием археологических находок;

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

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

2.2.4 Информационная модель и ее описание

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

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

Для составления логической модели данных использовано CASE-средство ERwin Data Modeler.

ERwin Data Modeler - средство концептуального моделирования БД, позволяет проектировать, документировать и сопровождать базы данных. Создав наглядную модель базы данных, можно оптимизировать структуру БД и добиться её полного соответствия требованиям и задачам организации. Визуальное моделирование повышает качество создаваемой базы данных, продуктивность и скорость её разработки. Благодаря удобной в использовании графической среде, которая упрощает проектирование баз данных и автоматизирует многие трудоемкие задачи. Разработчики с помощью ERwin Data Modeler могут сначала, используя визуальные средства, описать схему БД, а затем автоматически сгенерировать файлы данных для выбранной реляционной СУБД (прямое проектирование). Пользователь описывает структуру данных визуально. Он задает служащие прообразами реляционных таблиц сущности с их атрибутами и при помощи мыши выстраивает между ними связи, которые являются прототипами реляционных отношений. ERwin Data Modeler позволяет по уже существующим файлам БД восстанавливать логическую структуру данных. Это называется обратным проектированием.

ERwin Data Modeler поддерживает следующие типы баз данных: Oracle, InterBase, Ingres, Microsoft SQL Server, Clipper, ODBC, DB2, dBASE, Paradox, FoxPro, Rdb, HiRDB, Red Brick Warehouse, Informix, SAS, SQL Anywhere, Microsoft Access, SQL Base, Teradata, Sybase.

ERwin Data Modeler не привязан к технологии какой-либо конкретной фирмы, поставляющей СУБД или средства разработки. Он поддерживает различные серверы баз данных и настольные СУБД, а также может обращаться к базе данных через интерфейс ODBC, среди которых: Oracle; Microsoft SQL Server и т.п. Речь идет только о реляционных СУБД.