Author Archives: pavel

Уход в облака

Ray Ozzie, недавно покинувший пост главного архитектора Microsoft, написал в блоге о том, куда IT-индустрия идёт: http://ozzie.net/docs/dawn-of-a-new-day/

Идёт она давно и верно в облака.

 

«Instead, to cope with the inherent complexity of a world of devices, a world of websites, and a world of apps & personal data that is spread across myriad devices & websites, a simple conceptual model is taking shape that brings it all together.  We’re moving toward a world of 1) cloud-based continuous services that connect us all and do our bidding, and 2) appliance-like connected devices enabling us to interact with those cloud-based services.»

 

Что-то, однако, такой подход, когда всё в облаках, душу не греет. По двум причинам: privacy и надежность.

 

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

Остаётся риск проблем с интернет-соединением. Но это уже не такая проблема, как раньше. В США, как я понимаю, практически все места, где есть люди, покрыты сетями 3G и WiMAX, а с проводным интернетом так и вовсе никаких сложностей. В России и других странах третьего мира всё куда хуже, но по-тихоньку подтягиваются. В достаточно крупных российских городах (уровня Красноярска) хороший проводной интернет уже есть наверное везде, но с мобильной связью  достаточно туго: покрытие 3G, не говоря уже о WiMAX, оставляет желать лучшего.

Проблемы надежности, пожалуй, можно откинуть. Отсутствие интернета в наше время – такой же форс-мажор, как и отключение электричества :)

 

А вот что делать с безопасностью – не ясно :( Облако могут поломать. Или оно может само куда-то слить ваши данные, хотя бы государственным службам. А иногда облако может дотянуться до вашего железа и, скажем, стереть с вашего iPhone какую-нибудь программу или данные. Что, естественно, мало кого устроит.

 

–

Павел Сурменок

http://surmenok.ru/

 

LINQ

В данный момент я руковожу несколькими проектами на платформе .NET. Давно я не писал о разработке. Технологии разработки ПО за последние годы серьёзно развились.

Чего только стоит Microsoft LINQ. Эта штука – фактически язык запросов для данных, независимо от их источника. Можно и для БД применять (это LINQ to SQL), можно для XML, можно для списков/массивов. На днях пришлось накидать простенькую софтину на пару сот строк кода, и для работы с данными (который в БД SQL Server 2008 лежат) решил применить LINQ. Ниже кусочек кода:

using (DataClassesDataContext dc = new DataClassesDataContext())

{

dc.Names.InsertAllOnSubmit(names

.Where(n => n != “”)

.Distinct()

.Except(dc.Names.Select(n => n.Title))

.Select(n => new Name() { Title = n }));

dc.SubmitChanges();

}

Здесь я беру string[] и закидываю эти данные в БД, для каждого элемента массива создавая отдельную строку в таблице Names. При этом тут же делается проверка на уникальность, как в исходном массиве (если строка в массиве встречается дважды, то обрабатывается только один раз), так и в БД ( если в таблице уже есть строка с таким значением в поле Title, то я её не добавляю). Также проверяем на то, что строка не пустая.

Просто, кратко и удобно. На всё 10 строк простого хорошо читаемого кода.

С решениями Microsoft приятно работать.

–

Павел Сурменок

http://surmenok.ru/

Об iPhone

Много разговоров про Apple и её продукцию. В т.ч. недавняя серия постов в блоге http://dz.livejournal.com/ (там в данный момент как раз идёт мегасрач в комментах :) ).

http://dz.livejournal.com/606046.html

http://dz.livejournal.com/606431.html

http://dz.livejournal.com/606914.html

http://dz.livejournal.com/607059.html

 

«Вспомнилось, как одну даму спросили, где хранится текст, который мы выделили мышкой и нажали copy, но перед тем, как нажали paste.

- “Конечно в мышке!“, – сказала она, посмотрев на вопрошающего как на идиота.

Вы реально не представляете себе уровень юзеров.»

 

В целом из этих дискуссий выходит, что Apple целит в неграмотных пользователей.

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

 

Но вот чего я не понимаю: зачем все эти возможности  Apple блокирует вовсе?

Подход Android, на мой взгляд, более здравый: http://dz.livejournal.com/606914.html?thread=12383426#t12383426

Android даёт людям удобно и без напряжения мозга делать простые вещи: позвонить, СМС отправить, календарь, музыка, фото и прочее. Но при этом не закрывает более хитрые возможности.

Я сам пользуюсь HTC Desire. И меня радует, что скажем нет ограничения на интерфейсы. Я телефон к компьютеру вообще не подключаю шнурком. Всё через мобильный интернет и WiFi (причём сеть WiFi он сам нашел и подключился). Программы с маркета качаются через интернет. Файлы тоже сливаются с интернета. Без лишних ограничений. Даже OS телефон обновил сам, без подключения к компьютеру.

 

Еще любопытно будет на Win Phone 7 глянуть. Но судя по обзорам, они ближе к Apple :( Например, софт можно только из маркетплэйса ставить, каждая программа в своей песочнице, а при разработке софта для связи с серверам даже сокеты недоступны. Поурезали всё, что можно. Но маркетинг могуч, видимо продавят  платформу. Да и по UI, говорят, приятен весьма.

 

–

Павел Сурменок

http://surmenok.ru/

 

Ian Alexander

Искал, что же хорошего почитать об инженерии требований. И нашел.

На международной конференции по проблемам системной инженерии RuSEC 2010 в Москве присутствовал Ian Alexander, уже не один десяток лет занимающийся проблемами инженерии требований. Жаль, что я не смог поприсутствовать на конференции, потому что судя по слайдам, доклад был замечательный.

На сайте Яна можно найти его публикации.

А еще он автор трёх книг о требованиях: Writing Better Requirements (2002),  Scenarios, Stories, Use Cases (2004),  Discovering Requirements (2009). Их можно без проблем найти в интернете. Я сейчас читаю последнюю, надо сказать, очень полезно и практично.

 

–

Павел Сурменок

http://surmenok.ru/

 

Вступил в INCOSE

Вступил в INCOSE (International Council on Systems Engineering).

Немного попарился с оплатой. Платить надо картой. У меня MasterCard Standard, с него оплата не проходит. ailev говорит, что есть два варианта: либо завести специальную карту для интернет-платежей, например MasterCard Virtual), либо связаться с центральным INCOSE и попросить провести платёж в ручном режиме.

С INCOSE Central я связаться не смог: на два моих e-mail’а ответа так и не пришло. Поэтому сделал MasterCard Virtual и оплатил ей. Видимо это самый простой вариант.

Стоимость года членства в INCOSE – 105 долларов. После вступления можно посещать заседания русского отделения INCOSE (http://incose.ru/), в т.ч. и удалённо. Также центральный INCOSE заверил меня, что «membership in INCOSE offers a tremendous number of benefits» и дал доступ к ресурсу INCOSE CONNECT, на котором предоставляются какие-то ништяки, пока не смотрел, какие именно.

 

–

Павел Сурменок

http://surmenok.ru/

User Requirements Notation

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

Я посмотрел, по ссылочкам походил, почитал, и решил для начала попробовать URN. Потому что там есть акторы, есть цели.  

Как позже выяснил, посмотрев 22-е заседание русского чаптера INCOSE (24 февраля 2010), Левенчук тоже моделирует требования к своему чем-то-там-ядерному в URN. Значит велика вероятность, что я копаю в правильную сторону :)

 

Итак, что же такое URN… Это User Requirements Notation. Нотация пользовательских требований. Включает в себя:

·         GRL – Goal-oriented Requirement Language – целеориентированный язык требований – для нефункциональных требований.

·         UCM – Use Case Map scenario notation – нотация карт сценариев использования – для функциональных требований.

URN была стандартизирована ITU (International Telecommunication Union) как рекомендация Z.151 в ноябре 2008.

Подробней можно почитать у Левенчука http://ailev.livejournal.com/800769.html, а также тут http://jucmnav.softwareengineering.ca/ucm/bin/view/UCM/WebHome, далее по ссылкам.

GRL основан на подмножестве языка i*.

i* framework – conceptual modeling language for capturing the social characteristics of complex systems in terms of actors, their intentions, and their relationships. Actors are viewed as being intentional, i.e., they have goals, beliefs, abilities, and commitments, which must be discovered and properly documented.

О соотношении GRL с i* и о том, как дополнить GRL полезными штуками из i* (роли, агенты, позиции): http://jucmnav.softwareengineering.ca/ucm/pub/UCM/VirLibRIGiM09/RIGIM09-AmyotEtAl.pdf

Есть плагин для Eclipse, который позволяет рисовать модельки в этих нотациях. http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/WebHome

 

В связке GRL и UCM мне почему-то более интересен GRL. В нём определены акторы, цели, решения (Tasks, не знаю, как лучше перевести: решения/задачи/действия), обоснования. Также можно задавать стратегии.

Туториалы по GRL:

http://www.cs.toronto.edu/km/GRL/tutorial.html

http://jucmnav.softwareengineering.ca/ucm/pub/UCM/VirLibComNet03/ComNet03.pdf

 

–

Павел Сурменок

http://surmenok.ru/

 

Определение модели

При обсуждении каких-то сложных вещей сразу возникают проблемы с терминологией – стороны по-разному толкуют термины.

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

Наиболее распространено такое общее определение:

In the most general sense, a model is anything used in any way to represent anything else. Some models are physical objects, for instance, a toy model which may be assembled, and may even be made to work like the object it represents. However a conceptual model, may only be drawn on paper, described in words, or imagined in the mind. They are used to help us know and understand the subject matter they represent.

Т.е. обычно под моделью понимают нечто, что каким-то образом используется, чтобы представить что-то другое. Даже игрушечный самолётик можно считать моделью самолёта. В каком-то смысле (с чьей-то точки зрения) и кусок железа можно считать моделью самолёта.

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

A model is an approximation, representation, or idealization of selected aspects of the structure, behavior, operation, or other characteristics of a real-world process, concept, or system (IEEE 610.12-1990), i.e. an abstraction.

A model usually offers different views in order to serve different purposes. A view is a representation of a system from the perspective of related concerns or issues (IEEE 1471-2000).

Здесь уже говорится о том, что модель – это идеализация, абстракция чего-то из  реального мира.

Дальше смотрим пояснение сущности модели у Левенчука:

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

Далее эту идею можно развивать и преломлять (например, считать, что оперативная память — это не физическое представление, а что-то иное, и в зачёт идут только разные отображения — на экран, принтер, графопостроитель и т.д.). Но это уже детали.

Вот как-то так. Далее, понимая, что есть модель в MBSE, можно уже рассуждать о том, как модели соотносятся с документами, как понять, где уже моделеориентированная системная инженерия, а где еще олдскул и прочее, прочее.

 

–

Павел Сурменок

http://surmenok.ru/

 

Моделеориентированная инженерия требований

Инженерия требования, как и в целом системная инженерия, может быть документоориентированная (олдскул), может быть моделеориентированная (ньюскул).

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

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

В моделеориентированной инженерии требований требование – это модель (или кусок модели или её элемент), с указанием на то, что система должна следовать этой модели. Требование состоит из 3 частей:

1.    Модель

2.    Деонтический оператор. Он предписывает: “должен”, “не должен”, “must”, “recommended”, “insist” и т.п.

3.    Стэйкхолдер, заинтересованная сторона. Это тот, чьё требование. При этом должно проверяться, имеет ли он право на то, чтобы говорить, что должно быть так.

 

Ох, запутанно как-то написал… Ну ничего, как поглубже вникну в эту связку документы vs модели – напишу понятней.

 

–

Павел Сурменок

http://surmenok.ru/

 

Высокотехнологический распил

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

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

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

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

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

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

 

–

Павел Сурменок

http://surmenok.ru/