Обзор предметной области что писать
Перейти к содержимому

Обзор предметной области что писать

  • автор:

1.1 Описание предметной области

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

2. Модели баз данных

2.1 Логическая модель базы данных

Различают три уровня логической модели, отличающихся по глубине представления информации о данных: диаграмма сущность-связь (Entity Relationship Diagram, ERD); модель данных, основанная на ключах (Key Based model, KB); полная атрибутивная модель (Fully Attributed model, FA). В данной курсовой работе используется диаграмма сущность-связь. Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи многие-ко-многим и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области. Построение модели данных предполагает определение сущностей и атрибутов, т.е. определить какая информация будет хранится в конкретной сущности или атрибуте. Сущность можно определить, как объект, информация о котором должна сохраниться. Каждая сущность имеет атрибуты. Каждый атрибут хранит информацию об определенном свойстве сущности, а каждый экземпляр сущности должен быль уникальным. Связь между сущностями осуществляется посредствам связей. Сущности проектируемой информационной системы транспортной компании. Сущность Транспортное средство включает в себя следующие атрибуты: Гос_номер (Государственный номер), Название, Тип, Состояние_тр (состояние транспортного средства) Сущность обслуживающий персонал включает в себя: Таб_ном (табельный номер сотрудника, ФИО (Фамилия Имя Отчество), состояние (состояние персонала), должность, категория. Сущность Диспетчеры включает в себя: Таб_ном. Сущность Менеджеры включает в себя: Таб_ном. Сущность Водители включает в себя: Таб_ном, состояние. Сущность Заказчики включает в себя: ИНН, Название, Юр_адрес (юридический адрес), Кон_тел (контактный телефон). Сущность Рейс включает в себя: Ном_рей (номер рейса), ад_назнач (адрес назначения), ад_отпр (адрес отправления), Исполнитель, Ном_накл (номер накладной). Сущность Заказ включает в себя: Ном_зак (номер заказа), стоимость, Ад_назнач (адрес назначения), Ад_отпр (адрес отправления). Сущность Расписание включает в себя: Ном_расп (номер расписания), Таб_ном (табельный номер водителя), Гос_ном (государственный номер транспортного средства), Ном_рейса, Ном_зак (номер заказа), Маршрут. Связь между сущностями Сотрудники, Менеджеры, Диспетчеры и Водители осуществляется по типу Супер тип подтип. То, что общее остается в одной таблице. В нашем случае это Таб_ном, ФИО, Должность и Категория. Связь между сущностями Водители и Тр_ср осуществляется через ассоциативную сущность Тр_с_вод. Т.к одним рейсом может выполняться несколько заказов, также как один заказ может выполняться несколькими рейсами, то осуществляем связь М-М между этими сущностями посредствам ассоциативной сущности Рей_зак (рейс-заказ). Т.к в один рейс может отправляться несколько водителей и транспортных средств, на одном транспортном средстве может отправляется несколько водителей, то связь между ними осуществляется через ассоциативную сущность Тр_с_в_рей. Одним рейсом может выполняться несколько заказов, также, как и один заказ может выполняться несколькими рейсами. То связь между сущностями Рейс и заказ осуществляется через ассоциативную сущность Рей_зак. Связь между сущностями Заказ и Заказчик осуществляется посредством ассоциативной сущности Заз_заказ. Т.к менеджер формирует список заказов, то связь между Менеджером и Заказом осуществляется через ассоциативную сущность М_Заказ. Расписание формируется на основание сущности Заказы и ассоциативной сущности Тр_с_в_рейс. На рис. 1.2 изображена Логическая модель базы данных (см. рис 1.2). Рисунок 2.1 Логическая модель базы данных.

Анализ предметной области

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

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

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

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

Рис. 2.2. Объектно-атрибутивное представление предметной области

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

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

Рис. 23. Общее представление идеальной объектной модели данных

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

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

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

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

  • [1] Вопросы разработки информационной системы в целом не являются предметом рассмотрения данного учебника.
  • [2] Документы могут являться объектами предметной области только в случае разработки информационной системы документооборота или при необходимости хранения в базе данных отдельных документов, реализуя элементарные задачи документооборота.

ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

В качестве предметной области выбрано коммерческое предприятие «Мебель под заказ», которое занимается производством мебельной продукции под заказ. Информационная система (ИС) данного коммерческого предприятия занимается обслуживанием процесса производства.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цех. Атрибуты цеха — код участка, название, номер участка, код оборудования.

Поставщик. Атрибуты поставщиков — код поставщика, объем поставки, дата поставки, наименование поставки, наименование поставщика, адрес, телефон.

Сырье. Атрибуты сырья — код сырья, наименование, ед изм (л, шт., кг), количество, гарантия, стоимость_ед.

Детали. Атрибуты детали — код детали, название, размер, номер участка.

Изделия. Атрибуты изделия — код изделия, название, номер участка, размер, количество.

Покрытие. Атрибуты покрытия — номер покрытия, номер участка, наименование изделия, количество.

Сушка. Атрибуты сушки — номер участка, наименование изделия, количество.

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

Контроль качества. Атрибуты контроля качества — номер проверки, деталь, изделие, продукция, ГОСТ.

Сотрудник. Атрибуты сотрудников — код сотрудника, ФИО, дата рождения, данные паспорта, адрес, телефон.

Заказ. Атрибуты заказа — код заказа, наименование продукции, количество, дата заказа.

Реализация. Атрибуты реализации — номер реализации, объем, дата реализации, вид продукции, номер выпуска, цена за единицу продукции.

Система создается для обслуживания следующих групп пользователей:

  • • руководство предприятия;
  • • начальники участков;
  • • поставщики;
  • • заказчики;
  • • сотрудники отделов.

Функциональные возможности:

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

Готовые запросы:

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

Выбор СУБД и других программных средств. Анализ информационных задач показывает, что для реализации требуемых функций подходят почти все СУБД для ПЭВМ (Oracle, Clipper, MS SQL Server, MS Access и др.). Все они поддерживают реляционную модель данных и предоставляют разнообразные возможности для работы с данными.

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

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

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

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

  • В чем вы видите назначение будущей системы?
  • Какие проблемы она должна решить?
  • Какие возможности должна предоставить?
  • Как должна выглядеть?
  • Известны ли вам аналогичные продукты?
  • Будет ли система единичной или тиражируемой?
  • В каких странах она будет работать?
  • Предполагается ли обмен данными с другими существующими продуктами?
  • Сколько пользователей будет работать с системой к моменту реализации и в перспективе?
  • С какими системами и как давно вы работаете?

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

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

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

Процесс формирования и анализа требований к ПО

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *