91

Примеры / Re: Полный комплект UML диаграмм

« : 24 Января 2014, 17:44:04 »

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

Хотелось бы дополнить... Разделение на части начинается на уровне аналитика. Функциональные требования делятся на фичи и варианты использования. В свою очередь ВИ делятся на потоки. Разработчики, дизайнеры, архитекторы, тестировщики также работают с каждым ВИ или потоком ВИ в отдельности. На уровне архитектуры/дизайна система также разбивается на части - слои, подсистемы, компоненты, сервисы. Таким образом, работая с каждой частью в отдельности, слон съедается частями.

92

Примеры / Re: Полный комплект UML диаграмм

« : 23 Января 2014, 20:33:17 »

Теперь проект в разы стал больше. Цель, наверно, в первую очередь вспомогательная/наглядная, возможно для отчётности. Что-то мне в голову не приходит ни одна альтернатива. А UML и в университете изучал. Что-то помню.
Проект большой. Людей мало. Без структурного подхода приступать к написанию программы - методом проб и ошибок будем очень долго идти. Хоть какая-то системная аналитика должна быть. На сколько я понимаю самый простой вариант - UML диаграммы.

Цель использования UML так и не была четко сформулирована. Чем будут по Вашему отличаться проект без UML и с ним? Что потеряет проект если Вы не
будете применять UML? Какую проблему вы хотите решить с помощью UML?

93

Задачи студентов / Re: Помогите с построением графика в UML

« : 22 Января 2014, 22:33:25 »

Нужно построить график в UML

Задание именно так и звучит? Какую UML-диаграмму нужно построить?

94

Примеры / Re: Полный комплект UML диаграмм

« : 22 Января 2014, 19:20:33 »

До этого справлялся наброском "в тетрадке".

А что теперь изменилось?

Однако, теперь без UML не обойтись.

Какая цель применения UML в проекте и почему именно UML?

P.S. Подскажите, пожалуйста, простенькую книжку для начинающих актуальную для UML 2.2.

Изучение самой нотации (в отрыве от принципов ООАП), мало что дает. Лучше почитать что-нибудь типа Джим Арлоу, Айла Нейштадт - UML 2 и унифицированный процесс. Еще на uml2.ru присутствует список рекомендуемой литературы.

95

Задачи студентов / Re: Моделирование статусов заказов

« : 13 Января 2014, 06:39:38 »

Моделирование статусов - это по определению диаграмма состояний

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

96

Задачи студентов / Re: Моделирование статусов заказов

« : 11 Января 2014, 19:50:52 »

Здравствуйте. Возникла такая задача смоделировать на UML систему заказов:

Но проблема в том, что я совершенно не понимаю, как это должно выглядеть. Я знаю, как, например, сделать вот такое задание: "Сотрудники работают в отделах. Каждый сотрудник может занимать одну или несколько должностей. У каждой должности есть своя тарифная ставка зарплаты", но на свое задание даже примеров не нашел. Обращаюсь за помощью, может кто даст наводку, как это оформлять, или даст ссылочку на литературу? Буду очень благодарен.

Добрый вечер! Нужно сделать только диаграмму классов?

97

Обучение / Re: Инструментальные средства информационных систем

« : 08 Января 2014, 01:25:32 »

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

Дисциплина новая, предложена в рамках ФГОС 3 поколения. К сожалению наши стандарты (учебные) часто противоречивы и не полны. Так, например, данная дисциплина указана как обязательная профессиональная, но среди списка требований и компетенций стандарта мне ничего внятного найти не удалось, чтобы проливало свет на то, а что нужно от специалиста по данной дисциплине.

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

Я бы отнес к инструментальным средствам прежде всего средства поддержания жизненного цикла систем, CASE, CAD/CAM, кодогенераторы, Средства реинжиниринга и репроектирования, Среды разработки приложений, системы непрерывной интеграции, СУБД и операционные системы.

При этом что-то упоминать вскользь, что-то рассматривать более подробно. У вас какое мнение?

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

Если меня "понесло" и речь все же о прикладных средствах разработки и сопровождения АИС, тогда я бы рассматривал еще системы управления требованиями, версиями, автоматизированного тестирования, различные трекеры задач, багов и т.п. Также не нужно забывать про инструменты для поддержки "железа".

98

Задачи студентов / Re: Игра "Дурак"

« : 05 Января 2014, 21:49:02 »

целью курсового является проектирование системы, после чего выполняется ОО разработка приложения
Вот собственно задание для разработки диаграммы классов:
Найти сущности, для которых можно выделить базовый и производный классы. Привести описание базовой (абстрактной) сущности и производных сущностей, указать отличительные черты производных сущностей между собой. Создать иерархию классов, определить базовый и производный классы.
При выполнении работы учесть следующие требования:
•выделить общие методы производных классов, описать их в отдельной таблице;
•предусмотреть  хранение объектов иерархии;
•показать на диаграмме классов иерархию классов и связи между классами;
•сгенерировать код по разработанной диаграмме.

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

99

Задачи студентов / Re: Игра "Дурак"

« : 05 Января 2014, 01:35:53 »

предлагаете убрать крупье? кто то же должен сдавать картыс такими диаграммами не сталкивался

Когда я играл в дурака, то всегда сдавал кто-то из игроков и они никогда не назывались "крупье". Диаграмма классов такая же, просто на ней отсутствуют проектные классы типа "главное меню"

100

Задачи студентов / Re: Игра "Дурак"

« : 05 Января 2014, 00:52:25 »

собственно диаграмма то у меня есть
имеются сомнения относительно правильности и уровня её выполнения

1. Обычно сначала рисуется диаграмма классов анализа. На ней не должно быть главного меню и других проектных классов.
2. Название каждого класса должно быть в единственном числе.
3. Откуда крупье в игре "Дурак"?
4. Предлагаю идти поэтапно, сначала правильно выделить классы, а уже потом атрибуты и операции.
5. Предыдущее моё сообщение остаётся в силе.

101

Задачи студентов / Re: Игра "Дурак"

« : 04 Января 2014, 23:31:58 »

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

Добрый вечер!
1. Сформулируйте назначение системы с точки зрения игрока.
2. Определите какими классами событий/действий будет оперировать система, выполняя своё назначение.
3. Определите с какими классами объектов/субъектов/сущностей будут связаны вышеуказанные события.
4. Нарисуйте диаграмму классов, расставив связи между ними и множественности.

102

Задачи студентов / Re: Диаграммы UML для Библиотеки

« : 26 Декабря 2013, 18:33:34 »

Я не возражаю ЭТИМ Вашим словам, я против превращения базы данных в actor.

Согласен, что чаще всего это является ошибкой.

Унаследованная система вряд ли называется база данных.

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

103

Задачи студентов / Re: Диаграммы UML для Библиотеки

« : 26 Декабря 2013, 14:14:29 »

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

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

104

UML SysML и пр. / Re: Диаграмма прецедентов /Актеры/

« : 26 Декабря 2013, 07:23:50 »

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

105

Задачи студентов / Re: Диаграммы UML для Библиотеки

« : 25 Декабря 2013, 23:49:39 »

Уточню кое-что:
1. Диаграмма прецедентов:
- Из описания не совсем понятно читатель регистрируется сам или его регистрирует Библиотекарь. Можно предположить что это будет Библиотекарь. Хотя от Заказчика можно ожидать всё что угодно и я бы уточнил.
- В описании нет информации про необходимость использования существующих систем. Если у заказчика выясните, что необходимо использовать существующую БД, только тогда она может появиться на диаграмме в виде эктора.
2. Диаграмма классов:
- Нужно прежде всего отталкиваться от того, на каком уровне абстракции нужно построить диаграмму классов. Они будут отличаться в моделях бизнеса, анализа, дизайна/реализации.
Судя по всему нужна диаграмма классов на уровне анализа.
- Для чего нужен класс "Персонал" или "Библиотекарь". Их нужно учитывать? Это нужно уточнить.
- Связи действительно непонятно по какому принципу построены.
- Собираемся ли мы учитывать возврат книг? Из диаграммы видно, что не собираемся. А вообще надо бы.
- Как будут учитываться конкретные экземпляры одной и той же книги? Помимо класса "Книга" должен быть ещё класс "Экземпляр книги".
- Другой вопрос... Что если читатель возьмёт книгу, а вернёт такую-же, но в более плохом состоянии? Необходимо учитывать связанные выдачу и возврат конкретного экземпляра.
В общем есть над чем поразмыслить.
3. Диаграмма объектов:
Она показывает "моментальный снимок" объектов системы в определённый момент времени. Какой момент времени предполагается рассматривать? Какая цель создания этой диаграммы?
4. Диаграмма кооперации и диаграмма последовательностей:
Добавить особо нечего.
5. Диаграмма деятельности (активностей):
Нужно понимать какой именно вариант использования мы хотим визуализировать этой диаграммой, а не скидывать всё в кучу. Цепочка "Применение скидки/Подготовка книги -> Внос залога/выдача книги" это вообще взрыв мозга.