Звоните! 
 (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 и 6) и диаграммы взаимодействия (см. главу 5) полезно использовать для представления взаимодействия компонентов.



Диаграммы пакетов (см. главу 7) на этой стадии могут дать общее представление о компонентах системы.

Диаграммы развертывания (см. главу 10) могут дать представление о распределении составных частей системы.

Риски, связанные с квалификацией персонала

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

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

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

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

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

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



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

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

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

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

В среде специалистов по образцам такая групповая работа над книгами считается особенно полезной. Уже появилось несколько групп по обсуждению образцов. Дополнительную информацию о таких группах можно получить в Интернете по адресу: http: www.hillside.net/patterns.



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 
Продажа и изготовление мебели.


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