usecase.ru – вариант использования

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

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

Процессы, происходящие при выполнении каждой функции, должны описываться стандартным текстом (usecase) и могут сопровождаться рисунками и диаграммами, поясняющими происходящие действия.

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

Если при анализе становится понятным, что какие-то функции дублируются в рамках системы в целом, то это верный признак необходимости реорганизации (оптимизации) бизнес-процессов в организации.

После проведения анализа должны получиться следующие результаты:

1. Высокоуровневый анализ:
• Разбиение общей системы на модули;
• Список основных функций каждого модуля;
2. Модульный анализ:
• Список функций модуля;
• Описание каждой функции модуля;
• Описание взаимодействия каждой функции модуля с другими функциями этого модуля;
• Описание взаимодействия каждой функции модуля с функциями других модулей;
• Список ролей пользователей и их отношение к функциям модуля.

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

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

Оптимально начать с высокоуровневого разбиения функциональности. Организация делится на некоторые организационные структуры: бухгалтерию, склад, отдел (департамент, другая орг. структура) работы с клиентами, отдел работы с поставщиками и т.д. Таким образом определяем общее модульное покрытие автоматизации по орг. структурам.

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

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

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

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

Более детальное описание процесса анализа можно найти книге «Принципы работы с требованиями к программному обеспечению. Унифицированный подход» Леффингуэлл, Уидриг. Книга очень стоящая, но, к сожалению, в продаже уже давно не видел ее. В виде альтернативы могу предложить вторую редакцию этой книги на языке оригинала «Managing Software Requirements: A Use Case Approach, Second Edition» Dean Leffingwell, Don Widrig.

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

Далее идем по ссылкам:
Guidance Automation Extensions (GAX) + Guidance Automation Toolkit (GAT) – общие расширения для VS2005, которые позволяют легко строить структуру приложений и настраивать ее под себя
Web Service Software Factory – расширение для веб-сервисов
Smart Client Software Factory – расширение для смарт-клиентов
Mobile Client Software Factory – расширение для мобильных клиентов

Хоть все это и не релиз, но обязательно стоит посмотреть.

На днях Microsoft объявила о своем плане сделать приложения Office точкой входа в бизнес-приложения от других поставщиков.

Теперь мэйнстрим действительно начинает двигаться в сторону создания интерфейса пользователя для бизнес-приложений в офисных приложениях. Microsoft все больше делает офисные продукты универсальными и все более developer friendly, что показывает грядуший Office 2007.

Бывали ли у вас ситуации, когда покупаешь интересную техническую книгу, которая действительно является интересной, после прочтения появляется куча интересных идей, но при первых попытках их реализовать на выходе получается мусор?

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

Если раскрываемая в книге тема является для вас достаточно размытой, то потребуется время и усилия для того, чтобы осознать новые знания и научиться их применять. Полезно бывает прочитать два, а то и три раза книгу от корки до корки, чтобы пришло понимание. И обязательно надо делать небольшие тестовые примеры по содержанию книги, чтобы можно было быстро понять суть. Лучше, если вы самостоятельно сформулируете себе небольшую задачу. Да, примеры в книге хороши, но они не дают необходимой практики. С ними надо обязательно разбираться, но и не забывайте делать свои небольшие тестовые примеры.

А что не стоит делать при прочтении книги?

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

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

Не стоит прерывать чтение книги на несколько дней – можно потерять целостное понимание изложения.

Занимаясь последние несколько лет разработкой автоматизирующих систем, я очень часто сталкивался с тем, что работникам намного удобнее по старому – в Excel и Word. Практически любая система воспринималась по удобству использования значительно хуже, чем тот же лист в Excel или таблица в Word.

На основе этих фактов у меня стала формироваться идея создания интерфейсной части (UI) систем в офисных приложениях. При этом вся логика системы по прежнему должна реализовываться наиболее удобным средством отдельно от UI (.NET, Java или другое средство).

Недавнее посещение Microsoft Developers Days 2006 на фоне презентаций по новому офису еще более утвердили меня в идее реализации UI в офисных программах. Заключающую точку в размышлениях поставил Антон Антич своим постом в блоге.

Итак, вот основная идея:

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

Как построить процесс разработки архитектуры бизнес-приложения?

Необходимо еще на этапе анализа выделять основные функции будущей системы. При этом первым шагом после анализа должно идти проектирование пользовательского интерфейса системы (или любого другого интерфейса взаимодействия с внешними «факторами»: другие системы, веб-сервисы или иные сервисы). На этом этапе можно определить, какие данные необходимы пользователю, а так же определить все необходимые операции, производимые пользователем. Здесь мы можем описать формат данных и взаимодействие с бизнес- или workflow-логикой (отталкиваемся от принципов Contract-First – сначала описываем интерфейсы взаимодействия, а потом реализуем функциональность).

Теперь следует определить, что такое «Контракт». Контракт – это совокупность трех компонентов: контракт операций (Service Contract), контракт данных (Data Contract) и контракт взаимодействия (Workflow Contract). Контракт операций (Service Contract) описывает методы, которые будут вызываться клиентом. Контракт данных (Data Contract) описывает структуру данных при вызове методов из контракта операций. Контракт взаимодействия (Workflow Contract) описывает последовательность вызовов и переходов (что соответствует последовательности UseCase).

Дальнейший шаг – определение и наполнение необходимой workflow- и бизнес-логики. Workflow-логика должна обращаться к бизнес-логике, а та в свою очередь обращаться к серверам баз данных или другим системам для выполнения запросов. Таким образом, workflow-логика инкапсулирует в себе сложные процессы, в том числе агрегирование, и базируется на более простых функциях бизнес-логики. Возможен вариант, когда часть или вся бизнес-логика реализована в виде оптимизированных хранимых процедур на сервере баз данных.

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