841

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

« : 26 Декабря 2013, 16:06:36 »

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

Браво!!

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

842

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

« : 26 Декабря 2013, 10:07:36 »

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

843

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

« : 26 Декабря 2013, 09:59:32 »

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

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

844

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

« : 25 Декабря 2013, 10:58:53 »

Вот ряд замечаний, советов, рекомендаций и вопросов.

1. Диаграмма прецедентов - из описания явно можно вычленить только Возврат и выдачу книги, а также Регистрация читателя
Проверка контрольных сроков - это часть ВИ возврат книги, не вижу смысла вычленять это в отдельный поток. Это похоже на функциональную декомпозицию. что нехорошо.
Оплата услуг - часть процесса по Выдачи книги. Подумайте, что значит Читатель обратился в систему с целью оплатить услугу. Из описания никак не следует, что это отдельный поток.
Читатель - участник процесса. но он не ОСНОВНОЕ ДЛ, а потому непосредственно с системой учета проката книг не взаимодействует
Сами прецеденты желательно заключить в системный контекст - boundary - типа Система учета проката книг
База данных - в топку - это элемент реализации, или она должна быть представлена как внешняя сущность - актор, типа Картотека читателей

2. Диаграмма классов - мастдай!
Персонал - плохой класс, Библиотекарь лучше, Можно Сотрудник
все связи разорвать - бред!!!
Классы именуются единственным числом
Связи
Читатель (1) - (1 .. *) Выданная книга
Книга (1) - (0 .. *) Выданная книга

Персонал видимо мастдай, либо висит несвязанный

Я бы конечно создал класс Прокат
Читатель (1) - (1..*) Прокат (0..*) - (1) Сотрудник
Прокат (1) - (1..*) Выданная книга (0..*) - (1) Книга

Например как-то так

3. Диаграмма последовательность  - мастдай.
- сначала определись что за прецедент она моделирует, опиши это прецедент текстом
- читатель - не у дел - его убрать
- понять что должна отображать диаграмма последовательности -  реализацию прецендента? Если да в каком стиле, стиле РУП, тогда нужно определить выделить интерфейсные классы: форма, страница, и т.п.; управляющий класс: Обработчик, Диспетчер, контроллер, МенеджерВыдачи и т.п.; ну и твои сущностные классы: читатель, книга и т.п.

4. Диаграмма деятельности - реально у тебя не диаграмма деятельности, а типа 3 в одном. Низя. Опять же нужно понять что ты хочешь передать ДД -процесс чего? Как минимум функции должны располагаться в дорожке где это действие производится выбор книги наверное делает Читатель, Выдачу - отдел и т.д.

845

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

« : 24 Декабря 2013, 22:42:18 »

На форуме могут помочь, но не будут за тебя делать, пойми.

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

846

Проектирование / Re: Archimate: примеры использования

« : 24 Декабря 2013, 11:22:33 »

Эд, у тебя курс как я понял называется "Архитектура информационных систем". Archimate позиционируется преимущественно как язык описания Enterprise Architecture. Оно понятно что если смотреть выше на IEE 1471, то архитектура она и в Африке архитектура. Но обычно информационная систем как правило масштабом поменьше будет, чем EA. Хотя довольно забавно попытаться описывать ИС c т.з. которые предлагает тот же TOGAF по отношению к EA.

Юра, спасибо за твой проснувшийся интерес А какова к примеру альтернатива?
Согласно TOGAF есть уровень бизнес-архитектуры, уровень архитектуры ИС и уровень технологической архитекутры
1. Уровень БА - описывает всякие там БП и БФ и прочие БЦ
2. Технологическая архитектура - техническую и программную системную платформу: СКС, Сервера, Станции, Мобильные устройства, Сетевое оборудование, Способы организации всего этого хозяйства. Серверные ОС , Системные утилиты, Системные платформы, Клиентские ОС и прочее бла бла

А что тогда остается на уровне Архитектуры ИС - прикладные приложения, прикладное оборудование? пользователи исполнители. Что?

Кстати чем глубже я изучаю Archimate - тем больше он представляется мне красивой игрушкой. Сам язык, конечно, представляет собой хорошо проработанную онтологию. Однако какова все-таки польза от всех этих диаграмм? Только в частном общем виде, для иллюстрации и усиления воображения, чтобы задействовать правое полушарие. Как с помощью его описывать реально ГИГАНТСКИЕ архитектуры понять затруднительно, для этого лучше (имо) использовать базы данных, веб-сайти...

847

Примеры / Re: Нужна помощь, срочно

« : 18 Декабря 2013, 20:18:43 »

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

А в чем была помощь от davvol, в том, что он озвучил очевидное? И это подвигло вас на самостоятельную реализацию. Почему вы не отметили Григория Печенкина? Не из-за того, что он пошутил в ваш адрес?

848

Проектирование / Re: Archimate: примеры использования

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

Эдуард, добрый вечер! Тема интересная. А по каким критериям был выбран именно Archimate, а не упомянутый UML или что-то другое? Чем он лучше для обучения студентов?

Сергей, добрый вечер.
UML - это само собой, но все-таки UML это инструмент для моделирования приложений. Archimate - язык иного уровня. Как пишется в книге: UML язык с упором на синтаксис, Archimate на семантику. Archimate согласован с TOGAF и соответствует стандарту.
Более того, я вовсе не остановился на Archimate как языке обучения, пока идет процесс исследования. Можно изучать ARIS.
То, что я уже подсмотрел выглядит привлекательно.

849

Проектирование / Archimate: примеры использования

« : 12 Декабря 2013, 15:54:14 »

Друзья.

Я начинаю проект по разработке курса Архитектура информационных систем. Узнал о языке архитектурных описаний Archimate.
Хотелось бы получить навык и обменяться опытом его использования, чтобы (возможно) подготовиться к использованию языка в рамках курса Архитектура ИС.

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

За основу  можно взять инструмент: http://www.archimatetool.com/, там же есть книга Mastering ArchiMate Edition I. Мне также советовали книгу: "Enterprise architecture at work" from Marc Lankhorst et al.

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

Что скажите?

850

Для всех / Re: Тема дипломной работы

« : 30 Ноября 2013, 17:41:40 »

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

851

Задачи студентов / Re: Вариант использования Создать меню

« : 21 Ноября 2013, 22:14:28 »

Ошибки разбираются в книге, на сайте — только примеры.

Ну так бы и сказал, а то заставляешь ребусы разгадывать Понял я.

852

Задачи студентов / Re: Вариант использования Создать меню

« : 21 Ноября 2013, 18:00:13 »

List

Фенькс, у меня была догадка

853

Задачи студентов / Re: Вариант использования Создать меню

« : 21 Ноября 2013, 17:59:48 »

Возьми список ошибочных и рекомендуемых примеров и преврати в чеклист:
http://alistair.cockburn.us/Sampler+of+good+and+bad+use+cases

Я что-то не очень понял где в каких местах конкретно и какой тип ошибки?

Например:
STANDARD MISTAKES (Withdraw Cash) (PEUC 6.10)
Scope: ATM
Level: User Goal
1. The card gets inserted.
2. The card information gets validated.
3. The transaction information gets collected and validated.
4. The cash is issued, card returned, cash removed, account debited, screen reset.

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

854

Задачи студентов / Re: Вариант использования Создать меню

« : 20 Ноября 2013, 22:17:44 »

Мой подход:
1. выделить два уровня. Уровень моря и уровень змея.
2. Разделить на множество юзкейсов.

Может быть.

Почему так:
* Текущий ВИ "Создать меню" не проходит проверку на уровень моря

А как это проверяется

* Текущий ВИ не проходит проверку на полноту по методу "объект-действие"

а что за метод?

* При моем подходе SRS будет более устойчива к изменениям

Наверное.

-- Вариант А. Реестр ВИ. (Может быть не самый лучший подход, но достаточно понятный)
1. Управление Меню. Уровень змея [включает в себя все нижеследующие].
2. Создание меню. Уровень моря.
3. Копирование меню. Уровень моря.
4. Просмотр меню. Уровень моря.
5. Редактирование меню. Уровень моря.
6. Просмотр списка меню. Уровень моря.
7. Удаление меню. Уровень моря.

Вполне соглашусь. Но есть вопрос. По твоему, как тогда должен выглядеть ВИ Создание меню?

Далее. <<5. Редактирование меню.>> можно оставить как есть, а можно сказать, что включает все операции, кроме операций с блюдами и все пять операций CRUDL с блюдами выписать отдельно. Последнее, на мой взгляд, лучше.

Не допонял идею. А L это что в CRUDL?

Итого моя рекомендация: Вместо одного ВИ напишите дюжину двух уровней.

Рекомендация понятная, а как бы с однотипными альтернативами и исключениями?

855

Варианты Использования (Use Case) / Re: Место вариантов использования в ГОСТ 34

« : 18 Ноября 2013, 17:37:49 »

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

Не мы не безумцы. Мы же не аналитиков явно готовим, а более абстрактно специалист по информ систем.