Gocapital.ru

Мировой кризис и Я
5 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

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

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

Тема 3.Методы анализа предметных областей информационных систем

Понятие предметной области

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

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

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

К предметной области ИС относятся предметы, объекты, явления реальной действительности, их свойства, функции, отношения между ними.

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

пространственные и временные параметры услуги;

цена услуги и др.

Другим примером предметной области могут служить сотрудники предприятия. В этом случае в ИС будет использоваться следующая информация:

фамилия, имя, отчество сотрудника;

дата его рождения;

служебная характеристика и др.

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

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

Анализ предметной области является первым шагом, с которого начинается разработка ИС.

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

В ходеанализа предметной области разработчики ИС должны:

научиться понимать язык, на котором говорят заказчики;

выяснить требования заказчика к ИС;

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

Для этого разработчики с участием заказчика решают следующие основные задачи:

изучают миссию предприятия, цели деятельности и стратегии их достижения;

исследуют функции предприятия, их распределение между подразделениями предприятия;

выполняют статическое описание предприятия (объектной, функциональной, организационной структуры, структуры управления);

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

моделируют отдельные бизнес-процессы на предприятии.

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

Анализ предметной области и требования к ПО

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

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

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

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

Читать еще:  Анализ состояния основных фондов предприятия

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

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

Анализ деятельности крупной организации, такой как банк с сетью региональных отделений, нефтеперерабатывающий завод или компания, производящая автомобили, дает огромные объемы информации. Из этой информации надо уметь отбирать существенную, а также уметь находить в ней пробелы — области деятельности, информации по которым недостаточно для четкого представления о решаемых задачах. Значит, всю получаемую информацию надо каким-то образом систематизировать. Для систематизации сбора информации о больших организациях и дальнейшей разработки систем, поддерживающих их деятельность , применяется схема Захмана ( автор — John Zachman, [1,2]) или архитектурная схема предприятия (enterprise architecture framework).

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

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

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

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

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

Читать еще:  Анализ внутренних факторов предприятия

11. Анализ предметной области: цели и задачи. Модели предметной области. Формальные определения. Классификация моделей. Методоло

Primary tabs

Forums:

11. Анализ предметной области: цели и задачи. Модели предметной области. Формальные определения. Классификация моделей. Методология IDEF0, синтаксис IDEF0-моделей.

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

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

  1. · понимать язык, на котором говорят заказчики;
  2. · выявить цели их деятельности;
  3. · определить набор решаемых ими задач;
  4. · определить набор сущностей, с которыми приходится иметь дело при решении этих задач.

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

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

Определения=

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


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

Виды моделей

Формальные модели, используемые на этапе анализа предметной области можно разделить на две группы:

  1. · модели, зависящие от подхода к разработке (структурного или объектно-ориентированного);
  2. · модели, не зависящие от подхода к разработке.

Методологии IDEF

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

  1. IDEF0 – методология создания функциональной модели системы (основана на методе SADT Росса);
  2. IDEF1 – методология создания информационной модели системы (основана на реляционной теории Кодда и использовании ER-диаграмм Чена);
  3. IDEF2 – методология создания динамической модели системы;
  4. IDEF3 – методология создания модели потоков работ (обычно используется вместе с диаграммами потоков данных DFD Data flow diagram)

Синтаксис IDEF0-моделей

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

Основные правила

Каждая сторона функционального блока должна иметь стандартное отношение блок/стрелки:

  1. · входные стрелки должны связываться с левой стороной блока;
  2. · управляющие стрелки должны связываться с верхней стороной блока;
  3. · выходные стрелки должны связываться с правой стороной блока;
  4. · стрелки механизма (кроме стрелок вызова) должны указывать вверх и подключаться к нижней стороне блока;
  5. · стрелки вызова механизма должны указывать вниз, подключаться к нижней стороне блока, и помечаться ссылкой на вызываемый блок

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

Сегменты стрелок, за исключением стрелок вызова, должны помечаться существительным или оборотом существительного. Чтобы связать стрелку с меткой, следует использовать «тильду» (

Принцип декомпозиции

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

Читать еще:  Анализ эффективности системы управления

Состав

IDEF0-модели состоят из трех типов документов:

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

Эти документы имеют перекрестные ссылки друг на друга. В методологии IDEF0 существует 6 типов отношений между блоками в пределах одной диаграммы:

  1. · доминирование;
  2. · управление;
  3. · выход — вход;
  4. · обратная связь по управлению;
  5. · обратная связь по входу;
  6. · выход – механизм

Предметная область информационной системы;

Лекция 4 Системный анализ предметной области

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

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

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

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

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

Итак, на первом этапе проектирования необходимо выполнитьcистемный анализ предметной области

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

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

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

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

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

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

Системный анализ должен заканчиваться:

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

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

— описанием входных документов, которые служат основанием для заполнения данными базы данных;

— кратким описанием алгоритмов решения задач;

— описанием выходных документов, которые должны генерироваться в системе.

Ссылка на основную публикацию
Adblock
detector