Форум Сообщества Аналитиков
Дисциплины => Проектирование => Тема начата: dimaxz от 09 Июля 2010, 16:25:09
-
В ходе разработок веб приложение испольщующее технологие php(CodeIgniter),Mysql,Javascript(YUI) дорасло до такого размера что встала необходимость использовать UML чтоб задокументровать систему, да и разложить по полочкам всю архитектуру.
Остановился на IA для проектирования, выбрал деаграммы классов для отображения физической структуры и диаграмме DataBase для БД. Возникли вопросы на которые так и не нашел ответы на форуме. Читаю Основы UML Гради Буча.
Итак:
1. В системе используется компонентный(модульный подход) каждый исполнен в архитектуре MVC(модель-предствление контроллер). Трудности возникли в отображении моделей. Например есть компонент оргструктура. Модели: сотрудник(атрибуты: номер, фио, отдел, должность, компания), и конечно же отдел(номер, название), должность(номер, название), компания (номер, название). Тут понятно что сотрудник связан с отделом, должностью и компанией, но с условием что с отделом не обязательное отношение. На диаграме отобразил отношения в виде агрегаций и композиций. Хотелось бы знать мнение экспертов , ошибки неточности.
-
1. В системе используется компонентный(модульный подход) каждый исполнен в архитектуре MVC(модель-предствление контроллер). Трудности возникли в отображении моделей. Например есть компонент оргструктура. Модели: сотрудник(атрибуты: номер, фио, отдел, должность, компания), и конечно же отдел(номер, название), должность(номер, название), компания (номер, название). Тут понятно что сотрудник связан с отделом, должностью и компанией, но с условием что с отделом не обязательное отношение. На диаграме отобразил отношения в виде агрегаций и композиций. Хотелось бы знать мнение экспертов , ошибки неточности.
Ну вообще странное прочтение структуры, более структура сама по себе не отвечает на вопрос поведения системы. Возможно поведение сидит у Вас в голове и преобразуется в такую вот структуру, что Вы нарисовали. Но все равно не оптимально.
Во-первых, да сотрудник работает в отделе, но отдел находится в (принадлежит, является неотъемлемой частью) компании
Во-вторых, если сотрудник работает в отделе, а отдел часть компании, то агрегация между сотрудником и компанией лишняя.
В-третьих, сотрудник не может быть частью должности, тем более такой которая ФИЗИЧЕСКИ уничтожается в месте с классом композитом(должность). Сотрудник имеет ассоциацию с должностью
В-четвертых, что вы пытаетесь моделировать структуру хранимых данных? или предметную область через диаграмму классов?
-
Скорее всего предметную область через диаграму классов. даграмму поправил
-
Скорее всего предметную область через диаграму классов. даграмму поправил
Мне больше видится конечно совершенно другой вариант.
Компания как объект агрегирует отдел, ну а отдел уже так сказать сотрудников, выражается паттерном композит.
Должность это всего лишь состояние объекта сотрудник а значит только его свойство.
А вот если по теме ajax: это отлично показывается на диаграмме последовательностей. На ней существую асинхронные сообщения.
-
Мне больше видится конечно совершенно другой вариант.
Компания как объект агрегирует отдел, ну а отдел уже так сказать сотрудников, выражается паттерном композит.
Должность это всего лишь состояние объекта сотрудник а значит только его свойство.
А вот если по теме ajax: это отлично показывается на диаграмме последовательностей. На ней существую асинхронные сообщения.
Должность реализованна в виде класса т.к. имеет методы
-
вот так
-
Привет. Скажи, пожалуйста, как связана проектируемая модель классов с реальной, которая уже работает в приложении?
-
Компоненты собраны в каталоге components, каждый компонент имеет в своем составе три каталога models, controllers, views (по принципу MVC). Сигналы с сервера обрабатывают контроллерами в соответствующем каталоге а также активно используют бизнес-модели компонента, модели компонента собраны в models,работаю напрямую с БД
-
шаблоны за вывод информации
-
даграмма моделей
-
даграмма моделей
Опа - а это что за чудо?
-
классы потомки класса Модель
class User extends Model
{
.....
}
-
На мой взгляд не стоит увлекаться построением сложных моделей, тем более если система уже разработана. Если очень необходимо визуализировать то, что уже создано в коде, можно воспользоваться обратным инженирингом. Это упростит поддержку модели в процессе изменения системы. В большинстве случаев достаточно простого описания требований и модели БД, которую можно синхронизировать с реальной БД.
-
это еще делается для понимания веб приложения между разработчиками с целью улучшения как отдельных компонентов так и системы в целом
-
это еще делается для понимания веб приложения между разработчиками с целью улучшения как отдельных компонентов так и системы в целом
Мне кажется, что представленные диаграммы пока вряд ли этому помогают. В любом случае систему следует представить с разных сторон, а не только структурных. При этом фреймвёрк не должен давлеть, на мой взгляд...
-
скажите а какие диагрыммы вы бы использовали?
-
скажите а какие диагрыммы вы бы использовали?
А те, которые помогут составить внятное и понятное описание системы.
Я, например, не очень понимаю, ЧТО вы пытаетесь описать?
Конструкцию фреймвёрка? Модель системы?
UML - это язык, пользование языком может быть различным. Но когда мы его используем, мы пытаемся передать смысл. Мы можем ошибаться в деталях, но успешно смысл этот передать.
Любая система - это совокупность таких описаний, совокупность описаний с разных точек зрения.
UML- язык, но не МЕТОДОЛОГИЯ. ТО как использовать язык решать Вам.
Ясно, что UML это достаточно гибкий. но ограниченный язык. Вы не сможете на нем высказать любое предложение. Но это и не нужно.
Следует внимательно посмотреть на имеющиеся диаграммы и точно понять, что же вам нужно, минимально исходя из следующего:
описать структуру (диаграммы классов. диаграммы компонентов, диаграммы размещения)
описать поведение (три способа - через автоматы, через последовательности, через деятельности) - то что есть три способа напрягает, но Вам решаеть что и когда применять
описать взаимодействие (диаграммы использования, коммуникации, последовательности)
Если у вас уже имеется код, то можно попытаться сделать реинжениринг и вытащить структур классов, возможно диаграммы последовательностей, явно выстроить диаграммы использования
Либо вообще имеет смысл абстрагироваться от имеющегося и выстроить все с нуля.
Для отображения элементах используемого Шаблона - подойдут кооперации или структурированные классификаторы.
Параметризированная кооперация будет задавать явный шаблон, а конкретные классы вы берете из контектса приложения.
При этом у Вас явно будут несколько множеств моделей - модели описывающие действие интерфейса (гуи), модели, описывающие структуру данных и правила работы с ними, модели слоя бизнес-логики
-
Попробуйте начать с большой контекстной диаграммы (кубики и стрелочки), на которой изобразите основные компоненты (функциональные и/или физические) системы, внешние системы, контрагенты и информационный обмен между ними. Далее можно провести функциональную декомпозицию каждого модуля. Для этого можно, например, использовать диаграммы потоков данных (DFD), где показать информационный обмен внутри каждого модуля http://ru.wikipedia.org/wiki/DFD (http://ru.wikipedia.org/wiki/DFD). Однако, на мой взгляд, лучше для декомпозиции использовать сценарии использования системы(СИС). СИСы можно рисовать в каком-нибудь средстве визуального моделирования типа Visio или Rational Rose, однако простых текстовых описаний будет вполне достаточно.
Все эти модели и описания можно свести вместе в wiki системе. Если нет своей, то можно воспользоваться гугл сайтами.
Опять же, не зацикливайтесь на моделях. Сделайте сначала простое описание. При необходимости вносите пояснения в него при помощи диаграмм.
-
Спасибо за советы.
Вообще возникает такая ситуация когда приходится работать над готовым проектом будь то сайт, интернет магазин или веб приложение без какой либо документаций, неговоря уже и про ТЗ.
Поэтому доработка становится трудной и мучительной. Хорошо если имеется CMS, а вот если индивидуальная разработка то это ваще ж..
Каждый раз начиная свой проект хочется все сделать как надо ТЗ->проектирование->разработка. И хочется чтоб это было как то универсально. Если по ТЗ уже сформировался кое какой стандарт, то в проектированнии все размыто и не ясно, какие диаграммы? сколько? некоторые говоритят 1-2 (class и use case) будет вполне достаточно.
Недавно нашел рисунок каторый прояснил какие диаграммы долджны присутсвтовать в проектировании предметной области и какие этапы проектирования.
-
Если по ТЗ уже сформировался кое какой стандарт, то в проектированнии все размыто и не ясно, какие диаграммы? сколько? некоторые говоритят 1-2 (class и use case) будет вполне достаточно.
Почитайте Брукса. Все уже изобретено и придумано
В проектирование вовсе ничего не размыто. Проектирование это решения по ТЗ.
Подходы бывают разные - это правда, разные методики и методологии.
Описанные вами задачи - типичные для использования UML.
Делаем так - составляем словарь предметной области, он же может позволить сформировать концептуальную модель классов (классы предметки)
Определяем роли пользователей и рисуем use cases.
Далее определяем реализацию каждого use case - в виде текстового описания, в виде диаграмм деятельности, в виде диаграмм последовательности (коммуникации). Особенно последняя. Соотносим появившиеся объекты на этих диаграммах с концептуальной моделью классов, дорабатываем ее, превращая в модель проектирования, т.е. добавляем класс реализации (программные): страницы, обработчики, утилиты, перечисления, контроллеры и т.п.
Определяем ответственности классов - добавляем операции, описываем взаимодействие появившихся объектов классов через диаграммы состояний, деятельности, коммуникации и последовательности
Применяем последовательно шаблоны и принципы проектирования - описываем это через кооперации.
Группируем по пакетам, по компонентам. Компоненты распределяем по узлам, компоненты связываем артефактами
По сути нужно получить сборочный чертеж - т.е. чертеж на монтаж можно сказать системы.