Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Максим Пшеничников

Страницы: 1
1
Ссылки рабочие. Скорее всего у вас что-то с браузером. Можно правым кликом по ссылке скопировать адрес и потом вставить его в адресную строку.
Да даже если и так не получится, "паттерн стратегия" (англ. Strategy) и "паттерн состояние" (англ. State) моментально ищутся гуглом.

2
Если мы говрим о моделировании логики работы ПО, то делаем так:
1. Рисуем ДВИ, потом каждый ВИ расписываем в виде сценария и(или) ДП\ДД
Я как раз так и сделал ранее. Сценарии прорисовались.
Цитировать
2. Рисуем ДК для каждого слоя ПО
А вот тут я и сел. У меня проблема не смоделировать бизнес-процесс (он достался мне как неизменяемая данность), а зашить этот бизнес-процесс в конкретные классы.

В моем предыдущем сообщении я несколько сумбурно даже сам себе представлял описанную декомпозицию - поэтому и обратился за советом. Поразмыслив, я пришел к немногим более простому решению:
1. Мой бизнес процесс (БП) - это последовательность множества заранее известных этапов взаимодействия сущностей БП (менеджеры, руководители, клиенты, заказы, поставщики, заявки, автомобили, грузы и так далее).
2. БП имеет несколько сценариев развития. Каждый сценарий - это уникальная последовательность этапов. Сценарии - воплощение паттерна Стратегия
3. На каждом этапе сущности БП обладают определенным поведением и имеют определенные ограничения. (Поясню: например, после того, как фуры пересекли границу и прошли таможенный контроль, и уже едут домой, менеджер не может их опять завести на таможню (предполагается, что границу пересекаем один раз) )
4. Для тех объектов, чье поведение меняется в зависимости от этапа (всего три таких класса: менеджер, груз и заказ), пишутся отдельные классы в которых реализовано их поведение в зависимости от этапа - реализация паттерна Состояние. По одному классу состояния на каждый этап и каждый класс, меняющийся от этапа к этапу.
5. В итоге наши "изменчивые" объекты будут переходить от этапа к этапу так, как это прописано в выбранном сценарии, а поведение в зависимости от этапа будет подхватываться из объектов-состояний. Общий алгоритм БП будет сосредоточен в классах-состояниях.

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

И второе, невеянное сообщением от Galogen: как вы относитесь к тому, чтобы сделать общий алгоритм БП событийно-управляемым? (переход между этапами при определенных условиях происходил бы автоматически, без нажатия на кнопку "перейти на следующий этап" того или иного менеджера)

3
Здравствуйте, уважаемые проектировщики!

Ситуация:
Я новичок в проектировании ПО, до сего момента только читал PEAA и GOF и практиковался на реализации некоторых паттернов. Недавно у меня появилась возможность почувствовать себя в роли проектировщика в создании небольшой системы учета заказов одной компании. Сейчас занимаюсь рисованием UML диаграмм, одна из которых (диаграмма деятельности+"плавательные дорожки") описывает алгоритм движения заказа по этапам, различные сценарии взаимодействия пользователей системы с заказом в зависимости от его типа и текущего этапа, условия перехода от этапа к этапу и так далее. В этой диаграмме я опустил мелкие ветвления, которые не важны для процесса в целом, но тем не менее корректируют небольшие участки алгоритма внутри этапов. В любом случае у каждого этапа всегда одинаковые входы и выходы.

Мои идеи:
1. В силу того, что логика всего процесса от составления заявки на оказание услуги до момента успешного оказания услуги будет впоследствии меняться и дополняться, у меня есть желание сосредоточить этот алгоритм в одном пакете классов, отделив его от более мелких алгоритмов внутри этапов.
2. Ветвления алгоритма, важные для процесса в целом, определяют несколько типичных сценариев протекания этого алгоритма. У меня таких сценариев получилось пять, но в будущем будет больше: до 10-15.
3. Логическую последовательность этапов и условия переходов от одного этапа к другому я предполагаю зашить в класс «бизнес-процесс». Все мои сценарии зашить в маленькие классы-стратегии (паттерн Стратегия), описывающие конкретную последовательность этапов. Каждый этап зашить в свой класс «этап» и в нем уже реализовывать всю логику взаимодействия объектов домена в пределах этапа.
4. идеи есть еще, но пока ограничусь этими.

Проблема:
1. Не изобретаю ли я велосипед? Если да – то ткните в нос типовым решением.
2. Стоит ли сосредотачивать логику бизнес-процесса в одном месте?
3. Декомпозицию логики бизнес-процесса на классы «бизнес-процесс», «сценарий» и «этап» я кратко описал – насколько она плоха/хороша и в каких ситуациях может себя повести (может, сейчас все просто, пока система мала)?

Очень надеюсь на конструктивную критику. Если появятся вопросы, могу снабдить пояснения UML диаграммами.

4
Работа / Re: Начало карьеры
« : 23 Января 2008, 09:20:45 »
Кроме того, важно понимать, что устроившись сейчас с нулевым опытом в помощники аналитика вы с большой вероятностью никогда не станете полноценным архитектором
что по-вашему нужно, чтобы с большей вероятностью стать полноценным архитектором?

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

5
Работа / Re: Начало карьеры
« : 23 Января 2008, 00:11:30 »
Не в обиду Максиму, но жизненный опыт приучил не относиться всерьез к решениям относительно профессиональной специализации, принятым "раз и навсегда" в студенческие годы....
....В-общем, не торопитесь со специализацией, а попытайтесь лучше получить кругозор.
Нет не в обиду, конечно... я и сам прекрасно на себе испытал смену интересов и даже приоритетов.
Сейчас мне интересна тема проектирования, и продолжает интересовать уже где-то 2 месяца. Мне нравится, что я готов к новому и готов учиться ради этого, тратить силы, время и деньги. Мне нравится, что я не увалень, желающий только ничего не делать и получать зарплату. Мне нравится, что мне не нравится стоять на месте. И сейчас я направляюсь в сторону ооап.

А насчет того, что я уже сейчас думаю о позиции "главного специалиста" или "архитектора" - как своей потенциальной должности в будущем - так ведь приятно ж иметь настолько соблазнительные мечты, желания, ориентиры!

6
Работа / Re: Начало карьеры
« : 22 Января 2008, 21:38:01 »
Для начала не совсем ясно какую карьеру Вы хотите делать. Программиста или аналитика.
Я хочу проектировать ПО. И в этом процессе проектирования быть ближе к технической стороне вопроса, чем к  финансовой.

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

Про курсы на интуит.ру знал и раньше. Сейчас читаю оттуда UML, пока не пришел Фаулер из Озона. Очень полезный портал.

Вопрос, скорее всего, аппелирован к людям, которые сами сейчас работают в сфере проектирования ПО. Интересно, как они проникли в эту сферу, где самообучения явно недостаточно, хотя оно и находится, как мне кажется, на втором месте после богатого опыта. Другими словами: Как дальше по карьерной лесенке к главному системному архитектору - меня не интересует. А вот как стать ассистентом аналитика (или как называется низшая должность в этой сфере) - для меня очень интересно. Как ощутить это порог вхождения и что надо, чтоб его преодолеть?

7
Работа / Начало карьеры
« : 22 Января 2008, 19:38:14 »
Здравствуйте, всем!
Представлюсь, так как новичок. Максим Пшеничников, студент 4го курса, веб-программист-самоучка. Очень нравится программировать. Меня, что называется, прет от него (так сказали на одном из собеседований). Мне очень интересна сфера разработки ПО. Сейчас разбираюсь с основами UML, параллельно читаю про паттерны у Фаулера, скоро приступлю к книге Крэга Лармана.

Так вот сам вопрос: кратко распишите мне примерный путь образования/карьеры от студента технического вуза до успешного специалиста в области ООА/П.

Спрашиваю потому, что, естественно, спецом стать только с помощью книг нельзя: нужна реальная практика использования этих знаний в условиях реального бизнеса. Где найти такую практику? Ответ: на работе. Но как пробиться на такую работу, чтобы заниматься там ООА/П? Вот именно "как забраться на первую ступеньку в карьере ООА/П" интересует меня больше всего.

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

Страницы: 1