diego sevilla’s weblog
it is better to remain silent and be thought a fool,
than to open your mouth and remove all doubt -- groucho marx

4/2/2009

Más avances: Cátedra SAES-UMU

Como un avance inédito (se firma mañana), os diré que otra cosa que me ha tenido muy ocupado los últimos meses (en realidad años) es lo que hemos llamado la “Cátedra SAES-UMU”. Esta cátedra significa un apoyo monetario a la investigación que una empresa privada, en este caso la Sociedad Autónoma de Electrónica Submarina (SAES), ofrece a la Universidad de Murcia a través de unos promotores de la misma (en este caso Gregorio Martínez y yo mismo). El acuerdo será por dos años, y pronto prepararemos una página web con algunos resultados que estamos obteniendo en nuestras investigaciones.

La cátedra se financia por la empresa, y permite que nosotros contratemos a personal que realiza investigaciones, tesis, etc. (camos, la labor de la Universidad), mientras que la empresa se beneficia de que orientemos nuestras investigaciones hacia temas que le sean de interés. Esta sinergia universidad-empresa es el fin último de la Universidad, que tiene que proveer conocimiento básico que finalmente se pueda aplicar a una empresa.

Personalmente estoy muy contento (y también orgulloso en cierto grado), como sé que lo está Gregorio, de que esta empresa haya confiado en nosotros para ofrecernos esta oportunidad, también teniendo en cuenta que es la cátedra de más cuantía económica que se ha realizado nunca en la Universidad de Murcia. Esta confianza mutua se ha ido fraguando a lo largo de tres años de colaboraciones puntuales con la empresa en tópicos relacionados con el modelado de aplicaciones, software libre, programación en C++, programación distribuida y CORBA (sí, chichos, por extraño que parezca), etc.

La firma la realizará el Rector de la Universidad de Murcia junto con el director general de SAES mañana miércoles 4 a las 10 de la mañana en el edificio de convalecencia de Murcia. Irá también la prensa, así que no descarto que aparezca en los periódicos.

Nada más por hoy que mañana tenemos un acto importante…

3/2/2009

Avanzando temas: Tesis

Bueno, aquellos que me conocéis o que estáis en mi círculo más cercano sabréis que el año pasado estuve bastante ocupado, dejando a un lado casi a mis amistades, aficiones, … todo lo que no fuera la tesis.

El trabajo de escribirla e implementarla fue inmenso para mí. Quizá otras personas tengan más facilidad o no les cause tanto estrés y cansancio, pero a mí me dejó exhausto. Tanto que cuando la terminé ya no quiero ni volver a verla.

Sí me gustaría, no obstante ir comentando poco a poco cómo la hice, los puntos importantes, y mostrar la propia tesis, que al menos, si alguien la lee, o alguna parte de ella, que al menos tenga la sensación de que sirve para algo…

La presentación de la misma fue el día 4 de noviembre, y todo fue bien. Menos mal, después de tanto trabajo. Parece que les gustó a los miembros del tribunal (que me calificaron con Summa Cum Laude por unanimidad).

Por ahora os dejo una página que hice para mostar la tesis a los miembros del tribunal. La tesis está en PDF (ojo, 64MB), y también página a página. Que la disfrutéis. Me guardo para después explicar un poco de la tesis en sí misma y de cómo la fui desarrollando.

28/10/2008

Parecía que nunca iba a llegar…

Filed under: General, CORBA & Component Model (CCM), español — Diego Sevilla @ 20:56 — In English

… pero el otro día recibí el correo que he estado esperando varios años ya :)

Hola a todos,

Tengo el placer de comunicaros que el próximo día 4 de noviembre de 2008
Diego Sevilla Ruiz presentará su tesis doctoral titulada «Desarrollo del
Modelo de Componentes Distribuido CORBA Lightweight Components
(CORBA-LC)». La defensa tendrá lugar en el Salón de Grados de la Facultad
de Informática a las 12:00h.

Estáis todos invitados. De nuevo, perdonad a todos los que no os he respondido en el correo, correos pendientes de Planet Murcia, etc. Con suerte, este día 4 de noviembre estaré libre (por un tiempo) para relajarme un poco, y dedicar tiempo a estas tareas más relajantes…

17/9/2008

:)

Filed under: CORBA & Component Model (CCM), español, fotografía/photo — Diego Sevilla @ 1:06 — In English


:), originally uploaded by dsevilla.

¡Sí! ¡Por fin! Esto que me ha tenido apartado de Flickr y de mi vida normal ya está terminado por fin. Años de sufrimiento, desesperación y trabajo resumidos en 396 páginas. Ya vuelvo a la vida.


14/7/2007

Boston skyline by night

Filed under: CORBA & Component Model (CCM), english, español, fotografía/photo — Diego Sevilla @ 16:38 — In English


Boston skyline by night, originally uploaded by dsevilla.

Estos días estoy en Cambridge en el NCA’07. No he tenido tiempo de hacer muchas fotos ni de subirlas, pero aquí una que pude hacer la otra noche. Mañana de vuelta a España, aunque llego el lunes…

These days I’m in Cambridge at the NCA’07 conference. It’s a really nice city, and although I haven’t had much time to make photos, I had the chance to go out by night and take this.

19/4/2007

En Julio al Network Computing and Applications en Cambridge, Massachusetts

Filed under: General, CORBA & Component Model (CCM), español — Diego Sevilla @ 23:13 — In English

Bueno, no iba a ser todo malo hoy. Hoy me han comunicado que me aceptan un artículo que envié a este congreso. En la página web del NCA’07, organizada por el IEEE, podéis ver que es del 12 al 14 de julio de 2007, en Cambridge. No está mal visitar esa zona en verano… :) Estoy muy contento porque significa un espaldarazo a la tesis, que espero terminar este año. Tener un artículo internacional publicado a la hora de presentar la tesis implica que el tema tratado tiene aceptación científica en el entorno de la investigación.

18/10/2006

Fowler, inversion del control

Filed under: CORBA & Component Model (CCM), español, código/code — Diego Sevilla @ 23:47 — In English

Quizá es un poco antiguo el artículo, pero ahora que quiero empezar a escribir mi tesis, basada en componentes y contenedores, este artículo me viene genial para saber quién tuvo una de las primeras ideas de cómo implementar contenedores y sus consideraciones asociadas. La «Inversión de control» implica aplicar el Principio de Hollywood a la construcción de software. En EJB y CCM (también en el código de mi tesis, por cierto), y en la mayoría de los _frameworks_ para construir interfaces de usuario, el control no lo toma el programa desarrollado por el usuario (el componente EJB, por ejemplo), sino que lo toma el propio entorno de ejecución, que llama al componente cuando necesita alguna acción por parte del componente o requiere algún dato del mismo.

La comunicación entre contenedor (el que hace de gestor de los componentes) se inicia normalmente estableciendo un contexto de ejecución, en el que se le indican al componente las características del entorno de ejecución (por ejemplo, qué servicios tiene a su disposición, como persistencia, etc.) y continúa con el contenedor llamando a las operaciones implementadas por el componente cada vez que se requiere su ejecución.

En los entornos distribuidos (en concreto de componentes distribuidos), esta inversión se da a muchos niveles. Por ejemplo, para cada interfaz se genera un _stub_ y un _skeleton_. Este último llama a las operaciones implementadas por el componente cuando un cliente requiere que se ejecuten (esto es, una llamada llega por la red). De hecho, este principio es el más básico de todos los sistemas remotos, desde RPC de Sun hasta CORBA y su modelo de componentes (CCM).

14/4/2006

doing a PhD is hard (ii)


doing a PhD is hard (ii), originally uploaded by dsevilla.

Diagrama de jerarquí­a del generador de código de mi tesis.

9/11/2005

Un día de trabajo con mi tesis

Filed under: CORBA & Component Model (CCM), español, código/code — Diego Sevilla @ 1:44 — In English

Quiero poner desde hace tiempo cosas de mi tesis. Sobre todo porque así me animo a escribir y a explicar lo que hago, de cara a empezar a escribirla. Básicamente traba de componentes en CORBA. Cada componente ofrece un conjunto de interfaces como interfaces «ofrecidos». Estos interfaces son como «vistas» de un mismo componente.

La mayoría del código de los componentes se genera automáticamente, salvo el código propio del componentes, que lo tiene que programar el programador. En particular, se debe generar el código que retorna valores adecuados para cada uno de los interfaces. Por ahora estoy con el generador de código. A grandes rasgos, y ya que no puedo explicar todo el diseño aquí, diré que he aumentado el IR (_Interface Repository_, que describe cómo son los interfaces de los objetos) de CORBA para añadir componentes e interfaces ofrecidos. El IR de CORBA estándar sólo contiene definiciones de interfaces normales, y no componentes, por lo que he tenido que aumentarlo.

El generador de código sigue una estrategia de _visitor_ del árbol aumentado del IR (árbol semántico), en la que va generando el fichero de salida. La generación se realiza de manera que el _visitor_ de cada nodo del árbol genera una salida en forma de una variable de texto. Así, por ejemplo, el nodo para «Componente» genera una variable llamada «Component». Imaginemos que una parte de esa variable de texto incluye una función como la que sigue:

...
corbalc::UserArtifact_ptr
%(qualified_component_name)s_impl::queryIfaceArtifact (const char* name)
{
        ServantMapType::const_iterator it;

        if ((it = ServantMap_.find( name )) == ServantMap_.end())
                return NULL;

        %(SearchForArtifacts)s

        return NULL;
}
. . .

Este trozo de texto generará la función queryIfaceArtifact. Nótese que los elementos entre «%(» y «)s» son variables que se sustituyen al recorrer elementos más internos en el árbol. En el caso de los componentes, hay varios elementos más internos: operaciones, atributos, interfaces requeridos e interfaces ofrecidos.

Nótese también que esta función depende del valor de una variable llamada «SearchForArtifacts». Esta variable, tal y como lo tengo implementado, debe contener el código que retorne un objeto del tipo adecuado según el valor de la variable «name» de la función. Así, se genera una comprobación para cada uno de los interfaces ofrecidos. El código del visitador que genera el valor necesario para la variable «SearchForArtifacts» es el siguiente:

        class SearchForArtifactsVisitor: public generic::ProvidedIfaceVisitor
        {
        public:
                SearchForArtifactsVisitor(codegen::util::Context *c)
                        : generic::ProvidedIfaceVisitor(c)
                {
                }

                const char*
                variable() const
                {
                        return "SearchForArtifacts";
                }

                const char*
                pattern_file() const
                {
                        return "CppImplTemplates/SearchForArtifacts";
                }

                void
                traverse (corbalc::AIR::ProvidedIfaceDef_ptr i)
                {
                        CORBA::String_var id = i->id();
                        IRID irid (id);

                        ctx_->vm_ ["idl_iface_name"] = id;
                        ctx_->vm_ ["qualified_iface_name"] = irid.cppFQN(false);

                        stringstream lengthstr;
                        lengthstr << strlen (id);
                        ctx_->vm_ ["idl_iface_name_length"] = lengthstr.str();

                        ctx_->vm_[variable()] +=
                                pattern().substitute (ctx_->vm_);
                }
        };

Sé que este código por sí solo es difícil de entender, pero creo que uno se puede hacer una idea con las siguientes aclaraciones:

1. Esta clase hereda de «ProvidedIfaceVisitor» esto es, es capaz de visitar los interfaces que ofrece el componente.
2. Por tanto, la función «traverse» se ejecutará para cada interface ofrecido por el componente.
3. La función «variable» retorna la variable de texto que será el resultado de este _visitor_ (SearchForArtifacts).
4. La función «pattern_file» especifica el fichero de patrón que se utilizará para hacer de esqueleto de esa variable. Como pasaba en el caso del componente, se utiliza un patrón en el que se sustituyen valores de variables que son a su vez cadenas de texto (lo veremos después).
5. La función «traverse», como puede verse, genera el valor para unas cuantas variables que se utilizarán dentro del patrón, como puede ser «qualified _interface _name», que después veremos que forma parte del patrón para generar esta variable.
6. El valor de la variable «SearchForArtifacts» se añade a lo que ya haya en esa misma variable al final de la función «traverse», con lo que se generará código para todos los interfaces ofrecidos. Ese código se dejará en la variable citada, que a su vez forma parte de la variable «Component», que a su vez forma parte de la variable «Fichero», que genera el fichero final.

(Sé que es un poco complicado, pero creo que expresa la idea).

¿Cómo es el patrón para generar la variable «SearchForArtifacts»? Aquí está:

// Iface %(idl_iface_name)s
if (!strncasecmp (name, "%(idl_iface_name)s", %(idl_iface_name_length)s))
{
        %(qualified_iface_name)s_impl* i =
             dynamic_cast<%(qualified_iface_name)s_impl*>((*it).second);

        return corbalc::UserArtifact::_duplicate (i->executor_);
}

Nótese que contiene las variables a rellenar por el _visitor_, como «qualified _iface _name». Este patrón, una vez relleno, se sustituye en el primero de los patrones mostrados para construir la variable «Component», y así sucesivamente hasta el fichero a generar.

Quizá esto no haya explicado bien lo que hago, pero sí que ha dado una idea de lo penoso del proceso. Supongamos que quiero probar el código generado. Lo que hago es modificar el generador de código. Este generador lo uso para generar código para los componentes de prueba. Los pruebo, y si dan errores (de compilación o funcionamiento) tengo que volver atrás el proceso para revisar los patrones de generación, que contienen los ficheros, pero por partes, lo que complica la cosa, modificarlos acorde con los errores que se hayan producido y repetir el proceso de construir el generador, generar el código y compilar.

La única buena noticia es que al estar basado en patrones, muchas de las veces sólo modificando los patrones de generación es suficiente para arreglar los errores que se hubieran producido o añadir nueva funcionalidad. Así sólo tengo que generar de nuevo el código de los componentes, pero no recompilar el generador.

Si lo hubiera diseñado ahora, quizá habría diseñado un lenguaje específico del dominio, como están ahora tan de moda (y no por casualidad), lo que habría hecho casi innecesario recompilar el generador de código, a costa de que el generador sería más complejo. Este es un tema muy complejo y extenso, que no puedo tratar ahora, y que quizá deje para otro post, pero en general, el lenguaje dedicado en cuestión estaría en concordancia con el orden de visita de los nodos del árbol, y permitiría especificar de forma no funcional qué hacer en cada uno de los nodos. Eso lo dejaré para una posterior entrada.

21/10/2005

Sistemas Distribuidos

Filed under: General, CORBA & Component Model (CCM), español, código/code — Diego Sevilla @ 19:39 — In English

Como ya he dicho alguna vez en este weblog, imparto en la Facultad de Informática la asignatura de Sistemas Distribuidos. El otro día tuvimos la introducción a la asignatura en la que hacía un pequeño repaso en lo que han sido (y son) los sistemas distribuidos. Desde los sistemas centralizados a los sistemas distribuidos actuales, servicios Web, CORBA, etc. Esto suscitó una pregunta de un alumno, Bassman contertulio de Planet Murcia, y que no sabía que lo tenía de alumno. He aquí su pregunta (con pequeñas ediciones, ya que fue en un correo electrónico):


Todo eso está muy bien lo de CORBA, middleware y tal pero… ¿qué pasa
con los pequeños electrodomésticos o dispositivos móviles que
utilizarán servicios distribuidos? Es viable implementar esas
arquitecturas en hardware con poca capacidad? Por otra parte, las
arquitecturas middleware y los buses asíncronos de comunicación
implementan una arquitectura lógica cliente-cliente, pero sigue
existiendo la necesidad de administrar el canal común mediante algún
tipo de servidor, al igual que en redes P2P se acceden a servidores
para darse de alta en el servicio distribuido.

Todo esta duda me surge porque ya sois dos los profesores que habéis
comentado ambas tecnologías, dejando “en el aire” algo tan importante
como es la gestión de ese canal común. ¿Es tan sencilla su
implementación o está ya tan optimizada que no merece la pena
comentarlo? Quiero saber más al respecto.

En la asignatura de “Desarrollo de Aplicaciones Distribuidas” de la
intensificación del software vamos a dar de forma casi exclusiva web
services en plataforma Java, y ahí nos lo pintan todo como muy en
auge, mientras que tú nos das una imagen de decadencia.

Por último, […] sobre
programación en C++, en la carrera no nos dan NADA de NADA, ya que el
resto del profesorado prefiere usar Java por ser más “didáctico” y más
“de moda” (me supongo).

Interesantes reflexiones. Déjame que te responda en orden.

Primero, me preguntas sobre los dispositivos de poca capacidad hardware. Supongo que te refieres a teléfonos móviles/PDAs. Me encanta que me hagas esa pregunta, porque precisamente, existen varias implementaciones de CORBA para ellos. Por ejemplo, LUAOrb. Además, existen especificaciones como Minimum CORBA diseñada y pensada específicamente para este tipo de periféricos. La mayoría de implementaciones de CORBA actuales permiten compilar casi sin restricciones todos los ORBs de libre distribución en PDAs. Por ejemplo, Eduardo Martínez, también de la Universidad utiliza MICO compilado en una PDA, y muchos de los operadores de telefonía (por ejemplo Telefónica) utilizan CORBA para gestionar las conexiones telefónicas. Lo bueno de estos aparatos pequeños es que cada vez se hacen más potentes.

Hablas después de los buses de comunicación «peer-to-peer». Interesante reflexión. También hablé yo de la gestión de arquitecturas MOM («Message-Oriented Middleware»), que se basan en un bus de comunicación. ¿Qué pasa con la gestión de ese bus? Pues que se puede realizar, como bien dices y es el caso de los sistemas p2p, gracias a un servidor. Los elementos que se conectan al bus no tienen que tener un protocolo especialmente complejo, ya que sólo indican su presencia, y recogen todos los mensajes que circulan por la red, siendo capaces de enviar también sus propios mensajes. El símil de este caso con dispositivos pequeños lo tenemos en una tecnología que utilizamos todos los días: los móviles. Imagina la red GSM como un bus en el que se envían y reciben mensajes de una aplicación distribuida. Ahí tendrás la respuesta a tu pregunta sobre dispositivos pequeños. Imagina la torre receptora como gestor de los distintos canales y ya está.

El siguiente punto que mencionas es mi particular aversión a los servicios Web. Te diría que esperes a ver ambas asignaturas y decidas por tí mismo. El paradigma de servicios web se encuentra en la actualidad ante un franco estancamiento. Sí, las empresas utilizan los servicios web, al menos eso dicen. Sin embargo, en cinco o seis años de desarrollo, no han pasado de ser utilizados para servicios simples de petición/respuesta. Mi principal crítica, resumiendo, son varias. Primero, el paradigma de servicios web se basa en un protocolo (SOAP) que no está optimizado para comunicaciones distribuidas, ya que está basado en texto y es muy ineficiente (esto, por sí solo, y teniendo en cuenta que los servicios web se utilizan para realizar aplicaciones distribuidas, ya es un error grave). Después, se ha puesto mucho hincapié en que los servicios web permiten comunicar cualquier cliente y servidor sobre Internet, etc., cosa que ya se lograba con otras tecnologías (véase CORBA) hace muchos años. Además, hay un conjunto monstruoso de especificaciones, muy difíciles de comprender y sobre las que nadie llega a un consenso. Después de 5 años no han llegado a consenso en cuestiones tan simples como el «workflow» de servicios web (totalmente necesario para realizar servicios web en cascada), etc. Todo eso ya era posible en CORBA, y de una manera mucho más natural y con estándares más sencillos. Etc, etc, etc.

Por último, el problema de C++. Veo muy mal que no se enseñe C++ en una Ingeniería Informática. Sin entrar en guerras de lenguajes de programación, pienso que C++ es hoy por hoy uno de los lenguajes más importantes y más utilizados, y un Ingeniero debería conocerlo como la palma de su mano. En la asignatura procuraremos introducirlo para que a partir de ahí seais capaces de desarrollar código CORBA/C++. Es triste, pero muchos profesores ni siquiera saben programar en C++ y no conocen sus beneficios, como la STL.

Espero haber despejado algunas dudas. Un saludo.

19/10/2005

Interesting post on XML messaging by Stefan Tilkov

Filed under: CORBA & Component Model (CCM), english, código/code — Diego Sevilla @ 0:01 — In English

Just a little while after I wrote something about people talking about CORBA failure, I find this post that I wanted to link it because I have some questions that I stated in his web site. You can read the post and comments here. It refers to an article in Steve Vinoski’s weblog, that in turn refers to another one of Mark Baker claiming that CORBA has failed. By now, I’ve heard that so many times that I can assure it’s not true :) Mark itself refers to another article from John Udell that I can’t find. Mark says that the primary reasons for CORBA failure are technical ones… Well, Web Services haven’t still reached the level of maturity or technical development that CORBA has…

12/10/2005

CORBA Reborn?

Filed under: CORBA & Component Model (CCM), english, crítica/critics, código/code — Diego Sevilla @ 12:43 — In English

I sure was expecting this. People is realizing Web Services are not the “Right way to go” ™. The other day I came trough a post in Patrick Logan’s weblog (Making it stick), CORBA redux about a conversation in ACM Queue between Roger Sessions and Terry Coatta. Contradictions comming from Sessions are noted in Patrick Logan’s weblog. Surprisingly enough, Sessions admited WS-* standards being even more complicated than the CORBA counterparts, arguing that WS-* specs. are just for Microsoft and IBM architects to be understood, not programmers.

I tend to think that people have forgotten what CORBA really is and what does it exactly do. CORBA did 10 years ago what WS specs. are not finishing to define in five years of development. Also, CORBA specs., at least many of them, are an example of well-written and complete documents.

29/7/2005

Impressive OpenCCM 0.9.0 release

Filed under: CORBA & Component Model (CCM), english — Diego Sevilla @ 12:13 — In English

OpenCCM 0.9.0 has been released, with an _impressive_ set of features and changes. I’ll comment more on that in the next days. Keep the cool work, guys!!

openccm

19/5/2005

Stefan Tilkov on RPC Web Services

Filed under: CORBA & Component Model (CCM), english — Diego Sevilla @ 10:14 — In English

I found this interesting. Have had not enough time to read it carefullly, but I think it’s interesting somebody these days dare remembering CORBA and sets its position right among the Web Services technologies.

10/4/2005

Survey about Components

Filed under: CORBA & Component Model (CCM), english — Diego Sevilla @ 20:37 — In English

Bayu Hendradjaya sent me the interview I include below. It would be nice everybody doing components-related work to answer it and send it back to him.

"A SURVEY ON COMPONENT BASED METRICS"

A. GENERAL ISSUES QUESTIONS
---------------------------
A.1 Please describe your development and application
environment and platform briefly?

A.2 When you use CASE tool to develop the software
a) Specify your CASE tool

b) Describe how it helps you in developing the Component
Based software.

c) What are the unresolved problems with such tools?

A.3 How well is your system documented?

A.4 Do you find reusing components technically difficult?
State/describe the difficulties involved.

A.5 How many times did you reuse a component before you
become confident with its "blind re-use"?

A.6 Do you use any visualization mechanism to represent your
software system?

B. COMPONENT ISSUES QUESTIONS
-----------------------------
B.1 Do you find some components to be more complex than
others? If yes, how do you define complexity?

B.2 Do you find some components to be more critical than
others? If yes, how do you define criticality?

B.3 Do you find the specification document for components
are clear  enough to be used in software development? Please
explain.

B.4 Are the interfaces between components well-defined? What
would be your interpretation of the term "well-defined"?

B.5 How do you make a judgment on the security aspects of
third party components?

B.6 What procedures do you adopt in order to impart
trustworthiness to the components that you have developed?

B.7 Describe/state any metrics that you use to "measure"
various issues in (B.5) and (B.6) above.

C. COMPONENT INTEGRATION ISSUES QUESTIONS
-----------------------------------------

C.1 During integration, do you use your own components,
third party  components or both? Please describe the reasons
for your choice.

C.2 How are the components specified (e.g., using CIDL/MIDL,
etc) in your environment?

C.3 How are the dynamic behaviors of components captured?
(e.g., using OCL?)

C.4 How many components on average do you integrate into
your system per day/week?

C.5 What depth of component hierarchy do you tolerate before
you declare that the system is "very complex"?

C.6 How many people on average are involved in integrating
components? What is the average system integration time (in
days)?

C.7 What are the key issues do you encounter during integration?

D. QUESTIONS ON DIFFICULTIES IN COMPONENT INTEGRATION
-----------------------------------------------------
D.1 What problems did you experience during component
integration?
Please list.

D.2 List/describe the issues/problems that you encounter
when integrating third-party components?

D.3 What problems do you encounter when integrating an
updated versions of third-party components?

D.4 How do you manage change in requirements during
integration of components?

E. QUESTIONS ON RISKS IN COMPONENT INTEGRATION
----------------------------------------------
E.1 What risks did you face during component integration?
Please explain.

E.2 How did you identify and ameliorate the risks during
component integration?

F. METRICS ISSUES RELATED QUESTIONS
-----------------------------------
F.1 For your CBSE-based system development
a) Explain the nature of metrics used.

b) Do you use any special software metrics generator tool?
If yes, please specify the name

c) How do you measure the development of your software using
these metrics?

d) How do you find the usefulness and effectiveness of these
metrics?

e) Please specify the limitations of the metrics used, if any.

F.2 Please explain the degree of confidence in chosen
metrics in predicting the system behavior.

F.3 Do you use special metrics for component integration? If
yes, please describe the metrics, and if not, do you think
to need one?

------------ end of survey

18/3/2005

New version of the CCM tutorial

Filed under: CORBA & Component Model (CCM), english — Diego Sevilla @ 1:21 — In English

Douglas C. Schmidt, from Vanderbilt University has updated his tutorial on CORBA Component Model. I haven’t had time to review it, but I’ll do it soon. You can download it here (PPT). Feel free to review it and send him comments/suggestions. I’ll post an update with my impressions on the tutorial when I have the chance to read it.

2/12/2004

CCM Wiki updated

Filed under: CORBA & Component Model (CCM), english — Diego Sevilla @ 11:47 — In English

Long time ago I updated the c2.com’s wiki. It was so long ago that I even didn’t remember it… I added the CCM page to the page on the CORBA Component Model. Now Enric Jaen has taken the effort to update it including this weblog and some other things. Thanks, Enric! The page can be modified by anyone, as any Wiki. Let’s see if people contributes… :)

26/11/2004

New version of StarCCM

Filed under: CORBA & Component Model (CCM), english — Diego Sevilla @ 21:23 — In English

Back on September this year, a new version of StarCCM was released. Taken from their web page, it seems to be feature-rich:

New version supports multithread, a visible assembling tool, a graphic management tool, and can support dynamic deployment. New version StarCCM can upgrade assembly online.

German book on CCM

Filed under: CORBA & Component Model (CCM), english — Diego Sevilla @ 21:08 — In English

Tom Ritter announced in Qedo-devel mailing list that he (with Bertram Neubauer and Frank Stoinski) published a book about the CCM titled “CORBA Komponenten.” Tom was searching for people who wanted to publish it in English.

Recent articles on CCM

Filed under: CORBA & Component Model (CCM), english — Diego Sevilla @ 20:53 — In English

I read recently in Middleware Matters (Steve Vinoski’s Weblog) that he published a new article about the CCM jointly with Douglas C. Schmidt. The article is titled “The CORBA Component Model Part 4: Implementing Components with CCM”. Fourth of the series, the other entries can be found here: (part 1), (part 2), and (part 3).

Next Page »

Creative Commons License
This work is licensed under a Creative Commons License.
EWWV  AWStats  Site Meter 24 queries. 0.130 seconds. Powered by WordPress
406021 email messages processed in this box. 10858 were spam

0