Дата: 11 июня 2006.

Скачать полный текст отчета

Скачать проект в BPwin

Скачать проект в ERwin

Скачать реализацию проекта (программа и база данных)

1. Задание на лабораторный практикум, описание предметной области, информационные запросы.

 1.1. Тема: Подсистема кадрового учёта.

1.2. Предметная область и информационные запросы.

Подсистема кадрового учёта.

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

Разработать ИС (по методологии, указанной преподавателем), формирующую отчеты по информационным запросам:

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

2. Начальника отдела кадров: Указать табельный номер, ФИО, домашний адрес, должность и название подразделения для сотрудников, имеющих детей не старше определенного возраста. Вывести все сведения о детях.

2. Краткие сведения о методологиях.

 2.1. Система проектирования SADT.

SADT - одна из самых известных и широко используемых систем проектирования. SADT - аббревиатура слов Structured Analysis and Design Technique (Технология структурного анализа и проектирования) - это графические обозначения и подход к описанию систем. Дуглас Т. Росс ввел их почти 20 лет назад. С тех пор системные аналитики компании SofTech , Inc . улучшили SADT и использовали ее в решении широкого круга проблем. Программное обеспечение телефонных сетей, системная поддержка и диагностика, долгосрочное и стратегическое планирование, автомати­зированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, встроенное программное обеспечение для оборонных систем, управление финансами и материально-техническим снабжением - вот некоторые из областей эффективного применение SADT. Широкий спектр областей указывает на универсальность и мощь методологии SADT. В программе интегрированной компьютеризации производства (ICAM) Министерства обороны США была признана полезность SADT, что привело к стандартизации и публикации ее части, называемой IDEFO . Такая стандартизация вкупе с растущей автоматизированной поддержкой означает, что SADT теперь более доступна и проста в использовании. Под названием IDEFO SADT применялась тысячами специалистов в военных и промышленных организациях. В коммерческом мире SADT используется для определения требований. В этом качестве она конкурирует с методами, ориентированными на потоки данных, - структурного проектирования Е.Иордана, структурного анализа Т.ДеМарко, структурного системного анализа С. Гейна и Т. Сарсона, а также с методами структуризации данных -методами М.Джексона, Лж.Д. Варнира и К. Орра. В отличие от этих методов структурного анализа, истоки которых нужно искать в проектировании программного обеспечения, SADT создана для описания системы и ее среды до определения требований к программному обеспечению или к чему-либо другому. Иными словами, поставив своей целью описание системы в общем, создатели SADT изобрели графический язык и набор процедур анализа для понимания системы прежде, чем можно представить себе ее воплощение. Таким образом, SADT, как правило, применяется на ранних этапах процесса создания системы, который часто называют "жизненным циклом системы", и иногда за этим следует применение упомянутых выше методов.

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

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

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

• ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

• связность диаграмм (номера блоков);

• уникальность меток и наименований (отсутствие повторяющихся имен);

• синтаксические правила для графики (блоков и дуг);

• разделение входов и управлений (правило определения роли данных).

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

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

2.2. Методологии моделирования DFD.

Методологии моделирования DFD (data flow diagram) и IDEF3 (workflow). Методология DFD служит для описания потоков данных, которые возникают в результате деятельности компании. Методология IDEF3 служить для графического описания потока процессов (работ), взаимодействия процессов и объектов, которые изменяются этими процессами. В диаграммах потоков данных все используемые символы складываются в общую картину, которая дает четкое представление о том, какие данные используются, и какие функции выполняются системой документооборота. Хранилища данных соответствуют тем хранилищам, которые либо уже существуют, либо которые нужно создать.

3. Краткие сведения об инструментальных средствах BPWin и ERWin.

3.1. BPWin.

BPwin является мощным средством моделирования и документирования бизнес-процессов. Этот продукт использует технологию моделирования IDEF0 (Integration Definition for Function Modeling) - наиболее распространенный стандарт, который принят для моделирования бизнес-процессов. Этот стандарт был разработан в лаборатории военно-воздушных сил США в 1981 году и успешно использовался для разработки систем противовоздушной обороны.

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

Рисунок 1. Фрагмент диаграммы, описывающий процедуру входа в систему.

Основными элементами диаграммы являются активности и дуги (стрелки), которые изображают взаимосвязи и отношения активностей друг с другом. Дуги могут быть нескольких типов: вход, выход, управление и ресурсы. На каждой диаграмме обычно располагается от 3 до 6 активностей, это обусловлено тем, что такое количество активностей является оптимальным для восприятия сознанием. Модель BPwin представляет собой набор иерархически связанных и упорядоченных диаграмм, каждая из которых является конкретизацией (декомпозицией) активности предыдущего верхнего уровня. Каждая модель имеет одну диаграмму верхнего уровня, которая содержит только одну активность, определяющую общую функцию моделируемого процесса. Модели имеют так называемые "точки зрения" (point of view), определяющие ракурс, под которым рассматривается процесс. Например, для рассмотрения процесса может быть выбрана точка зрения начальника отдела компании, где происходит моделируемый процесс.

Кроме стандарта IDEF0, BPwin поддерживает также методологии моделирования DFD (data flow diagram) и IDEF3 (workflow). Методология DFD служит для описания потоков данных, которые возникают в результате деятельности компании. Методология IDEF3 служить для графического описания потока процессов (работ), взаимодействия процессов и объектов, которые изменяются этими процессами.

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

3.1.1. Пользовательский интерфейс BPWin.

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

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

Одним из важнейших средств BPwin является генератор отчетов. На деле, генератор отчетов RPTwin представляет собой автономный продукт, который поставляется с некоторыми продуктами CA/Logic Works, и позволяет генерировать подробные и многогранные отчеты по модели. Вместе с BPwin устанавливается набор стандартных отчетов, которые позволяют осветить модель с различных сторон. Отчеты обычно сопровождают окончательный вариант модели бизнес-процессов, созданной при помощи BPwin, и содержат информацию, размещение которой на модели сделало бы ее трудной для восприятия. Например, отчет может содержать подробное описание каждого элемента диаграммы, что помогает отчетливо представить себе назначение данного элемента без дополнительных разъяснений со стороны системного аналитика, создававшего диаграмму. Кроме того, существуют отчеты, которые предназначены для самого системного аналитика, например, отчет по целостности модели.

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

Рисунок 2. Среда моделирования BPwin.

3.2. ERWin.

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

Обычно разработка модели базы данных состоит из двух этапов: составление логической модели и создание на ее основе физической модели. ERwin полностью поддерживает такой процесс, он имеет два представления модели: логическое (logical) и физическое (physical). Таким образом, разработчик может строить логическую модель базы данных, не задумываясь над деталями физической реализации, т.е. уделяя основное внимание требованиям к информации и бизнес-процессам, которые будет поддерживать будущая база данных. ERwin имеет очень удобный пользовательский интерфейс, позволяющий представить базу данных в самых различных аспектах. Например, ERwin имеет такие средства визуализации как "хранимое представление" (stored display) и "предметная область" (subject area). Хранимые представления позволяют иметь несколько вариантов представления модели, в каждом из которых могут быть подчеркнуты определенные детали, которые вызвали бы перенасыщение модели, если бы они были помещены на одном представлении. Предметные области помогают вычленить из сложной и трудной для восприятия модели отдельные фрагменты, которые относятся лишь к определенной области, из числа тех, что охватывает информационная модель.

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

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

Возможность использования модели ERwin одновременно для логического и физического представления данных позволяет по окончании работы получить полностью документированную модель. ERwin, как и инструмент моделирования бизнес-процессов BPwin, интегрирован с генератором отчетов фирмы Logic Works - RPTwin. Это средство позволяет получать подробные отчеты по модели, освещая самые различные ракурсы и аспекты. Инструмент RPTwin поставляется вместе с ERwin и имеет богатый набор встроенных отчетов, позволяющих получать многогранную информацию по модели. Документирование структуры данных является очень важной частью моделирования, т.к. это позволяет другим разработчикам или лицам, которые будут сопровождать систему, быстрее начать ориентироваться во внутренней структуре и понимать назначение компонентов.

ERwin является не только инструментом для дизайна баз данных, он также поддерживает автоматическую генерацию спроектированной и определенной на физическом уровне структуры данных. ERwin поддерживает широчайший спектр серверных и настольных СУБД. В этот список входят такие продукты, как Microsoft SQL Server, Oracle, Sybase, DB2, INFORMIX, Red Brick, Teradata, PROGRESS, Microsoft Access, FoxPro, Clipper и многие другие. Для каждой из перечисленных СУБД в ERwin предусмотрено присоединение по "родному" для этой СУБД протоколу и поддержка всех средств управления данными, присущих этой СУБД. Инструмент имеет богатый и гибкий макроязык, позволяющий создавать сценарии (pre- и postscripts), которые будут выполняться до и после генерации определенного объекта на СУБД назначения. С помощью этого макроязыка можно также сгенерировать на СУБД назначения тысячи строк шаблонов, хранимых процедур и триггеров. ERwin не поддерживает моделирования механизмов защиты базы данных, однако при помощи макроязыка можно автоматически выдать права на объект, пользуясь языком определения прав, который используется в конкретной СУБД.

ERwin имеет средство, выполняющее задачу, обратную генерации, что называется "обратная разработка" (reverse engineering). Т.е. ERwin может присоединиться к СУБД, получить всю информацию о структуре базы данных и отобразить ее в графическом интерфейсе, сохранив все сущности, связи, атрибуты и прочие свойства. Таким образом, можно переносить существующую структуру данных с одной платформы на другую, а также исследовать структуру существующих баз данных.

ERwin имеет средство Complete-Compare, которое является единственным на данный момент средством интерактивной разработки. ERwin демонстрирует разногласия между моделью и базой данных, эти несоответствия можно переносить или оставлять без изменений. При помощи этого средства можно все изменения модели вносить в базу данных автоматически без необходимости контроля за соответствием модели и базы данных "вручную", при этом существующие данные не будут затронуты. ERwin поддерживает многомерное моделирование, которое используется при построении хранилищ данных. Производительность OLAP-приложений определяется, в основном, качеством дизайна хранилища данных, поэтому критически важно при разработке хранилища иметь инструмент, который бы поддерживал распространенные технологии. ERwin поддерживает две технологии моделирования хранилищ данных: звезда (star) и снежинка (snowflake).

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

4. Разработка диаграмм проекта в методологии SADT .

4.1. Определение целей модели.

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

4.2. Разработка контекстной SADT диаграммы.

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

Рисунок 3. Контекстная диаграмма проекта.

4.3. Разработка диаграмм детализации 2-го и 3-го уровней.

Диаграмма детализации второго уровня модели представлена на рисунке 4. Блоки на диаграмме размещаются по «ступенчатой» схеме в соответствии с их доминированием – влиянием, которое один блок оказывает на другие. Часто блоки еще и нумеруют, также в соответствии с доминированием.

Первый уровень декомпозиции состоит из 3 блоков (рисунок 4):

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

Рисунок 4. Первый уровень декомпозиции.

Второй уровень декомпозиции, блок «Вход в систему» состоит из 3 блоков (рисунок 5):

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

Рисунок 5. Второй уровень декомпозиции, блок «Вход в систему».

Второй уровень декомпозиции, блок «Вести БД» состоит из 3 блоков (рисунок 6):

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

Рисунок 6. Второй уровень декомпозиции, блок «Вести БД».

Третий уровень декомпозиции, блок «Вести справочники» состоит из 4 блоков (рисунок 7):

• вести справочник подразделений;
• вести справочник должностей;
• вести справочник операций;
• вести справочник пользователей.

Рисунок 7. Третий уровень декомпозиции, блок «Вести справочники».

Второй уровень декомпозиции, блок «Формировать отчеты» состоит из 2 блоков (рисунок 8):

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

Рисунок 8. Второй уровень декомпозиции, блок «Формировать отчеты».

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

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

Третий уровень декомпозиции, блок «Сформировать отчёт о сотрудниках имеющих детей не старше определённого возраста» состоит из 4 блоков (рисунок 10):

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

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

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

Рисунок 10. Третий уровень декомпозиции, блок «Сформировать отчёт о сотрудниках имеющих детей не старше определённого возраста».

4.4. SQL запросы.

SQL запрос блока «Сформировать и выполнить SQL- запрос о сотрудниках, принятых на работу в течение указанного периода на определённую должность»: Select People . Name , People . LastName from Operation , People , Position where ( Operation . Date >’+ d 1 +’) and ( Operation . Date >’+ d 2 +’) and ( People . ID _ Position = Position . ID _ Position ) and ( Position . Name _ position =’+ d 3 +’)

SQL запрос блока «Сформировать и выполнить SQL- запрос о сотрудниках, имеющих детей не старше определённого возраста»: Select People . FirstName , Children . Name , Children . Sex , Children . Date of birth from People , Children where ( People . Tab namber )=( Children . Tab namber ) and ( Children . Date of birth )<=('+ st +')

Где d1 и d2 – границы периода, d3 – должность сотрудника; st – возраст ребёнка (вычисляется программно по текущей дате и дате рождения ребёнка).

4.5. Разработка логической ER модели.

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

Рисунок 11. Схема логической модели хранения данных.

4.6. Разработка физической ER модели.

Схема логической модели хранения данных представлена на рисунке 6.

Рисунок 12. Схема физической модели хранения данных.

5. Реализация проекта.

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

Рисунок 13. Форма заполнения базы данных.

Рисунок 14. Форма информационного запроса начальника отдела кадров.

Рисунок 15. Форма информационного запроса директора предприятия.

Использованная литература.

На главную