Звоните! 
 (926)274-88-54 
 Бесплатная доставка. 
 Бесплатная сборка. 
Ассортимент тканей

График работы:
Ежедневно. С 8-00 до 20-00.
Почта: soft_hous@mail.ru
Читальный зал -->  Диаграммы параллельных состояний 

1 2 3 4 5 6 [ 7 ] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

Для построения модели предметной области особенно полезны следующие два метода языка UML.

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

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

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

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

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

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



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

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

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

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

Естественно, она не скажет вам, как отделить мясо от костей ; именно в этом состоит искусство опытного аналитика, а я пока не разобрался, как это делается.

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

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

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



Технологические риски

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

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

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

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

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

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

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



1 2 3 4 5 6 [ 7 ] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57



ООО «Мягкий Дом» - это Отечественный производитель мебели. Наша профильная продукция - это диваны еврокнижка. Каждый диван можем изготовить в соответствии с Вашими пожеланияи (размер, ткань и материал). Осуществляем бесплатную доставку и сборку.



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.


Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы
.