Собственно, даже не знаю, это надо сюда постить, или в Тестирование, или в Философию вообще =)
Вопрос такой. Есть ведь куча древних метрик для софта, вроде Холстедовских, которые еще в универе нудно читают. Есть более продвинутые, посовременнее. Но все, как правило, оперируют исходным кодом, который можно почитать, запустить на выполнение и т.п.
А есть ли где метрики (и где их искать), которые призваны оценить качество проектных решений? Например, имея для ОО-приложения статическую структурную диаграмму классов и диагр. последовательности/взаимодействия (или ту же информацию в другом виде — не важно), требуется определить, какая из предложенных архитектур "лучше" решает задачу. То есть понятно, что архитектура сама по себе может накладывать дополнительные ограничения как на объем данных в возможных получающихся в результате программах, так и на скорость их работы (скажем, некая архитектура подразумевает хранение графа в виде матрицы смежности, а не списка инцидентности... или в архитектуре "прошит" односвязный список неких объектов, когда лучше было бы использовать в каких-то случаях красно-черные деревья). Вот, например, с этой точки зрения хотелось бы сравнить предложенные архитектуры. Ну, или еще по каким-то показателям. Или, скажем, сколько ошибок на каждый класс можно ожидать при внедрении, и т.п.
Потратил сегодняшний вечер на поиски — так ничего конкретно по теме не нашел. Разве что пара ссылок (платных), которые тоже еще не факт, что описывают нужные мне вещи.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Собственно, даже не знаю, это надо сюда постить, или в Тестирование, или в Философию вообще =)
SM>Вопрос такой. Есть ведь куча древних метрик для софта, вроде Холстедовских, которые еще в универе нудно читают. Есть более продвинутые, посовременнее. Но все, как правило, оперируют исходным кодом, который можно почитать, запустить на выполнение и т.п.
SM>А есть ли где метрики (и где их искать), которые призваны оценить качество проектных решений?
Нету даже отношения порядка, чтобы говорить что лучше.
Метрики качества обычно являются функциями от некоторых базовых, типа связности и количества строк.
SM>То есть понятно, что архитектура сама по себе может накладывать дополнительные ограничения как на объем данных в возможных получающихся в результате программах, так и на скорость их работы (скажем, некая архитектура подразумевает хранение графа в виде матрицы смежности, а не списка инцидентности... или в архитектуре "прошит" односвязный список неких объектов, когда лучше было бы использовать в каких-то случаях красно-черные деревья).
Если архитектура диктует способ хранения данных, то это хреновая архитектура.
SM>Вот, например, с этой точки зрения хотелось бы сравнить предложенные архитектуры. Ну, или еще по каким-то показателям. Или, скажем, сколько ошибок на каждый класс можно ожидать при внедрении, и т.п.
Если бы такие было доступно, то давно холивары корнчились бы в этом форуме.
Даже если получится придумать метрику , то оценивая решение локально невозможно понять что будет во всем сотальном проекте. По опыту некоторые решения могут дать значительное снижение mantainability index в одном классе и увеличить его во всем проекте.
Здравствуйте, gandjustas, Вы писали:
SM>>Вот, например, с этой точки зрения хотелось бы сравнить предложенные архитектуры. Ну, или еще по каким-то показателям. Или, скажем, сколько ошибок на каждый класс можно ожидать при внедрении, и т.п. G>Если бы такие было доступно, то давно холивары корнчились бы в этом форуме.
Вовсе нет. Скажем, метрики для оценки ОО приложений давно существуют. Например, "число всех методов в классе, включая унаследованные". Но это лишь "узкопрофильные" метрики, они не учитывают соответствие архитектуры поставленной задаче и среде, в которой предстоит работать, и вообще они основаны на "среднем по больнице" среди группы проектов, протестированных автором метрики. Так что простора для споров более чем достаточно. Но меня это устраивает — мне как раз и нужны формальные метрики, просто чтобы привести какие-то количественные оценки архитектуры.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Здравствуйте, gandjustas, Вы писали:
SM>>>Вот, например, с этой точки зрения хотелось бы сравнить предложенные архитектуры. Ну, или еще по каким-то показателям. Или, скажем, сколько ошибок на каждый класс можно ожидать при внедрении, и т.п. G>>Если бы такие было доступно, то давно холивары корнчились бы в этом форуме.
SM>Вовсе нет. Скажем, метрики для оценки ОО приложений давно существуют. Например, "число всех методов в классе, включая унаследованные". Но это лишь "узкопрофильные" метрики, они не учитывают соответствие архитектуры поставленной задаче и среде, в которой предстоит работать, и вообще они основаны на "среднем по больнице" среди группы проектов, протестированных автором метрики.
Эти метрики вообще ничего не показывают кроме "числа всех методов в классе, включая унаследованные". Как оно повлияет на mantainability, usability кода, а также на кол-во ошибок совершенно непонятно.
Кроме того если даже удастся получить характеристики для решения X остается напонятным как оно пвлияет на совокупность решений XYZ.
SM>Но меня это устраивает — мне как раз и нужны формальные метрики, просто чтобы привести какие-то количественные оценки архитектуры.
В студии есть метрики, можно там посмотреть.
