Qt, пока все еще qt.

Бьюсь с qt creator за правильное расположение виджетов. Бой неравный. В первом раунде, при расположении horizontal layout, я выйграла. Все отображается как надо. Но победа оказалась добыта только после такого финта ушами, что ужас просто. Чтобы компоновщик заработал, его обязательно нужно включить через меню вызова компоновщика, при выделении нескольких объектов для компоновки. При том, что в дизайнере есть объект компоновщика на панели для перетаскивания. Но если просто его перетащить, то работать почему-то не будет. Ужас. Настроить компонтвщик для своих самодельных виджетов у меня пока так и не вышло. Они выравниваются вручную. Хорошо что я догадалась их поместить на одну панель. Панель из стандартных виджетов, поэтому она компоновщику подвластна.  Еще одна непонятная вещь -как вручную править horizontal header элемента table view. Примеры из интернета не хотят компилироваться. Он редактируется только через дизайнер. Так что, вопросов к qt пока намного больше, чем ответов.

Имитационное моделирование

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

Как изучать чужой код

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

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

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

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

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

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

Итак, здесь есть несколько способов-отмычек, чтобы чужой код стал яснее. Я, как всегда, пишу статью  как будущего помощника себе самой. Может быть, и вам поможет применение данных методов. Может быть, что все эти методы не помогут. Видимо, в этом случае придется писать все с нуля. Кстати, это тоже метод изучения программ:). Желаю удачи!

Что такое HLA?

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

Что такое HLA

HLA (High Level Architecture, архитектура высокого уровня) - это архитектура для моделирования и имитирования. Используя HLA компьютерные модели могут взаимодействовать (т.е. обмениваться данными и синхронизировать действия) с другими компьютерами, не смотря на различие платформ. Взаимодействия между моделями управляеся RTI (Run-Time Infrastructure Инфрастструктура среды исполнения?).

HLA - это стандарт возможности взаимодействия для распределенных моделей, применяемый для поддержки ананлиза, разработки и управления,  тренировки в некоторых областях, как:

• средства обороны;
• управление воздушным транспортом;
• здравоохранение.

Она разработана под стандартом IEEE1516.
 IEEE 1516-2010 - Стандарт архитектуры высокого уровня для моделирования и имитации  - структура и правила.
IEEE 1516.1-2010 -Стандарт архитектуры высокого уровня для моделирования и имитации  - спецификации федерального интерфейса (сервера).
  IEEE 1516.2-2010 - Стандарт архитектуры высокого уровня для моделирования и имитации  - спецификация шаблона объектной модели.
IEEE 1516.3 - 2003 Рекомендуемая практика разработки HLA федерации и процесс использования.
IEEE 1516.4-2007- Рекомендуемая практика для проверки, валидации и аккредитации федерации как надстройка над разработкой HLA федераций и процессом использования.

Технический обзор

HLA состоит из следующих компонентов:

• Cпецификация интерфейса(Interface specification): определяет, как HLA совместимые модел взаимодействуют с RTI, предоставляющим библиотеку и api (прикладной программный интерфейс) совместимый с интерфейсной спецификацией.
• Шаблон объектной модели(Object Model Template): определяет какая информация взаимодействует между моделями и как она документируется.
• Правила(Rules). Модель жестко подчиняется, для того, чтобы соответствовать стандарту.
• Федерат(Federate). Сущность, единица модели, совместмая с HLA.
• Федерация(Federation) - множество моделируемых сущностей, соединяющихся с помощью RTI, используя  шаблон объектной модели(OMT).
•  Объект(Object)  - набор связанных посылок данных между моделями (? тактами моделирования).
• Атрибут (Attribute) - поле данных объекта.
• Взаимодействие(Interaction) - действие, посланное между модельными сущностями.
• Параметр(Parameter) - поле данных или взаимодействие.

Спецификация интерфейса.

Спецификация интерфейса объектно-ориентированно в соответствии с техническими условиями С++ или Java. Она разделена на группы:

• Управление федерациями.
• Управление объявлениями.
• Управление объектами.
• Управление имуществом(ownership).
• Управление временем.
• Управление распределением данных.
• Сервисы поддержки.

Шаблон объектной модели.

Шаблон объектной модели представляет собой общую структуру для коммуникации между HLA моделями. Он зависит от следующих документов:

• объектная модель федерации(FOM);
• объектная модель одного федерата(SOM).

Правила.

Правила описывают обязанности федерации и присоединенных федератов.

1. Федерации должны иметь HLA FOM, документированную в соответствии с HLA шаблоном объектной модели.
2. В федерации все представления об объектах в FOM должны быть в федератах, а не в инфраструктуре (RTI).
3. В течение работы федерации все обмены данными между федератами должны проходить с помощью RTI.
4. В течение работы федерации, федераты должны взаимодействовать с RTI в соответствии со спецификацией интерфейсов HLA/
5. В течение работы федерации атрибуты текущего состояния объекта должны принадлежать только одному федерату в любой момент времени ( не поняла точно этот пункт, поэтому привожу оригинал:During a federation execution, an attribute of an instance of an object shall be owned by only one federate at any given time.)
6. Федераты должны иметь HLA SOM, документированную в соответствии с HLA OMT.
7. Федераты должны быть способны обновлять и/или отражать любые атрибуты объектов в их SOM и посылать и/или получать SOM взаимодействие извне, как установлено в их SOM.
8. Федераты должны быть способны передавать и/или принимать имущество (ownership) атрибута динамически в течение работы федерации, как установлено в их SOM.
9. Федераты должны быть способны изменить условия, под которыми они осуществляют обновления атрибутов объектов, как установлено в их SOM.
10. Федераты должны быть способны управлять локальным временем способом, который позволит им координировать обмен данными между федератами.

OpenRTI

OpenRTI это реализация RTI c открытым исходным кодом. Эта реализация представляет следующие три версии RTI:
RTI13 - HLA версия 1.3
RTI1516 - первый HLA стандарт версии 1516
RTI1516e - HLA стандарт 1516-2010


Итак, перевод закончен.
Из ближайших планов на работу: мне необходимо изучить интерфейс RTI1516, т.к. он используется. Ура. Это только одна папка из трех. Хоть чуть понятнее стало.

Качество ПО, часть 2.

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

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

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

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

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

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

Качество По

Я перескакиваю в пересказе на несколько глав вперед. Одно время, я забросила конспектирование, и только отмечала в книге интересные места. так вот, я добралась до главы, которая меня очень взволновала. И хочу ее не только запомнить, но и переосмыслить.
Итак, Макконнелл перечисляет некоторые из характеристик качества ПО, внешние:

• корректность;
• практичность;
• эффективность;
• надежность;
• целостность;
• адаптируемость;
• правильность;
• живучесть.

И внутренние:

• удобство сопровождения;
• гибкость;
• портируемость;
• возможность повторного использования;
• удобочитаемость;
• тестируемость;
• понятность.

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

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

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

Макконелл привел таблицу эффективности обнаружения дефектов. Выводы из этой таблицы меня поразили. Я давно читала книгу про разработку через тестирование, и была уверена, что если бы могла легко протестировать автоматически визуальную часть приложения, в ней было бы меньше ошибок. Но оказалось, что блочное тестирование дает шанс выявить в среднем 30% ошибок. И что самыми хорошими результатами обладали формальные инспекции кода, моделирование, формальные инспекции проекта. По эффективности их обошло только масштабное (более чем в 1000 организаций) бета-тестирование. Вот так вот интересно.

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

Чтение кода способствует нахождению дефектов интерфейса, а функциональное тестирование - нахождению дефектов управляющих структур.  Интересно. Но эту вещь я не проверяла.

Методики поиска дефектов лучше применять в комбинации. Одни методики помогут обнаружить одни дефекты, а другие - еще некоторые.

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

Как важны мелочи 2

Программа не работала оттого, что я не написала один пробел в запросе на создание БД.
Это добавление к посту о том, как важны мелочи.