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

Вот еще декомпозиция по порядку. Не понятно по поиску, правильно ли?

А моделирование определенно чьей точкой зрения?

А моделирование определенно чьей точкой зрения?

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

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

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

И да, как уже отмечал Log  с т.н viewpoint лучше определиться сразу. Иначе размер вашей модели может устремится к бесконечности.

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

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

И да, как уже отмечал Log  с т.н viewpoint лучше определиться сразу. Иначе размер вашей модели может устремится к бесконечности.

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

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

Декомпозиция 1го уровня мне очень не нравится.
Поиск в картотеке как процесс верхнего уровня? Картотека - это только инструмент. Это примерно, как описывая завод сделать процессы верхнего уровня "Работа с компьютером" и "Остальные процессы". Т.е. непосредственному использованию инструмента - не место на верхнем уровне.

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

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

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


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

Декомпозиция 1го уровня мне очень не нравится.
Поиск в картотеке как процесс верхнего уровня? Картотека - это только инструмент. Это примерно, как описывая завод сделать процессы верхнего уровня "Работа с компьютером" и "Остальные процессы". Т.е. непосредственному использованию инструмента - не место на верхнем уровне.

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

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

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


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

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

я вот с этого примера пытался переделать без использования СУБД

и последняя декомпозиция

Совершенно неправильный подход использования IDEF0.
Ошибка начинается с первой диаграммы, А-0. И не надо спешить делать декомпозицию, надо начать с контекстной диаграммы, а не спешить.

IDEF0 - это про моделирование процессов, функций системы, а следовательно нужно думать в категориях процессов, функций (по-английски, activity т.е. деятельность).

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

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

Далее это может быть модель как есть, модель как должно быть.

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

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

Совершенно неправильный подход использования IDEF0.
Ошибка начинается с первой диаграммы, А-0. И не надо спешить делать декомпозицию, надо начать с контекстной диаграммы, а не спешить.

IDEF0 - это про моделирование процессов, функций системы, а следовательно нужно думать в категориях процессов, функций (по-английски, activity т.е. деятельность).

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

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

Далее это может быть модель как есть, модель как должно быть.

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

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

Хорошо что я сюда зашел, спасибо за ответ, буду переосмысливать

Хорошо что я сюда зашел, спасибо за ответ, буду переосмысливать

Могу посоветовать книгу http://dit.isuct.ru/ivt/books/CASE/case8/sadt_index.htm (там есть часть 5 - уроки)
Также можно посмотреть сам стандарт http://dit.isuct.ru/ivt/books/CASE/case10/idef0/index.htm

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

IDEF0 реализует системный подход, подход сверху-вниз. Если перевести на уровень написания программы, то Вы начинаете с того, что пишите собственно контуры программы, что-то типа:

program factorial;
uses crt;
begin
end.

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

Потом вы ее декомпозируете на составные более детальные функции и процедуры:

program factorial;
uses crt;
procedure datainput;
begin
end;
procedure dataoutput;
begin
end;
procedure factbycycle;
begin
end;
begin

datainput;
factbycycle;
dataoutput;

end.

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

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

При этом  входы - то, что потребляется или преобразуется для получения выхода.
Управления - то, что регламентирует, ограничивает, управляет, определяет ход преобразования входа в выход. И Нужно искать такое управление, которое будет полезным для дальнейшего, а не просто Законодательство РФ, но конкретно Статья 3, пункт 4, абзац 5
Механизмы - ресурсы, то что помогает преобразовать вход в выход, возможные пользователи, участники процесса, инструменты, и т.п.

Могу посоветовать книгу http://dit.isuct.ru/ivt/books/CASE/case8/sadt_index.htm (там есть часть 5 - уроки)
Также можно посмотреть сам стандарт http://dit.isuct.ru/ivt/books/CASE/case10/idef0/index.htm

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

IDEF0 реализует системный подход, подход сверху-вниз. Если перевести на уровень написания программы, то Вы начинаете с того, что пишите собственно контуры программы, что-то типа:

program factorial;
uses crt;
begin
end.

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

Потом вы ее декомпозируете на составные более детальные функции и процедуры:

program factorial;
uses crt;
procedure datainput;
begin
end;
procedure dataoutput;
begin
end;
procedure factbycycle;
begin
end;
begin

datainput;
factbycycle;
dataoutput;

end.

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

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

При этом  входы - то, что потребляется или преобразуется для получения выхода.
Управления - то, что регламентирует, ограничивает, управляет, определяет ход преобразования входа в выход. И Нужно искать такое управление, которое будет полезным для дальнейшего, а не просто Законодательство РФ, но конкретно Статья 3, пункт 4, абзац 5
Механизмы - ресурсы, то что помогает преобразовать вход в выход, возможные пользователи, участники процесса, инструменты, и т.п.

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

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