5971

Обучение / Re: Методика преподавания структурного-функционального анализа

« : 19 Декабря 2006, 23:11:40 »

Понимаешь, тема в приниципе не важна. Обычно все варианты лежат на поверхности: торговля, простое сборочное производство из комплектующих, что-то связанное с вузами: отдел кадров, ведение зарплаты, и т.п.
В целом я бы не сказал, что студенты не понимают своих заданий. Они порой увлеченно дискутируют, однако результат я оцениваю уже на дипломе, т.е. спустя 2 года на защитах курсовых и дипломов. И вот тут видно - бааааальшие проблемы.
В чем тут проблема, только ли в студентах или преподавании. На 4 курсе уних есть предмет проектирование ИС, веду не я:-) Их там заставляют делать DFD по Вендрову. Вендрова знаю лично. Человек интересный, но практикум у него так себе.
Ну да ладно я отвлекся.

Думаю надо сделать так:
1 занятие. Уяснение задания. Выработка цели, построение иерархии целей и задач.
Например:

3) автоматизировать обработку информации при следующих бизнес-операциях:
1)   прием товара от поставщиков (ввод данных приходной накладной);
2)   выдача товара в торговый зал (ввод данных о расходе и оформление расходной накладной),
3)   списание товара  (ввод данных о списании и оформление  акта о списании);
4)   переоценка товара (ввод данных о новой цене заданного товара, групповое изменение цены с заданным коэффициентом),
5)   передача устаревших документов в архив (накладные и акты за истекший финансовый год должны быть скопированы в архив и удалены из текущей БД);

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

помимо этого стоит подумать над структурой документов: накладных, форм отчетов и т.п. Студенту предлагается сделать их самостоятельно по аналогии и в упрощенной форме

На базе этого этапа, можно потребовать разработать скажем контекст для ПРиема товаров, или даже провести требуемую декомпозицию с использованием IDEF0 и IDEF3

продолжение следует

5972

UML SysML и пр. / Re: Кому, зачем и когда нужен UML

« : 19 Декабря 2006, 22:55:49 »

Странно куда-то исчез пост.

Ну да ладно.

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

you are welcome, прошу высказываться за и против

А вот насколько они помогают - это уже тема дисера.

на докторскую потянет? А то можно занятся:-))

5973

Примеры / Re: Micro-CRM

« : 19 Декабря 2006, 21:08:13 »

1. Должно ли данное web-приложение быть полностью самостоятельным или оно должно встраиваться в существующую систему. Если самостоятельное - то проще. Навороты к интерфейсу как я понимаю не важны.
Должна существовать первичная страница авторизации и далее основная форма-журнал

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

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

4.Насколько мы ограничены сроками (имхо праздник на носу), если это учебный процесс - не попытаться ли реализовать его в нашем Hydra проекте?

5. автоматическая рассылка имайл задолжникам вызывает самое большое затруднение

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

5974

Сообщество Аналитиков / Re: Присоединение к Сообществу Аналитиков России

« : 19 Декабря 2006, 20:40:16 »

Мой профиль: http://EGaliaskarov.moikrug.ru/
Цели -
1.всемерно помогать в администрировании сайта и оказывать техническую помощь сообществу
2. участвовать в проектах дабы обучаться и может быть:-) обогащаться
3. вести научные, филосовские и прочие заумные беседы на форуме

5975

Обучение / Re: Методика преподавания структурного-функционального анализа

« : 19 Декабря 2006, 18:56:43 »

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

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

5976

UML SysML и пр. / Кому, зачем и когда нужен UML

« : 19 Декабря 2006, 13:57:08 »

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

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

Итак некая компания Х в городе Н занимается производством КИС. Проект возник как ответ на веления времени и был реализован на одном из предприятий страны С. Мало по малу другие компании и организации страны С стали интересоваться КИС. Это так сказать предыстория.

Беседа эе с коллекгами заключалась в том, что можно и нужно ли использовать UML в проектировании КИС, и если да, то как это возможно.
Мои оппоненты весьма не глупые люди с богатым опытом программирования и работы в разных ИТ-компаниях, высказали мысль, что UML и многие другие методики и языки моделирования - все это красивая игрушка для пускания пыли в глаза заказчику, не более.
Мотивация. КИС - сложная система с огромным количеством классов и связей между ними. Как можно представить даже часть такой системы в виде ДК и как отобразить все многообразией связей, которые возникают между объектами. Т.е. мысль такая - при реализации ДК даже небольшой части системы мы получим такую огромную диаграмму с такми количеством связей, что вся ее изобразительная значимость, ее информативность окажется бесполезной. И потом - зачем тратить огромное, гигантское количество времени на подготовку ДК, чтобы в будущем в общем никак ею не воспользоваться. При этом надо ее постоянно сопровождать, обновлять, если происходят изменения кода и т.д. и т.п.
Была высказана мысль, что время, которое потратит человек на создание такой модели существенно больше, чем он бы потратил на простое кодирование. Митивация: грамотный человек умеет строить код и без предварительного моделирования, а не грамотный - ну нам такие не нужны... Проводится мысль - может UML и неплохо, но для его овладения нужно много времени и средств, а его преподавания не поставлено на такую основу, как скажем химия, математика, физика, бухгалтерский учет и т.п. Поэтому - использование UML бессмысленно, бесполезно и даже вредно.
В их рассуждениях я заметил одну неточность на мой взгляд. Мои коллеги путают язык UML и процесс проектирования и кодирования(реализации). Я высказал мысль, что просто в компании нет грамотного процесса производства, не отработана его технологичность, а возможно просто пока вы либо не доросли до этого, либо в данной ситуации это вам не подходит - маленький коллектив - смешение ролей, когда программист является и системным аналитиком и проектировщиком и кодером и тестировщиком, а порой и внедренцем.

Очень хотелось бы выслушать ваши комментарии, а также тех, кто имеет опыт или просто знает, ответить на вопрос:
А действительно кто-то использует UML грамотно и хорошо и на всех стадиях проекта, причем проекта очень больших и сложных систем? Или UML все-таки инструмент обучения, возможно инструмент бизнес-аналитиков, и возможно рассчитан на небольшие, обозримые проекты...

5977

Обучение / Re: Методика преподавания структурного-функционального анализа

« : 19 Декабря 2006, 12:57:52 »

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

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

Для начала нужно определить цель дисциплины как таковой:
Теория информационных процессов и систем, содержания ГОС 230201:

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

Его содержание мне не нравится, не наше оно. Это калька с ГОС ориентированного впервую очередь на ИСУ - и основан на ГОС Бауманки И ЛЭИ

Однако содеражание теоретического курса в нашем случае не так важно. Я его меняю процентов на 30 ежегодно: узнаю новое, появляется новая литература, новое понимание и т.д.

Что есть в содержании практикума:
1. Постановка задачи (выдается небольшое задание на моделирование и предлагается составить общее описание системы или проблемы, приветствуется дополнительный сбор информации: опрос пользователей, изучение аналогов, составление вопросников и опрос заказчика - т.е. преподавателя в нашей ситуации - уже здесь видна проблема - проблема времени, если реально общаться с каждой парой студентов (8-9 пар на преподавателя) то очевидны проблемы времени и качества ответа)
На этой стадии выясняется цель изучаемой системы, ее назначение, круг пользователей, заинтересованных лиц, обязанности пользователей, их потребности в самом общем виде, выделяются функции системы, определяется состав документов, форм, отчетов. Система изучается как есть либо как должно быть. Определяется цель моделирования, выделяются точки зрения, структуризируются точки зрения, выделяется наиболее значимая. Определяются границы моделирования и самые общие ограничения. Основной инструмент на данном этапе - здравый смысл, знания математической логики, теории множеств, отношений и т.п.
Представляются примеры проведения опросов, анализа информации по репрезентативной выборке документов и т.п.
2. Начальный этап моделирования - использую IDEF0, но может и вообще отойду от него, используется IDEF3.
Строится контекст и диаграмма нулевого уровня, выявляются взаимосвязи, точно определяется что на выходе, что на входе, что управление а что механизм. Итерационно связана с 1 задачей. Основная цель - выделение подсистем, определение закона функционирования
3. Детальный этап моделирование - разделение по подсистемам и переход к DFD, рассмотрение и структуризация потоков данных, алгоритмов обработки данных, ведения словаря данных, составление миниспецификаций процессов в самом общем виде - результат функциональные требования, понимание структуры данных, бизнес-правила
4. Моделирование данных - основанное на документах либо перенос из DFD модели (здесь пока не ограничиваю)
5. Трансформация модели данных в Access с целью посмотреть получается нормально или нет - то есть быстрое прототипирование

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

Примеры заданий:
Пример 1

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

Пример2

Домоуправление (Д/У) осуществляет контроль состояния и обслуживание принадлежащего ему жилого фонда. Д/У выполняет заявки жильцов на текущий и экстренный ремонт квартир. Д/У регистрирует проживающих и вновь прибывших в домовых книгах, где указывается адрес дома, номер и площадь квартиры,  проживающие на данной площади (ФИО и дата рождения), дата регистрации. Д/У ежемесячно начисляет квартирную плату.  Д/У ведет паспорт на каждую единицу жилого фонда, где указан адрес дома, дата ввода в эксплуатацию, тип строения, этажность, тип перекрытий, тип кровли, тип системы отопления, тип квартир, число квартир каждого типа. Д/У также проводит плановый и капитальный ремонт жилого фонда.
 Должностные обязанности штатных сотрудников:
•   Начальник Д/У осуществляет общее руководство деятельностью Д/У;
•   Главный инженер отвечает за техническое состояние жилого фонда – руководит текущими и капитальными ремонтами, входит в состав комиссии по приему новых домов на баланс Д/У;
•   Заместитель начальника Д/У по жилью ведет паспорт на каждый дом, регистрирует новые единицы жилого фонда и составляет план капитального ремонта домов, срок эксплуатации которых превысил нормативный;
•   Паспортист осуществляет регистрацию жильцов и ведет домовые книги;
•   Бухгалтерия начисляет квартирную плату в зависимости от площади и числа проживающих в квартире;
•   Диспетчер принимает заявки от жильцов, выполняет ежедневное распределение бригад на работы в соответствии с поступившими  заявками;
•   Бригады рабочих различных специальностей – слесарей, сантехников, строителей, электриков, которыми руководят бригадиры.

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

Вариант 1. Учет наличия и движения товаров в торговой организации.
В процессе учета участвуют специалисты следующих подразделений: склада, бухгалтерии, группы маркетинга, торгового зала. Товары подразделяются на товарные группы (бытовая техника, обувь, одежда, электроника и т.д.). Внутри группы товары отличаются наименованием, маркой, производителем, поставщиком и т.д.
1.1      Модуль «Учет движения товаров на складе».
Программное обеспечение АРМ кладовщика должно позволять -
1) хранить необходимую информацию о каждом виде товара, имеющегося на складе; хранить справочник нормативов запаса товаров по каждой группе товара;
2) выводить в удобной форме данные по следующим запросам пользователя:
-   поиск  данных о заданном товаре по его номенклатурному номеру;
-   выборка всех данных о товарах с сортировкой  по товарным группам;
-   выборка номенклатурного номера и наименования товаров, количество которых на складе меньше заданной нормы запаса;
-   расчет суммарной стоимости товаров, принятых и отпущенных за текущий день;
-   расчет стоимости товаров, отпущенных по заданной расходной накладной;
-   диаграмма - стоимость товаров с группировкой по товарным группам;
3) автоматизировать обработку информации при следующих бизнес-операциях:
1)   прием товара от поставщиков (ввод данных приходной накладной);
2)   выдача товара в торговый зал (ввод данных о расходе и оформление расходной накладной),
3)   списание товара  (ввод данных о списании и оформление  акта о списании);
4)   переоценка товара (ввод данных о новой цене заданного товара, групповое изменение цены с заданным коэффициентом),
5)   передача устаревших документов в архив (накладные и акты за истекший финансовый год должны быть скопированы в архив и удалены из текущей БД);
4) вывод выходных документов на печать (расходная накладная, карточка складского учета, акт о списании);
5) вывод сведений об авторе и назначении программы.

1.2      Модуль «Работа с товарами и покупателями в торговом зале»
Служащие торгового зала выписывают счет на покупку, товарный чек (накладную), ведут книгу продаж. Отпуск товаров покупателям ведется только через торговый зал.
ПО АРМ продавца должно позволять -
1)   хранить необходимую информацию о каждом виде товара, имеющегося в каждом  отделе торгового зала;  информацию о распределении продавцов по отделам;
2)   выводить в удобной форме данные по следующим запросам пользователя:
-   поиск  сведений о продаже заданного товара по номеру товарного чека;
-   выборка названия, цены и рекламных сведений о товарах, с сортировкой по   фирмам - производителям;
-   выборка данных о покупках заданного клиента по фамилии (названию фирмы) покупателя;
-   вывод списка покупателей в алфавитном порядке;
-   расчет суммарной стоимости товаров, отпущенных данному клиенту за год;
-   диаграмма - сумма продаж за заданный период времени с группировкой по товарным группам;
3) автоматизировать обработку информации при следующих бизнес-операциях:
   прием товара со склада (ввод данных накладной);
   продажа товара покупателю (ввод данных о расходе, оформление товарного чека; оформление требования на склад, если данный товар в зале закончился),
   оформление витрин торгового зала с помощью ценников и рекламных листовок;
   передача устаревших документов в архив (записи в книге продаж за истекший финансовый год должны быть скопированы в архив и удалены из текущей БД);
4) вывод выходных документов на печать (товарный чек, ценник, рекламный листок, требование);
5) вывод сведений об авторе и назначении программы.

1.3      Модуль «Работа с поставщиками и анализ продаж в группе маркетинга»
Маркетологи еженедельно анализируют сбыт товаров,  формируют прайс-листы, поддерживают контакты с поставщиками, информируют торговый зал и кладовщика об изменении цен на товары.
ПО АРМ маркетолога должно позволять -
1)   хранить необходимую информацию о каждом виде продаваемого товара; информацию о фирмах – оптовых поставщиках товаров;
2)   выводить в удобной форме данные по следующим запросам пользователя:
-   поиск  сведений о заданном поставщике по его названию или ИНН;
-   выборка названия и цены товаров, отсортированные по городам и поставщикам;
-   выборка данных о поставках заданного поставщика по его ИНН;
-   расчет суммарной стоимости продаж с группировкой по неделям (месяцам) и поставщикам (перекрестный);
-   расчет количества продаж каждого вида товаров за заданный период (от …до…);
-   определение 10 самых ходовых товаров (количество их продаж максимально);
3) автоматизировать обработку информации при следующих бизнес-операциях:
   переоценка товаров (изменение цены заданного товара, изменение цены на группу товаров,  формирование нового прайс-листа);
   анализ сбыта товаров (формирование еженедельной ведомости продаж с группировкой по товарам и их группам, построение диаграммы продаж или диаграммы цена\спрос),
   установление деловых контактов с новым поставщиком (ввод данных о поставщике и его товарах);
   разрыв контактов с заданным поставщиком (удаление сведений о заданном поставщике);
4) выводить выходные документы на печать (прайс-листы по группам товаров, ведомость продаж;  диаграмма продаж, перекрестный);
5) выводить сведения об авторе и назначении программы.

5978

Теория моделирования и нотации / Re: Что такое декомпозиция

« : 18 Декабря 2006, 11:41:48 »

Если можно подведу итог дискуссии.

Итак вариант использования, прецедент, use case, процесс - конечная НЕДЕЛИМАЯ последовательность событий, возникающих в системе для удовлетворения потребности действующего лица, инициирующего эту последовательность.
В самом определении присутствует слово НЕДЕЛИМАЯ, а значит имеющая смысл лишь только как целое. Если рассматривать части такого процесса, как самостоятельные элементы, теряется смысл использования. "Не выкинишь слов из песни". При этом можно считать, что при успешном завершении процесса участник достигает цели использования, а при не успешном не достигает. Т.е. в определенном смысле, участник заранее не знает, какой результат принесет вариант использования. Очевидно, что он ожидает успешность выполнения, но возможен и сбой. Таким образом, ВИ в определенной степени похож на транзакцию, которая либо осуществляется либо нет.
При этом конечность и неделимость не припятствует выделению другой последовательности внутри рассматриваемого ВИ. Здесь просматривается аналогия с вложенными транзакциями.

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

5979

RUP EUP AUP OpenUP / Re: Покрытие RUP инструментами от Borland и проч.

« : 17 Декабря 2006, 19:41:28 »

Я не испытывал трудности при работе с CaliberRM, мне он даже больше нраавился чем RequisitePro. Да и инсталляция его достаточно простая. Не знаю чем конкретно вызвана у вас проблема инсталляции серевера, но даже в бытность работы в Борланд, я с проблемами инсталляции у заказчиков на сталкивался. Посмотрите внимательно на ReadMe, может просто с .NET проблемы? И кстати какая у вас версия CaliberRM?
ReqPro нужно ставить более свежий, чтобы он работал с Word2003, не ниже 15 релиза. В 13 был дефект работы с офисом отличным от английского. Сейчас уже есть версия 7 ReqPro, но я ее еще не ставил. Как поставлю -- поделюсь впечатлениями, если они возникнут, учитывая что функциональность его не растет в последнее время, и GUI у него конечно не очень приятный, по сравнению с CaliberRM.

Ах, Юрий. Проблема вся в том, где взять эти новые инструменты. У нас в Иваново с этим не так уж и хорошо, поскольку продукты экзотические, стоят дорого. Лицензионные версии - проблема, академические - проблема обновления. в 2004 я был на курсах по UML, там мне досталась версия 2003. С тех пор ни одного обновления, может каким-то способом поможете? Если что, контакты есть.. ICQ, email, либо через Сашу Байкина..

5980

Теория моделирования и нотации / Re: Что такое декомпозиция

« : 17 Декабря 2006, 19:36:22 »

1. В старом форуме я приводил ссылку на статью "Why Usa cases are not functions", там можно и посмотреть более детально.

Юрий, спасибо. Не можешь (можете? как лучше:-)) напомнить ссылку, старый форум скорее всего почил в бозе

2. В общем виде можно сказать, что UC это в первую очередь ЦЕЛЬ ... а не действие. И именно функция может быть декомпозирована до элементарных операций. Причем, говоря о декомпозиции, подразумеваем, что функция строго состоит из последовательности операций. UC тоже могут быть декомпозированы, но в терминах декомпозиции ЦЕЛЕЙ пользователя по отношению к системе. Хотя более корректно говорить не о декомпозиции целей, а о контексте, который задает например outmost UC для других UC ... это очень хорошо показано у Коберна, когда он вводит понятие уровней юзкейсов. Близко к этому -- RUPовское Business UC - System UC. BUC -- по сути контекст для SysUC. Эта грань -- она с одной стороны достаточно четкая, с другой стороны (особенно с позиций функционального анализа) может показаться не вполне четкой. Но она еть :-). Например, можно выстроить функциональную декомпозицию по ЦЕЛЯМ, но сложно (или невозможно) будет выстроить "иерархию" UC по функциям, ввиду ортогоноальности природы UC и функций. Да, у них может быть пересечение (если описывать функционально предметную оласть и ее же потом описать на UC), но повторюсь, что в одном UC может присутствовать множество функций и наоборот.

Интересно. Однако в чем ортогональность описания множеством функция и множеством UC? Насколько я помню, есть ортогональность структурного подхода и объектного подхода. Но UC - к ООП никакого вроде отношения не имеет?
Далее: цель - стратегия,
           функция - тактика?
Так стоит понимать?
Вообще в программировании я понимаю под функцией некоторое атомарное действие, имеющее одну тему: соединиться с сервером, выбрать БД, подготовить запрос, выполнить запрос, вывести данные запроса и т.п.
Однако в моей постановке вопроса все-таки имеется ввиду не функция программы, а функция = функциональный блок = процесс. В чем все-таки отличие между функцией и процессом, что кого включает? Опять же у меня есть некоторый ответ, но он меня не удовлетворяет, поскольку я не могу подобрать хороших примеров и доказательств.




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

Вот Keen_G считает, что это одно и тоже по сути. Другие оппоненты это отрицают.

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

Например, можно выстроить функциональную декомпозицию по ЦЕЛЯМ, но сложно (или невозможно) будет выстроить "иерархию" UC по функциям, ввиду ортогоноальности природы UC и функций.

Да мысль понятна, действительно, по UC не выстроешь. Можно ли выдвинуть такую мысль: ВИ это потребности пользователей, это разные точки зрения на роль системы (в отличии от необходимости единой точки зрения в SADT)....?

5981

Теория моделирования и нотации / Re: Что такое декомпозиция

« : 17 Декабря 2006, 19:17:24 »

To Keen_G

ИМХО надо в другую тему перенести посты, а то от бизнес-процессов далековато ушли

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

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

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

Keen_G, а чем разбиение цели на подцели, отличается от разбиение функции на подфункции и действия?

5982

Теория моделирования и нотации / Re: Что такое декомпозиция

« : 17 Декабря 2006, 12:43:55 »

ВИ ничего не "возвращает".

Вот те на, а что же он возвращает? Дает? создает в ходе исполнения?

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

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

И про декомпозицию, кстати, не слово. Насколько я понимаю, тут-то весь перец. Функция IDEF декомпозируема, ВИ не декомпозируемый.
Функция IDEF = активность, деятельность, работа, процесс, аналогично в DFD.
Что есть ВИ - работа - сценарий или совокупность сценариев.
Функциональный блок IDEF, DFD - то же есть совокупоность работ и сценариев, единственная разница, что описывается не последовательность действий, а логика взаимоотношения действий.

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

ВИ - есть последовательность действий, рабочий процесс, работа, алгоритм = синоним сценарию IDEF3 (workflow)

Разница примерно в следующем - первое дает взаимное расположение например улиц и объектов на улицах, второе как из пункта А попасть в пункт Б - маршрут, основанный на карте, созданной в первом случае...

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

Заканчиваю:
Вывод:
1. Ваши замечание в целом понятны, но ответа фактически не содержат. Доказательная база слишком скудна. Не репрезентативной выборки

2. Про декомпозицию не сказали не слова. Хотя цель вопроса уточнить понятие декомпозиция, и перенести его на UML, где и в каком контектсе его использовать. Почему более детальное рассмотрение чего-либо не есть суть декомпозиции?

5983

Системный Анализ и Требования / Re: Основы системного анализа

« : 16 Декабря 2006, 22:58:33 »

Вот нашел ссылку на статьи из Большой советской энциклопедии по системам, системному анализу, системному подходу и т.п. Обнаружил с удивлением, что мы былипервыми, кто применил СА на практике :-)
http://bse.chemport.ru/index.php?l1=%F1

5984

Системный Анализ и Требования / Re: Основы системного анализа

« : 16 Декабря 2006, 22:30:30 »

Сорри за позднюю реплику.
Не могу согласится с последним абзацем. Думаю это вряд ли, это похоже на философию идеализма Канта. Если принять ее за основу, мы некогда не сможем договорится.
Напомню. Кант считал, что все, что нас окружает есть плод нашего воображения или нашего конкретного понимания мира. Т.е. как устроен реальный мир в реальности никто не знает, поскольку какждый имеет собственную модель окружающего мира. Есть некоторые элементы этих моделей, которые оказываются схожими или которые принимаются за истину. Поскольку модель восприятия мира во многом определяется также и воспитание, цель воспитания привить личной модели черты общего коллективного понимания...
Тут можно спорить или просто не принимать это, но к удивлению, очень многие люди разделяют такую концепцию. Может они и правы. Черт возьми! :-))

По первому обзацу. По субботам бываю в бани у друга. Часто имеем такие интеллектуальные беседы. Обсуждали вопрос, почему зачастую выпускники специализированных кафедр по ИТ менее успешны тех выпускников, которые заканчивали другие специальности, не связанные с ИТ, но пришедшие в ИТ по интересу.
Сделали так вывод. Многие студенты, идущие в ИТ кафедры полагаю, стоит им только поступить на эту специальность и у них весь ИТ мир в кармане. Однако когда выходят в жизнь вдруг оказывается, что никому особо не интересно, что данный парень отлично разбирается св SQL запросах, гораздо более интересно решение некоторой конкретной задачи. А для ее решения оказывается знания SQL и не достаточно, нужны еще другие знания, а их то оказывается и нет. Т.е. владение ИТ - это интсрументальные знания, но инструментальные знания не научат человека делать что-то. Т.е. мы можем владеть топором, однако это не значит мы сумеем построить дом. Это необходимое условие, но недостаточное.
Это, конечно, мое личное мнение.

5985

Теория моделирования и нотации / Что такое декомпозиция

« : 16 Декабря 2006, 21:45:34 »

Основой любого аналитического процесса или просто анализа есть декомпозиция.
Возьму на себя смелость сформулировать понятие декомпозиция.
Декомпозиция - это процесс упрощения чего-либо без потери целостности.
Существуют разные виды декомпозиции: функциональная, структурная, объектная, по физическому процессу.
Декомпозиция предполагает иерархическое подчинение нижних уровней верхним. Декомпозиция не меняет сути декомпозируемого объекта или явления, а лишь уточняет его, упрощает, помогает снять неопределенность или локализовать ее.
Когда говорят о структурных методах анализа, декомпозиция воспринимается как обычное явление, сопуствующее методикам структурных методик.
Однако когда мы переходим к вариантам использованиям, нам рекомендуют быть очень внимательным к этому понятию.
К примеру в книге Эрика Нейбурга и Роберта Максимчука "Проектирование баз данных с помощью UML" издательства Вильямс  от 2002 года на стр. 45 читаем "на рис.3.5 представлена общая модель бизнес-прецендентов (модель содержит 1 ВИ::Обслуживание резидента и большое количесвто актеров). Прецедент "Обслуживание резидента" содержит множество ВИ и видов деятельности. Заметим, что здесь речь идет не о функциональной декомпозиции, а просто о более высоком уровне абстракуции, который позволит лучше понять контекст".
Однако, если бы я проводил анализ, используя IDEF0, то действовал примерно так.
Контекст - Обслуживание резидента
О диаграмма - Оказание медпомощи, Получение счета, Выполнение постановлений, Управление клиническими записями, Ответ на запрос
Каждая из выше перечисленных функций может быть декомпозирована вплоть до элементарных действий.
В чем тогда разница? Чем отличается ВИ в UML и функция в IDEF0 или другой структурной методики?

ВИ всегда возвращает результат и всегда есть неделимая последовательность действий.
А Функция? разве что-то другое. По определению функция есть результат преобразования аргументов, в чем разница...

Хотелось бы услышать от знающих ответы на поставленные вопросы, желательно с примерами и обоснованием...