4426

Управление Проектом / Re: Руководитель проекта, как им стать?

« : 06 Января 2008, 13:18:13 »

А у кого есть книга в электронном виде?

4427

Тестирование / Re: Место тестирования в процессе разработки ПО

« : 06 Января 2008, 13:13:48 »

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

4428

Обучение / Re: Опыт преподавания структурного анализа

« : 06 Января 2008, 13:07:14 »

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

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

То что коррекция нужна, это понятно. С какого места? Наверное пока лучше начать с видения.

4429

Примеры / Re: Моделирование системы тестирования

« : 06 Января 2008, 13:02:25 »

Никто не фиксирует, уже прошли миллионы лет назад, возьмут данные из другой БД и пакетно зальют в эту созданную структуру. И надо только ПРОСМАТРИВАТЬ.

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

4430

Примеры / Re: Моделирование системы тестирования

« : 06 Января 2008, 12:52:42 »

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

Если коллеге Martynov интересно развиваться именно в этом направлении - т.е. RR и DM, то советую почитать книгу Нейбург и Максимчук "Проектирование БД с помощью UML".

Пацаны, я проблемы не понял и вопросов не понял. Что нужно? Как рисовать стрелочку и куда ее направлять? А зачем енто нужно на концептуальной модели? Это же у же реализация. Наличие или отсутствие навигации есть реализация.

Я обычно не парюсь и использую двунаправленную навигацию - это показывается ОТСУТСТВИЕМ стрелочек в любую сторону.

Вот что пишет достопочтенный Рамбо Буч и Якобсон в своей эпохальной книге UML руководство пользователей.

Навигация. С помощью простой, не содержащей дополнений ассоциации между двумя классами (скажем, Книга и Библиотека) можно осуществлять навигацию между их объектами. Если явно не оговорено противное, то навигация по ассоциации может осуществляться в обоих направлениях. Но бывают случаи, когда необходимо ограничить ее только одним направлением. Например, как показано на рис. 10.3, при моделировании сервисов операционной системы можно столкнуться с ассоциацией между объектами User (пользователь) и Password (пароль). Если дан объект класса User, то нужно уметь находить соответствующие объекты класса Password, но обратное недопустимо, то есть не должно быть возможности по паролю определить пользователя. Направление ассоциации можно выразить явно, дополнив ее стрелкой, указывающей на допустимое направление движения.

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

Про композицию.

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

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

Это означает, что в случае композитного агрегирования объект в любой момент времени может быть частью только одного композита. Например, в оконной системе класс Frame (Рама) принадлежит только одному классу Window (Окно), тогда как при простом агрегировании "часть" может принадлежать одновременно нескольким "целым". Скажем, в модели дома объект Стена может принадлежать нескольким объектам Комната.

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

Как показано на рис. 10.7, композиция является просто частным случаем ассоциации и обозначается путем дополнения ассоциации закрашенным ромбом на конце со стороны "целого".

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

Агрегирование

Агрегирование. Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа "часть/целое", в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). Отношение такого типа называют агрегированием; оно причислено к отношениям типа "имеет" (с учетом того, что объект-целое имеет несколько объектов-частей). Агрегирование является частным случаем ассоциации и изображается в виде простой ассоциации с незакрашенным ромбом со стороны "целого", как показано на рис. 5.7. Существует много важных разновидностей этого отношения (см. главу 10).

Примечание: Незакрашенный ромб отличает "целое" от "части"- - и только. Эта простая форма агрегирования является чисто концептуальной; она не влияет на результат навигации по ассоциации между целым и его частями и не подразумевает наличия между ними какой-либо зависимости по времени жизни.

По-моему не прибавишь не убавишь

4431

О Сайте и Форуме / Re: Поздравляем с НГ и Рождеством

« : 06 Января 2008, 12:24:12 »

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

4432

Примеры / Re: Моделирование системы тестирования

« : 05 Января 2008, 23:54:38 »

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

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

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

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

Т.е. вариантов море.

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

Почитайте Крёнке Теория и практика баз данных - по-моему лучшей книги не придумаешь

4433

Примеры / Re: Моделирование системы тестирования

« : 05 Января 2008, 22:42:55 »

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

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

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

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

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

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

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

Потому предлагаю сначала описать эту предметную область как можно более точно и полно.

4434

Примеры / Re: Моделирование системы тестирования

« : 05 Января 2008, 22:05:04 »

Для того, чтобы понять направление  стрелки, т.е. навигация, полезно построить OCL выражения.

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

4435

Примеры / Re: Моделирование системы тестирования

« : 05 Января 2008, 14:21:53 »

To Martynov

Понимаете следует определиться. Вы проектируете базу данных или приложение?

Ваша диаграмма классов - концептуальная, т.е. содержит классы-сущности. Лишена операций. Говорить о реализации пока преждевременно. Класс концептуальный может мигрировать в класс приложения, обрастая операциями, но может и не мигрировать.

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

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

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

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

Пока же Вы определили какую информацию будете хранить. Можно добавить в модель OCL выражения. Для быстрого прототипирования задачи можно воспользоваться технологией MDA в ее реализации BOLD for Delphi.

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

4436

Примеры / Re: Моделирование системы тестирования

« : 05 Января 2008, 01:52:39 »

Ну не совсем так.

Вообще если мы говорим об моделеи данных или реализации в виде SQL БД, то всем этим управляют процедуры ограничения целостности: стандартные и не стандартные.

Композиция говорит о наличии обязательного родителя и возможно обязательного потомка. Т.е. скажем вы не сможете удалить группу пока в ней есть хотя бы один студент. Более того вы не сможете переназначить этого студенту в другую группы например. Однако если дочерняя сущность необязательна (0, 1 или много) особых проблем нет. Нет особой разницы и между агрегацией и композицией. Просто при использовании UML для моделирование ER, композиция используется, а агрегация нет. Вообще где-то у гуру читал, что агрегацию следовало бы запретить как вредный элемент :-)

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

Ну и смотрите. разве номер студенческого может повторяться  в разных группах?

4437

Примеры / Re: Моделирование системы тестирования

« : 04 Января 2008, 23:55:25 »

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

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

Результат тестирование не часть студента, а часть работы студента. Таким образом связь композиция тут не допустима, здесь явная ассоциация. Я бы вообще сделал квалифицированную ассоциацию м/у Студент и Тест с классом-ассоциацией Результат тестирования.

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

4438

Примеры / Re: Задачи на построение диаграммы вариантов использования

« : 04 Января 2008, 23:21:53 »

Ты считаешь, что каждый ГФ должен автоматически превращаться в ВИ?
Можно детализировать ход рассуждений там, где происходит переход список ГФ -> список ВИ.

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

ГФ001 - это общая цель службы такси или ее миссия. Это может быть БВИ на контекстной диаграмме

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

ГФ004, 006, 010-015 - все эти функции (или глагольные фразы) в целом участвуют в ВИ принять заказа, который по рекомендации тебя, Юры и Дениса(1) нужно сделать системным зарегистрировать заказ. здесь возможно еще можно добавить управление клиентами(ввод, изменения, удаления)

ГФ005, 007 - распределить заказ, или зарегистрировать прием заказа водителем

ГФ009 - я бы вообще исключил пока из рассмотрения, поскольку это будет возможно не функция системы.

ГФ008, 016-017 - зарегистрировать выполнение заказа

ГФ019 и ГФ021 - функции бухгалтера, функция системы будет вероятно произвести расчет денежных начислений за указанный период по указанному водителю или диспетчеру

ГФ018 и ГФ020 - будет скорее всего трансформироваться во что-то типа сформировать (предоставить) отчет

Я бы еще добавил нечто вроде управление водителями (ввод, изменение, удаление) и диспетчерами-сотрудниками

4439

Примеры / Re: Компания по продаже полов, ламината, в большом количестве но в розницу

« : 04 Января 2008, 22:53:57 »

Эльдар, Ваша DFD мне лично не понятна. Да Вы изобразили скорее стадии изменения статуса продукта. продукт произведен, продукт складирован, продукт заказан, продукт доставлен, выпадает только последний пункт, который ни состояние, ни процесс.

Что касается ERD, ибо это именно то, что я вижу.

Не читая ваше описание попробую составить описание по модели
Каждая офферта содержит информацию об одном и только одном клиенте.
Каждый клиент может делать(?) множество офферте.

Каждый клиент заполняет один и только один лист заказа (не знаю что такое 1+)
Но лист заказ может быть заполнен несколькими разными клиентами

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

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

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

Как Вы полагаете восстановленные мною факты соответствуют Вашей предметной области?

4440

Примеры / Re: Компания по продаже полов, ламината, в большом количестве но в розницу

« : 04 Января 2008, 22:40:36 »

Саша, дело не в Видении или самой задаче. Дело в подходе, который используют наши посетители. Как я понял Эльдар интересуется, как бы мы решали подобную задачу, если бы столкнулись с ней на практике. У Эльдара есть решения и подходы, он их изложил, но он спрашивает, нет ли более эффективных подходов?

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

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

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