Форум Сообщества Аналитиков
Общий раздел => Примеры => Задачи студентов => Тема начата: neic от 20 Августа 2010, 22:13:06
-
Сделал КР по теме "Фирма разработчик ПО".
Необходима критика работы.
-
Начну с начала.
1. Диаграмма вариантов использования.
Подход нестандартный, но не будем устраивать холивары. Тем не менее:
1. что такое ВИ База знаний, Готовый программный продукт - на мой взгляд это некие объекты, но не варианты использования.
2. что такое ВИ Выделение бюджета, кем оно инициируется и какие отношения имеет с другими ВИ
3. Рассылка ответов / заявок - кем производится, зачем какой тип отношение моделируется - зачем?
4. Как система будет реализовывать ВИ Разработка ПП или Тестирование ПП или Корректировка и усовершенствование ПП - очень высокий уровень имхо
2. Сценарии
Как пример
Название: Учет требований
Основной ход события:
1) Заказчик передает требования и пожелания
2) Разработчики анализируют и предоставляют заказчику обработанные требования и пожелания (возможно/не возможно, возможное усовершенствование предъявленных требований)
3) Заказчик ознакомляется с требованиями и пожеланиями разработчиков, если соглашается, то начинается разработка ПО
Т.е. результатом данного сценария является начало разработки ПО? Очень странное утверждение.
Кроме того где же здесь диалог действующего лица с системой? Если под системой понимается разработчик, который часть системы, то почему на ДВИ он изображен как внешнее действующее лицо, т.е вне системы?
3. Диаграмма классов
Возьмем просто синтаксис и семантику
1. Внутренний сотрудник - это менеджер и отдел технической поддержки и разработчики и еще много чего - это верное утверждение?
2. Сторонние работники - это разработчики и тестировщики
3. в Чем отличие классов Разработчик и Разработчики?
4. Отдел по планированию имеет атрибуты Персонал - приведите значения этих атрибутов; список заказов - это как?, список требований заказчика? Приведите пару тройку конкретных объектов для этого класса и соответственно с конкретными значениями для атрибутов каждого объекта
4. Диаграмма последовательности используется для чего? Что вы хотите изобразить с ее помощью? Последовательность действий по решению какой задачи? На каком уровне?
5. Диаграмма размещения чего изображена Вами? Устройства сети в офисе? Или размещения узлов и компонентов по узлам, а где компоненты системы? А где тогда диаграмма компонентов системы?
-
В общем согласен с Эдуардом. Какая-то путаница и одни вопросы. Добавлю еще свои замечания:
1. ВИ выглядят как Бизнес ВИ, т.е. ими описано - что делает компания и внешние лица по отношению к этой компании. Теперь нужно из них выбрать что же относится к Системе (автоматизируется) и расписать их (построить Системную модель ВИ) как взаимодействие пользователя и Системы.
2. Во многих сценариях есть действия без конкретного ДЛ.
Ну и все что Эд сказал.
-
Кроме Вас еще одна девушка высказалась.
Буду править, результат выложу после исправлений.
-
ВИ База знаний, Готовый программный продукт
Как мне тогда их показать в ДВИ?
что такое ВИ Выделение бюджета, кем оно инициируется и какие отношения имеет с другими ВИ
Инициируется отделом финансов, имеет отношение с реализацией рекламы (выделение бюджета на рекламу)
Рассылка ответов / заявок - кем производится, зачем какой тип отношение моделируется - зачем?
Сори забыл убрать, сам еще понял когда делал, просто забыл убрать из диаграммы.
Как система будет реализовывать ВИ Разработка ПП или Тестирование ПП или Корректировка и усовершенствование ПП - очень высокий уровень имхо
Т.е. разбить их на более мелкие процессы.
Могу предположить, что например Разработка ПП можно разбить на:
1) Выбор языка программирования
2) Выбор технологий
3) Написание исходного кода
...
Тестирование ПП:
1) Написание сценариев тестов к ПО
2) Тестирование по сценарию
...
Корректировка и улучшение ПП:
1) Анализ новых технологий
2) Анализ новых версий языков
3) Анализ изменений требований (возможно такое? или написать проще: анализ новых требвоаний)
...
Я правильно думаю?
Т.е. результатом данного сценария является начало разработки ПО? Очень странное утверждение.
А как еще можно закончить данный сценарий, просто другого ни чего не лезет.
Кроме того где же здесь диалог действующего лица с системой? Если под системой понимается разработчик, который часть системы, то почему на ДВИ он изображен как внешнее действующее лицо, т.е вне системы?
Я просто на примерах видел, что все актеры выставлены за границу системы, поэтому и думал что так правильно будет. Тогда в данной ситуации можно переместить всех актеров внутрь системы, кроме заказчика и внешних сотрудников (добавив их).
3. Диаграмма классов
Возьмем просто синтаксис и семантику
1. Внутренний сотрудник - это менеджер и отдел технической поддержки и разработчики и еще много чего - это верное утверждение?
2. Сторонние работники - это разработчики и тестировщики
3. в Чем отличие классов Разработчик и Разработчики?
4. Отдел по планированию имеет атрибуты Персонал - приведите значения этих атрибутов; список заказов - это как?, список требований заказчика? Приведите пару тройку конкретных объектов для этого класса и соответственно с конкретными значениями для атрибутов каждого объекта
1. Да. Я сделал это потому-что в системе есть много сущностей (я их так назову) которые имеют имя "Отдел...", поэтому в этих отделах как атрибут стоит персонал (по другому можно сказать так: список сотрудников). Возможно я это не правильно сделал.
2. Да.
3. Насколько я знаю что нельзя делать связи много-много, поэтому и вывел так. Просто не знаю как можно по другому сделать.
4. Не понял, если можно пример из другой системы похожий.
4. Диаграмма последовательности используется для чего? Что вы хотите изобразить с ее помощью? Последовательность действий по решению какой задачи? На каком уровне?
Используется потому-что стоит в требованиях в КР. Хочу изобразить на ней весь этап от приема заявки от клиента до отсылки ему ПП.
Можно конечно все это разбить на много диаграмм. А учитывая что будут разбиты процессы Разработка ПП и другие, то скорее всего нужно будет это сделать.
5. Диаграмма размещения чего изображена Вами? Устройства сети в офисе? Или размещения узлов и компонентов по узлам, а где компоненты системы? А где тогда диаграмма компонентов системы?
Я просто делал из примера. Как разобрался так и сделал. Но скорее это будет правильным выражением:
Устройства сети в офисе
Насчет диаграммы компонентов еще не разобрался. Если можно пример привести.
1. ВИ выглядят как Бизнес ВИ, т.е. ими описано - что делает компания и внешние лица по отношению к этой компании. Теперь нужно из них выбрать что же относится к Системе (автоматизируется) и расписать их (построить Системную модель ВИ) как взаимодействие пользователя и Системы.
Понял сделаем.
Во многих сценариях есть действия без конкретного ДЛ.
Что значит "ДЛ"?
Возможно такое задание: Разработать документацию по "Фирма разработчик ПО" (сделать ИС), а также создать ПО выполняющие такие-то функции?
-
Как мне тогда их показать в ДВИ?
Для этого ДВИ не предназначена, либо их нужно демонстрировать как отдельные внешние системы - актеры
Инициируется отделом финансов, имеет отношение с реализацией рекламы (выделение бюджета на рекламу)
Из вашей диаграммы это никак не следует
Т.е. разбить их на более мелкие процессы.
ВИ - это цель пользователя, т.е. декларация какой-то законченной хотелки пользователя, приносящая ощутимый результат
Могу предположить, что например Разработка ПП можно разбить на:
1) Выбор языка программирования
А причем тут ваша система?
2) Выбор технологий
А причем тут ваша система?
3) Написание исходного кода
А причем тут ваша система?
Тестирование ПП:
1) Написание сценариев тестов к ПО
А причем тут ваша система?
2) Тестирование по сценарию
...
А причем тут ваша система?
Корректировка и улучшение ПП:
1) Анализ новых технологий
2) Анализ новых версий языков
3) Анализ изменений требований (возможно такое? или написать проще: анализ новых требвоаний)
...
А причем тут ваша система?
Я правильно думаю?
Категорично нет"
А как еще можно закончить данный сценарий, просто другого ни чего не лезет.
В чем цель данного варианта использования, какой результат должен получить пользователь при взаимодействии с системой - это и будет результат.
Я просто на примерах видел, что все актеры выставлены за границу системы, поэтому и думал что так правильно будет.
Правильно думали, на то они и актеры.
Тогда в данной ситуации можно переместить всех актеров внутрь системы, кроме заказчика и внешних сотрудников (добавив их).
А это будет ошибкой, это уже будет не ДВИ
1. Да. Я сделал это потому-что в системе есть много сущностей (я их так назову) которые имеют имя "Отдел...", поэтому в этих отделах как атрибут стоит персонал (по другому можно сказать так: список сотрудников). Возможно я это не правильно сделал.
Это вы не правильно сделали
2. Да.
Попутали обобщение и конкретизацию. Разработчики или тестировщики - это сторонние разработчики - так правильно, наоборот нет
3. Насколько я знаю что нельзя делать связи много-много, поэтому и вывел так. Просто не знаю как можно по другому сделать.
Поясните что вы хотели отобразить я не понял.
4. Не понял, если можно пример из другой системы похожий.
Имеем систему классов Клиент (1) - (*) Заказ (1) - (*) Строка заказа (*) - (0-1) Товар
Петя:Клиент
Заказ №1:Заказ (23.12.2012)
Книга1:Товар 300 р 2 шт
Книга2:Товар 350 р 3 шт
Заказ №100:Заказ ((3.02.2020))
Книга100:Товар 1000 р 1 шт
Используется потому-что стоит в требованиях в КР. Хочу изобразить на ней весь этап от приема заявки от клиента до отсылки ему ПП.
Требование к курсовой в студию
Я просто делал из примера. Как разобрался так и сделал. Но скорее это будет правильным выражением: Насчет диаграммы компонентов еще не разобрался. Если можно пример привести.
Читаем книги
Что значит "ДЛ"?
Действующее лицо = Actor
Возможно такое задание: Разработать документацию по "Фирма разработчик ПО" (сделать ИС), а также создать ПО выполняющие такие-то функции?
Это что?
-
Задание КР: Разработать ИС какой-либо фирмы (магазина и т.д.) используя диаграммы Use-case, классов, последовательности, размещения, коопераций.
Из вашей диаграммы это никак не следует
Я подумаю как сделать.
А причем тут ваша система?
А что Вы предлагаете сделать с этими Разработка ПП, Тестирование ПП?
Я уже запутался с этой ДВИ.
Что на ней должно быть конкретно изображено?
Ведь и заказчик, и менеджер, и разработчики и т.д. это пользователи системы.
Т.е. получается выбрать язык программирования, технологию и т.д. это цель разработчика (в частности программистов и/или отдела планирования), и это определяет как будет разрабатываться в дальнейшем продукт. Ведь выбор языка программирования это вопрос очень важный, тк. в дальнейшем может потребоваться модернизация ПО, а язык уже к тому времени будет устаревшим. Т.о. это касается и заказчика, и разработчика.
Если я не прав, помогите хотя бы начать правильно разрабатывать (хотя бы начало новой правильной ДВИ)
-
Решил сделать с самого начала.
Вот набрасал новую USE-CASE диаграмму.
Что в ней добавить/изменить?
-
Выгрузите Диаграмму в картинку или вордовский файл.
З.Ы. ДЛ = Действующее лицо = актер
-
Вот скрин
-
Задание КР: Разработать ИС какой-либо фирмы (магазина и т.д.) используя диаграммы Use-case, классов, последовательности, размещения, коопераций.
Что значит разработать ИС? Если в результате должны появиться изделие, продукт, прототип ИС какой-либо фирмы, то причем тут UML? Если результатом должно стать формальное описание ИС, по сути проектное решение, готовое завтра воплотится в реальную систему - то причем тут все ваши диаграммы UML, которые вы вообще сделали? По-моему, они никак вас не приблизили к исполнению требования по заданию.
Реально вы выполняете некое задание такого типа: продемонстрируйте основные диаграммы UML на примере ИС какой-либо фирмы.
А что Вы предлагаете сделать с этими Разработка ПП, Тестирование ПП?
Это уж вы, пожалуйста, предлагайте
Я уже запутался с этой ДВИ.
Что на ней должно быть конкретно изображено?
Хороший надо сказать вопрос - вот и задайте его себе и спросите - А ЧТО Я ХОЧУ ИЗОБРАЗИТЬ НА ЭТОЙ ДИАГРАММЕ: какой контекст, какие границы, какой scope (область действия). Тогда и будет ясно
Ведь и заказчик, и менеджер, и разработчики и т.д. это пользователи системы.
или же они не пользователи
Т.е. получается выбрать язык программирования, технологию и т.д. это цель разработчика (в частности программистов и/или отдела планирования), и это определяет как будет разрабатываться в дальнейшем продукт. Ведь выбор языка программирования это вопрос очень важный, тк. в дальнейшем может потребоваться модернизация ПО, а язык уже к тому времени будет устаревшим. Т.о. это касается и заказчика, и разработчика.
Вы что автоматизируете? У вас такая крутая система, которая на основании поступивших требований, сама выбираете (ну или помогает выбрать) язык программирования?
Если я не прав, помогите хотя бы начать правильно разрабатывать (хотя бы начало новой правильной ДВИ)
Ну изучите лекции, изучите книги, а потом пытайтесь использовать UML. Иначе не используйте
-
Реально вы выполняете некое задание такого типа: продемонстрируйте основные диаграммы UML на примере ИС какой-либо фирмы.
Да скорее всего такое задание в КР. Мне сказали разработать ИС использовав основные диаграммы и перечислила какие.
Это уж вы, пожалуйста, предлагайте
Я уже предложил, Вы забраковали, что ж я еще могу придумать?
или же они не пользователи
Пользователи системы.
Вы что автоматизируете? У вас такая крутая система, которая на основании поступивших требований, сама выбираете (ну или помогает выбрать) язык программирования?
Т.е. на ВИ должны быть расписаны процессы которое которые автоматизируются?
Тогда почему в некоторых ДВИ упоминается "Регистрация"? Т.е. это система которая автоматически регистрирует пользователя? Т.е. сама заполняет его имя, фамилию и т.д.? (не в обиду, просто я не понимаю как регистрация может автоматизироваться)
Я считаю, что ВИ это процесс. Т.е. например Программист выбирает язык программирования исходя из требований заказчика.
Думаю в данной системе трудно описать какие действие которые автоматизируются, кроме разве что разработать программу которая будет вести учет заказчиков, их заказов, назначать сотрудников на какой-либо заказ. Автоматизировать тех. поддержку, т.е. ответ пользователю на запрос (при ответе система сама определит адрес e-mail (например) или оповестит пользователя об ответе), хранить запросы.
-
Т.е. на ВИ должны быть расписаны процессы которое которые автоматизируются?
Да. На Системный ВИ (СВИ) именно отражает те процессы, которые автоматизируется и в сценарии прописывается - что при этом делает Пользователь и что делает Система.
Тогда почему в некоторых ДВИ упоминается "Регистрация"? Т.е. это система которая автоматически регистрирует пользователя? Т.е. сама заполняет его имя, фамилию и т.д.? (не в обиду, просто я не понимаю как регистрация может автоматизироваться)
Почему только Система? СВИ это последовательность действий, которую делает Пользователь и Система, вот как пример см. в конце:
http://www.uml2.ru/index.php?option=com_content&task=view&id=77&Itemid=51
Я считаю, что ВИ это процесс. Т.е. например Программист выбирает язык программирования исходя из требований заказчика.
Бизнес ВИ, да. Но Вы же хотите описать именно что должна делать Система, т.е. СВИ. См. различие БВИ и СВИ там же в ФАКе.
Думаю в данной системе трудно описать какие действие которые автоматизируются...
В какой Системе? Что Вы понимаете под Системой?
-
А что есть в вашем случае ИС фирмы?
Смотрите: есть фирма - разработчик ПО. Есть внешние по отношению к ней системы (люди, организации, и т.п.), которым данная фирма-разработчик для чего-то нужна. Заказчику, видимо, нужна, чтобы он мог обратиться с целью - заказать требуемое ПО.
Фирма-разработчик организует процесс создания ПО, каким образом она это делает, заказчику неважно, ему нужен не процесс, ему нужен результат - требуемое ПО.
Если Вы разрабатываете ИС фирмы-разработчика то возникает вопрос, какая ИС нужна фирме-разработчику, что она должна делать, чьи нужды обеспечивать. Заказчика или сотрудников фирмы?
UML и все его диаграммы - способ описания некой системы (главным образом все-таки систем с использованием программных средств). Вам в курсовой и дано задание: 1/определиться с предметной областью, для которой Вы будете строить систему; 2/используя UML и набор его диаграмм составить спецификацию такой системы (не самой системы, а набор именно спецификаций языковых и графических, определяющих суть моделируемой вами системы.
У фирмы разработчика может быть:
1. система регистрации запросов заказчика
2. система регистрации ошибок ПО, используемых заказчиком
3. система управления процессом разработки ПО
4. система управления кадрами и заработной платой сотрудников фирмы
5. система бухгалтерского учета
и т.п.
Все эти системы могут быть интегрированы в одну или реализованы на одной платформе. Ваша задача - или описать существующую систему, или описать предполагаемую систему (думаю скорее последнее). Учитывая уровень курсовых работ, это должна быть небольшая система, т.е. очень маленькая с небольшим набором функциональности. Иначе просто будет не курсовая, а нечто гораздо более и семестра не хватит, да не хватит и двух :)
-
Вот! Теперь все стало на места.
Т.е. существующую ДВИ я оставляю как БВИ и начинаю делать другую - СВИ.
Соответственно все остальные диаграммы можно выкинуть из курсача, т.к. их придется переделать.
Спасибо за подсказки буду делать. Новые наработки выложу, через пару деньков.
-
Т.е. существующую ДВИ я оставляю как БВИ и начинаю делать другую - СВИ.
Не уверен, что у вас это ДБВИ, тут смесь точек зрений и перспектив.
-
Появилось пару вопросов.
1) Какая связь должна быть на диаграмме классов между классом сотрудник и классом менеджер - агрегация или наследование?
2) На диаграммах последовательности в конце должна быть достигнута цель(?), вот 2 варианта, какой из них 3х правильный(?):
Вариант 1:
1. На стартовом окне нажать кнопку "Добавить сотрудника"
2. Открыть окно "Добавить сотрудника"
3. Ввести данные
4. Проверить данные ввода
5. В случае ошибки сообщить пользователю (какая линия должна быть в этом случае, т.к. это может и не возникнуть, т.е. исключение)
6. Добавить сотрудника (если ошибок не было выявлено)
Вариант 2:
1. Открыть окно "Добавить сотрудника"
2. Ввести данные
3. Проверить данные ввода
4. Добавить сотрудника (если ошибок не было выявлено)
Вариант 3:
1. На стартовом окне нажать кнопку "Добавить сотрудника"
2. Открыть окно "Добавить сотрудника"
3. Ввести данные
4. Проверить данные ввода
5. Добавить сотрудника (если ошибок не было выявлено)
-
1) Какая связь должна быть на диаграмме классов между классом сотрудник и классом менеджер - агрегация или наследование?
Ассоциация, может быть и наследование, где Сотрудник обобщающий класс - менеджер уточняющий
2) На диаграммах последовательности в конце должна быть достигнута цель(?), вот 2 варианта, какой из них 3х правильный(?):
Гы предложение уже содержит ошибку
Вариант 1:
1. На стартовом окне нажать кнопку "Добавить сотрудника"
2. Открыть окно "Добавить сотрудника"
3. Ввести данные
4. Проверить данные ввода
5. В случае ошибки сообщить пользователю (какая линия должна быть в этом случае, т.к. это может и не возникнуть, т.е. исключение)
6. Добавить сотрудника (если ошибок не было выявлено)
Вариант 2:
1. Открыть окно "Добавить сотрудника"
2. Ввести данные
3. Проверить данные ввода
4. Добавить сотрудника (если ошибок не было выявлено)
Вариант 3:
1. На стартовом окне нажать кнопку "Добавить сотрудника"
2. Открыть окно "Добавить сотрудника"
3. Ввести данные
4. Проверить данные ввода
5. Добавить сотрудника (если ошибок не было выявлено)
А это варианты чего? Вообще диаграмма рисуется, а сценарий пишется. Однако в сценарии вообще-то отражаются взаимодействующие объекты, а где они?
-
Вот например
-
Вот например
1. Что вы хотите показать этой диаграммой? напомню, что ДП одна из диаграмм взаимодействия и служит для визуализации некоторого сценария (т.е. строгой последовательности действий), отображающего путь достижения или не достижения пользователем его цели. При этом мы используем некоторые объекты ( в начале объекты предметной области ) для отображения реализации сценария варианта использования.
2. Вы пытаетесь изобразить справа по сути черный ящик. Ларман называет такие диаграммы системными ДП и предлагает их использовать для отображения или идентификации системных событий, которые потом отображаются на системные операции. Т.е. ваш объект Добавить сотрудника по сути либо сама система, либо ее часть показанная без детализации. Возникает вопрос зачем нужно рисовать диаграмму, если ПРАВИЛЬНО составленный сценарий ВИ вполне решает туже задачу? Какую пользу вы лично (или кто-то другой) извлечете из этой диаграммы?
3. Кроме того концовка диаграммы реализована не верно. Шаги 5 и 6 взаимоисключающие, альтернативные. У вас же они изображаются как последовательные, а следовательно всегда выполняемые. Для отображения альтернативных путей и в UML1.5 и в UML 2 существуют адекватные средства
-
1. Что вы хотите показать этой диаграммой? напомню, что ДП одна из диаграмм взаимодействия и служит для визуализации некоторого сценария (т.е. строгой последовательности действий), отображающего путь достижения или не достижения пользователем его цели. При этом мы используем некоторые объекты ( в начале объекты предметной области ) для отображения реализации сценария варианта использования.
Здесь я описывал процесс как сотрудник КО добавляет нового сотрудника.
Т.е. сотрудник нажимает кнопку "Добавить сотрудника" на стартовом окне сотрудника (открывается после авторизации). В открывшемся окне он вводит данные для добавления сотрудника, нажимает "Добавить". Программа делает проверку на правильность ввода и на повтор. Если данные введены не верно или сотрудник существует, то программа сообщает сотруднику КО, что выявлена ошибка. Если ошибки нет, то программа добавляет сотрудника в БД.
Это 1 из ... диаграмм. Просто я выбрал первую попавшую и добавил сюда.
2. Вы пытаетесь изобразить справа по сути черный ящик. Ларман называет такие диаграммы системными ДП и предлагает их использовать для отображения или идентификации системных событий, которые потом отображаются на системные операции. Т.е. ваш объект Добавить сотрудника по сути либо сама система, либо ее часть показанная без детализации. Возникает вопрос зачем нужно рисовать диаграмму, если ПРАВИЛЬНО составленный сценарий ВИ вполне решает туже задачу? Какую пользу вы лично (или кто-то другой) извлечете из этой диаграммы?
Что значит без детализации?
А насчет "зачем?"...не знаю может спросите у моего преподавателя? Вот стоит требование кровь из носа заюзать 5-6 видов диаграмма, ну а что, буду говорить, да зачем мне делать? Вы же сами знаете что такое требования.
3. Кроме того концовка диаграммы реализована не верно. Шаги 5 и 6 взаимоисключающие, альтернативные. У вас же они изображаются как последовательные, а следовательно всегда выполняемые. Для отображения альтернативных путей и в UML1.5 и в UML 2 существуют адекватные средства
Вот как раз этот вопрос я и хотел узнать, я и так знал что это не правильно, но как отобразить это правильно я не знаю. Поэтому и обратился с вопросом.
-
Здесь я описывал процесс как сотрудник КО добавляет нового сотрудника.
Т.е. сотрудник нажимает кнопку "Добавить сотрудника" на стартовом окне сотрудника (открывается после авторизации). В открывшемся окне он вводит данные для добавления сотрудника, нажимает "Добавить". Программа делает проверку на правильность ввода и на повтор. Если данные введены не верно или сотрудник существует, то программа сообщает сотруднику КО, что выявлена ошибка. Если ошибки нет, то программа добавляет сотрудника в БД.
Это не уровень ЧТО нужно делать, не уровень описания требования. Это по сути описания некой реализации, причем с привлечением определенных программных компонентов. Почитайте внимательно FAQ по USE Cases
Вот как раз этот вопрос я и хотел узнать, я и так знал что это не правильно, но как отобразить это правильно я не знаю. Поэтому и обратился с вопросом.
Почитайте руководство пользователя UML от авторов или иные книги по UML.