Sybase PowerDesigner — лучше, по моему мнению, средство UML проектирования, с которым я работал. Это средство позволяет делать все, ну или почти все, что предусмотрено стандартом UML 2, и даже больше.

Самым большим недостатком PowerDesigner следует признать отсутствие кросс-платформенности. К сожалению, эта программа работает только под Windows. Это обстоятельство заставляло меня пробовать разные средства проектирования, такие как Visual Paradigm for UML, Umbrello UML Modeller, Poseidon for UML, но каждое из них сильно проигрывает PowerDesigner по разным обстоятельствам. Umbrello не хватает функциональности и она крайне не устойчива, хотя бесплатна. Poseidon очень не удобен. Visual Paradigm слишком замудрен.

Это будет «Because it's important,» said Norman Guadagno, director of Visual Studio Team System (VSTS)"
Дело происходило на Microsoft's TechEd.
Оригинал новости тут.

Теперь главный вопрос, а на каком уровне это будет? Меня, например, «обратная инженерия» интересует.

Такая идея.

Хочется делать быстро админки по описанию данных (как в Symfony, но лучше).
Хочется, чтобы вообще создание некой веб-штуки сводилось к описанию данных, описанию страниц и настройке параметров отображения. Типа, для этой колонки сортировку разрешить, а в этой валидацию данных устроить. Это для бэк-энда. А для фронт-энда ещё темплейт украшать надо, конечно.
Ещё хочется, чтобы все эти схемы данных и страниц и прочего лежали в базе.

А впоследствии прикрутить парсинг XML в определённой схеме. Чтобы закинуть туда XML и получить управляло такими-то данными в такой-то базе. И round-trip опять же: слить текущую схему, изменить, изменения заслать. И чтоб и базу сменило попутно, колонки там добавило-убавило, таблицы…

Ну и под конец сделать выгрузку UML-диаграмм в определённом профайле в такой вот XML через XMI.

В результате получаем забавнейшую штуку: рисуем квадратики, давим кнопку и получаем полнофункциональный сайт, управляющий какими-то там данными. Остаётся навесить дизайн, если надо…

Вот и взялся я писать такую штуку. На Zend Framework.

Скажите, люди опытные, это велосипедостроение целиком или частично? 8)
И что можно использовать как готовые куски проекта?

UPD: Вы чем минусовать молча, лучше бы раскритиковали вслух. И вам приятно, и мне полезно.
UPD2: Нет, Rails и Django не годится. Потому что целиком всё что я хочу он всё равно не реализует, а писать с использованием фреймворка лично мне проще на PHP. Ну и внешние причины ещё есть, почему именно PHP. Тем не менее, я, конечно, собираюсь вдумчиво почитать их доки и потырить идей.

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

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

В этой статье я рассмотрю 2 скрипта, реализованных на PHP:

• Консольный скрипт php2xmi
• Библиотека PHP_UML

 

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

Учёба в универе и работа наложили свой отпечаток, оказалось, что нужно не только «кодить», но и уметь проектировать те или иные «задачи». Знакомство моё с UML началось с State Machine(конечный автомат, если по русски и приближённо).

 

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

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

Этот топик является продолжением статьи о средствах проектирования.
В данной части я постараюсь рассмотреть не менее достойных представителей данной «отрасли».
Итак следующая тройка выходит на старт!

Здравствуйте.

Делаю первые шаги в проектировании. Сегодня нарисовал след диаграмку


Основная идея лежит в разделении Чтения/Записи в БД.

Класс для чтения рандомно выбирает SLAVE-Сервер и конектится туда для чтения.
Класс Write работает непосредственно с мастер-сервером.

Базовый класс DB использует кеширование для запросов. (Уже понял что кеширование нужно вынести в read)

Так же класс READ конектится с пользователем, которому можно только SELECT

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

Я вижу тут плюс в том, что можно предоставить класс для работы с БД удаленному програмисту.

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

Я долго пытался выразить словами зачем мне всё это нужно но потом отказался от этой идеи. Кому интересно — отвечу в комментариях. Итак суть:

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

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

Проблема:

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

Например: каждый из объектов имеет метод Data(), который возвращает данные, необходимые для отображения объекта на странице (данные для шаблонизатора). Например объект $news класса News должен возвратить 5 последних новостей в приемлемом для шаблонизатора виде, например в виде массива. В свою очередь News::Data() обращается поочередно к объектам $newsPost->Data() (к вложенным объектам) для получения данных, касающихся отдельной новости (заголовок, дата и т.д.). Однако в некоторых случаях требуется, чтобы NewsPosе::Data() возвращал не полные данные, а лишь заголовок (например на главной странице сайта), а в другом случае требуется, чтобы вернулись все данные, включая ссылки на «новости по теме».

 

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

Добрый день, уважаемое сообщество! Хочу поделиться с вами неплохим, по моему мнению, способом изучения времен английского языка. Я очень надеюсь, что эта заметка будет полезна тем, у кого трудности с изучением времен в английском языке. Не такое уж это простое дело ─ знать 26 времен, а еще сложнее научиться их использовать в нужное время.

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

Новые архитектурные инструменты в Visual Studio Team System 2010 помогут вам понять имеющееся приложение, спроектировать необходимую вам новую функциональность и проверить что ваша реализация соответствует вашему дизайну.

Лет 10 назад веб-проекты по большей части были статическими, а технологический процесс порой — прост до безобразия. Теперь грань между веб-приложениями и настольными приложениями стирается, функциональная сложность веб-проектов растет. Это диктует новые требования к веб-разработке. Обычная ситуация нынче, в эпоху «удиви меня 2.0», — когда проект долгосрочный, в нем задействовано множество специалистов (и не специалистов также), щедро орошающих многострадальный product backlog новыми идеями и целями, как до начала разработки, так и после. Как вы понимаете, цели и истории мутируют, а вместе с ними и задачи. Предварительная оценка по времени теряет свою целесообразность. И т.д. и т.п. Очевидно, нужна специальная методология разработки. Можно попробовать приобщиться к Rational Unified Process (RUP) или Process Mentor. Однако, не стоит. Среди столь популярных ныне Agile методик имеется то, что нам надо — Feature Driven Development (FDD).

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

• Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)
• Проектирование структуры программы
• Кодирование (набор программного кода согласно проектной документации)
• Тестирование и отладка
• Внедрение программы
• Сопровождение программы
• Утилизация

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