Quantcast

ComponentHouse.com

Discussion about software development and related topics. ok
Hugo by Hugo @ in Others

English


ABAT: An Approach for Building Maintainable Automated Functional Software Tests
XXVI International Conference of the Chilean Computer Science Society
Iquique, Chile, November 2007
Marcos Kalinowski, Hugo Vidal Teixeira and Paul Johan Heinrich van Oppen.

Model-Based Generation of Business Component Architectures
30th European Computing Conference (EUROMICRO'04)
Rennes, France, August/September, 2004, pp. 176-183.
Hugo Vidal Teixeira, Regina Braga Villela and Cláudia Werner.

Applying Management Model and Ontology on a Telecommunication Company
13th International Conference on Software & Systems Engineering and Applications
Paris, December, 2000.
Carmen Maidantchik, Kátia Oliveira, Hugo Vidal Teixeira and Maria Lúcia Masiero.

Português



Javascript Fácil com jQuery
(Easy Javascript with jQuery)
Published in the brazilian Java Magazine #54 (January/2008).





Animações com JGoodies
(Animations with JGoodies)
Published in the brazilian Java Magazine #42 (December/2006).
Source code: codigo_GUI_jm42.zip





Validação de Dados com JGoodies
(Data Validation with JGoodies)
Published in the brazilian Java Magazine #40 (October/2006).
Source code: codigo_GUI_jm40.zip





Interfaces Gráficas com Qualidade - Parte 2: Presentation Model e a API Binding do JGoodies (GUIs with Quality - Part II: Presentation Model and the JGoodies Binding API)
Published in the brazilian Java Magazine #39 (September/2006).
Source code: codigo_GUI_jm39.zip





Interfaces Gráficas com Qualidade - Parte 1: Conceitos Fundamentais e a API Forms do JGoodies (GUIs with Quality - Part I: Fundamental Concepts and the JGoodies Forms API)
Published in the brazilian Java Magazine #38 (August/2006).
Source code: codigo_GUI_jm38.zip




Geração da Arquitetura de Componentes a Partir da Modelagem Funcional
(Generation of Component Architecture from Functional Models)
VII Workshop of Thesis on Software Engineering (WTES'2002), Gramado, Rio Grande do Sul, October, 2002.
Hugo Vidal Teixeira, Regina Braga Villela and Cláudia Werner.

Geração da Arquitetura de Componentes a Partir da Modelagem Funcional
(Generation of Component Architecture from Functional Models)
2nd Workshop on Component-based Development (WDBC'2002), Itaipava, Rio de Janeiro, August, 2002.
Hugo Vidal Teixeira, Regina Braga Villela and Cláudia Werner.

LockED: Uma Ferramenta para o Controle de Alterações no Desenvolvimento Distribuído de Artefatos de Software
(LockED: A Tool to Control Changes in Distributed Development of Software Artifacts)
15th Brazilian Symposium on Software Engineering (SBES'01), Tools Session, Rio de Janeiro, October, 2001.
Hugo Vidal Teixeira, Leonardo G. P. Murta and Cláudia Werner.

LockED: Uma Abordagem para o Controle de Alterações de Artefatos de Software
(LockED: An Approach to Control Changes over Software Artifacts)
IV Iberoamerican Workshop on Requirements Engineering and Software Environments (IDEAS'01), San José, Costa Rica, April, 2001.
Hugo Vidal Teixeira, Leonardo G. P. Murta and Cláudia Werner.
Hugo by Hugo @ in Others
My name is Hugo Vidal Teixeira and I am an expert software developer and architect with a strong background in component-based software engineering and User Interfaces. I work as an independent consultant and the reason behind this website is that I want to share my thoughts with people around the world and contribute with articles and ideas to improve software quality.

I have graduated from the Federal University of Rio de Janeiro (UFRJ) and I also have a Master's degree (MSc) in software engineering from COPPE/UFRJ.

My experience in software development is considerably large and varies from fine-grained components to large-scale distributed systems. In our software world, my passion for components and GUI started just before my MSc studies and it has now become part of my every day life. I have created frameworks and APIs to investigate these areas and this has improved my knowledge far beyond those concepts explained in books and articles.

My interest in user interfaces is quite old. However, in the last years I have been improving more and more my knowledge of and experience in GUI design and programming. Besides working with relevant companies in this field - such as Centigrade, OculusInfo and Ergosign, - I had the opportunity to learn valuable skills with Karsten Lentzsch (owner of JGoodies) and also use my free time to read significant books like The Design of EverydayThings, User Interface Design for Programmers, Designing Visual Interfaces and others.

It is important to remember that math plays an important role in my interest in UIs, specially in vectorial calculus and analytical geometry (in fact, this has been a great contribution from the university). To give you an idea of what this means to me, I have created about six diagramming tools (three in c++ and three in java) just to exercise my knowledge in this area. Let alone the 3D software with OpenGL and other libraries.

Besides software development, I usually like to play soccer with my friends. Actually, I like to juggle a soccer ball when I have to find solutions for my problems (and software development problems are pretty tricky!). This is sort of relaxing and the results are really good. You should try it yourself!
Hugo by Hugo @ in English
This is the second part of my UI lessons from the real world article. It has more funny examples of what (not) to do with your UIs.

You guessed it, folks. After the huge success of my first article Ten UI Lessons from the Real World, I decided to write the second part with more examples. Again, the idea is to teach UI lessons based on real world images that are funny and interesting for this type of discussion.

Lesson 11 – Don't redefine concepts



Please look at the image on the left. Why on earth would someone call a banana a "curved yellow fruit"?! OK, it is curved, it is yellow and it is a fruit, but WTF?

If you don’t know how to call a certain thing, please ask the business analyst. Don’t try to create a name that is meaningful to you but meaningless to the user. Applications should have standardized concepts and the whole team should understand them. FYI: this field of research is called ontology and it is a great domain analysis tool.

Lesson 12 – UIs should never surprise the user



The UI should never surprise the user. If it does, then the designer has failed to do a good job. One example of this problem is a link that doesn’t look clickable. This is actually conflicting with the idea that UIs should be clear and intuitive. How can something be surprising and intuitive at the same time?

Joel Spolsky has explained this lesson on his book User Interface Design for Programmers. Refer to the book if you want to see more examples on this problem.

Lesson 13 – UIs should never scare the user


Users shouldn’t be scared by the UI. If they are, they won’t use the system correctly and you will fail as a software engineer. If something can go wrong, it is your responsibility to create restrictions that will prevent wrong actions (unless the business itself is risky – e.g., trade market).



Lesson 14 – Don't ask users to do stupid things



I see two types of stupidity when it comes to user interfaces. The first type happens when the UI directly asks the user to do something stupid. This is best explained by the image on the left. Would you put your mouth on that thing? If you answered YES, you should talk to a psychiatrist. Some users might fall on that trap, but the real person that should be considered stupid is the person that invented that thing.


The other type of stupidity happens when you indirectly imply that something stupid can be done. You somehow tease the imagination of those people that have low IQ scores and have nothing else to do in life:



Lesson 15 – UIs should be easy to read



One of the ideas behind simplicity is that UIs should be understandable and easy to read. The clock on the left is an example of how things can get critical if you must read it immediately. Of course you know the position of the numbers, but imagine different situations where you must read them (e.g., the clock is rotated 90 degrees). Since you need some seconds to calculate the numbers, this will distract (and even disturb) you more than needed. By the way, what time does the clock show right now?

Lesson 16 – Users should never ask "What is this?"


 Which animal is this? Is this a cat? A bunny? Some people say it is a small camel! Use your imagination :-P

Users should never ask questions like "What is this?" when it comes to your UI. If they do, the designer has failed to create a good intuitive interface. UAT (User Acceptance Tests) is a great tool to find problems in this sense and you should talk to your team about this. Watch how your friends use the software application and ask them to do certain tasks (e.g., open a new document; create a new invoice, etc). You should also talk to the support team and see what people have been complaining about. You will learn a lot from that, trust me.

Lesson 17 – Don't distract users with obvious messages


Please look at the next two signs and think. Are they useful in your opinion? What is the chance that you won’t see the stairs, but will see the sign? Or what is the real value of the second sign and its warning?



Please don’t add obvious messages to your UIs because they will distract (and probably disturb) your users. UIs should guide the user, not force them to look at every detail on the screen. Their eyes should do this job seamlessly.

Lesson 18 – Accessibility should work in practice



We all know that accessibility features (in general) are used by just a small group of users. But if you decide to implement them, please make sure they are really useful in practice. If you don’t know what I mean, please look at the image on the left.

Look, there are nice toilets on the second floor! Yes, but you need a crane if you are on a wheelchair.

Lesson 19 – Know your users



You can’t create good interfaces if you don’t know your users. Things can get more difficult if they are aliens, but it is always possible to figure out what they really want. Talk to your users (maybe using a translator helmet) and try to understand how the see the world (not only our world, but also their world).

Lesson 20 – Creativity Again


The last lesson of my previous article was about creativity and its powerful effects on our brains. I will keep creativity again as the last lesson of this second part because it is really worth doing so. Please look at the AXE marketing signs displayed at shopping centers and malls... they are simple, easy to understand and – most important – have a real marketing message.



Conclusion


This was the second part of my article about user interfaces and their lessons from the real world. What is most fascinating is the fact that we can take lessons from almost anything visual. All we need is to think about our problems and create a bridge to real world signs and objects. Stay tuned for the next articles.
Hugo by Hugo @ in English
Learn UI concepts from real world pictures. Signs can teach valuable lessons in this regard and you should pay attention to them.

User interface isn’t a subject specific to computers. Every object in the real world has an interface and understanding it is crucial for a correct usage. Some objects are well designed and can offer different types of good reactions when we interact with them. Others aren’t that good and the designer might have missed the point.

Today I am going to teach some UI lessons based on signs and pictures of the real world. If you pay careful attention, you can realize that they do have lessons to be learned and you can use that knowledge to improve your UIs. This is a valid approach because we – as humans – have a common way of looking at things, be it a system UI, a coffee machine, a vacuum cleaner or signs on the roads. Signs on a road are my favorites because they guide the driver pretty much like icons guide users on a system interface. Let’s start our lessons.

Lesson 1 – Review your Icons




Please look carefully at the sign on the left. What is the meaning of that sign? Are there cows that bite and eat cars?!?

Actually, if you add an icon to your application, make sure it is understandable. Don’t try to create your own if you are not prepared for this task. UI designers should handle that. The biggest issue behind this problem is the fact that users have fear of clicking on things they don’t understand. This can get even worse if their money is involved in the action.



Another problem related to icons is best explained when we look at the image on the right. At first glance, you might see a dentist with a patient. But if you look closer, you might note a dirty second meaning. Would you let your wife go to that dentist? I don’t think so...

Lesson 2 – Unrelated information shouldn’t be displayed together



Look at this second example. By placing both signs together, it is inevitable to imagine people hunting children. When the worker placed the second sign, he probably saw the problem, but he didn’t care. He might have thought that the problem was with him, not with other people.

Trust me, this also happens on your UI. Please keep unrelated information clearly separated from other types of information.

Lesson 3 – Use the right punctuation or appropriate separators


 Isn’t that yummy? This might be good for your cholesterol levels.

Note that a missing separator clearly creates a misleading scenario that can ruin your business. Your interface can also suffer from that if you don’t pay careful attention. If you are not fully convinced, remember that when you read the same sentence several times, your brain starts to ignore or misinterpret it.

Lesson 4 – Redundancy increases complexity



This sign is in Portuguese, but I don’t think we need a translation here. The problem is right ahead and it is difficult to understand why people keep repeating the same information again and again. What worries me is the fact that they do that too often.

Redundancy might be important in some cases (especially when it comes to security), but it can be avoided in most situations. Note that when we remove redundancy we improve simplicity.



Another type of redundancy is in the meaning of words. The next sign provides a good example of how bad this can be. Maybe they are really telling the whole truth...

Lesson 5 – Identify and remove conflicting ideas


Conflicting ideas can be deadly critical. Look at the three pictures below and think about their explanations: an ant that goes to the opposite direction of the sign, police that can’t turn right while normal people can do so, or a land full of poison just to protect living animals. What could be stranger than that?

The same concepts apply to user interfaces. It is very easy to think that you wouldn’t do such mistakes, but people do that and we have to admit. So look carefully at your UIs and search for conflicting ideas.



Lesson 6 – Hide unnecessary precision



Sometimes too much precision can be useless. Take a closer look at the next sign and let me know if that extra half mile is important to you. Information like that is inappropriate for the situation and only adds noise and clutter. Drivers usually have just a few seconds to read a sign and the more information you add, the worse it will be. The same applies to a software UI.

Lesson 7 – Fix typos


Typos happen in every corner of the world (see pictures below) and it is your responsibility to fix them. It is quite common nowadays to have non-native speakers in the development team. So, besides typos, people can simply write wrong words because they don’t master the UI language.



Lesson 8 – Sentences with the right meaning



A sentence with a wrong meaning is worse than a typo. That’s the case of our next sign: If your worries aren’t strong enough to kill you, the church can give *them* a hand.

Sentences in the UI can also be misleading, mainly when the system tries to explain more than needed. Your UI – and its sentences – should be simple, small and clear enough to guide the users.

Lesson 9 – Alignment



Alignment is important because users don’t read text on the UI. They scan it. So, well aligned text and controls can help dividing the screen into digestible pieces of information. Unfortunately this isn’t the case of our next picture. After reading the first sign, I wonder if people hire cats to make burgers with their flesh.

Lesson 10 – Creativity saves the day



At last, remember that your creativity can connect the user with a whole new experience. Let your imagination fly when you build user interfaces, as it happens with the guys from the last picture. Good interfaces make users forget their computers pretty much like readers forget their books when they read good stories.

Conclusion


This article was an attempt to show my different point of view on user interfaces. The idea of showing real signs is just a funny way to teach concepts that can make applications more usable. Remember that everything around us can teach lessons, but only those that really pay attention can take advantage of that. This is a daily exercise that you should execute when you drive or walk on the streets. It is worth trying, trust me.

Read the second part of this article »
Hugo by Hugo @ in English
Learn a trick to shrink images using the Java2D API, which creates high-quality image icons for your applications.

Image resize with java isn't a new topic. What I want to explain here is a technique to create small high-quality images using the Java2D API, since I couldn't find any reasonable solution on the Internet. The are some solutions available - like this one - but the final quality is low.

You can use this approach for different purposes, but the best example I can think of is the implementation of small avatars on web applications (see Nabble, DZone, etc.) or desktop software (e.g., Skype, MSN, etc.).

In order to show the contribution of this technique, I have to explain image resize from the beginning. We will improve the algorithm as we go and I also assume you have some background with Java2D.

Reading and Writing the Image


Since this is a simple example, I will read an image from the file system, resize it and save it back. The image I am using is below. Note that I am using a JPG file, which is the common format for pictures.



To read this image, we can use the ImageIO class:
BufferedImage image = ImageIO.read(new File("c:\picture.jpg"));

First Attempt


Now we have to find a way to resize this image. Our first attempt is to use the drawImage() method of the Graphics interface:
private static BufferedImage resize(BufferedImage image, int width, int height) {
    BufferedImage resizedImage = new BufferedImage(width, height,
    BufferedImage.TYPE_INT_ARGB);
    Graphics2D g = resizedImage.createGraphics();
    g.drawImage(image, 0, 0, width, height, null);
    g.dispose();
    return resizedImage;
}
With this method, we can create a 24x24 avatar by calling:

Image resized = resize(image, 24, 24);
The last step is to save the image so that we can see the results. The ImageIO class can do this job:

ImageIO.write(resized, "png", new File("c:\picture1.png"));
Note that the second parameter is the format of the saved image. I used "png" because it is simpler. If you want to save it as JPG, you will have to use the JPEGImageEncoder class (and the result is the same, trust me).

The result of this method is a low-quality image:


Pay attention to the details of the image (look closer). There is no anti-alias and the face is distorted. Would you add such algorithm to your web application? I don't think so. Users could get scared by looking at those images.

Second Attempt


We noticed that the main problem of the resize() method above is the fact that it doesn't have anti-aliasing. So we could use the Rendering Hints of the Java2D API as an attempt to solve that problem:
private static BufferedImage resize(BufferedImage image, int width, int height) {
    int type = image.getType() == 0? BufferedImage.TYPE_INT_ARGB : image.getType();
    BufferedImage resizedImage = new BufferedImage(width, height, type);
    Graphics2D g = resizedImage.createGraphics();
    g.setComposite(AlphaComposite.Src);

    g.setRenderingHint(RenderingHints.KEY_INTERPOLATION,
    RenderingHints.VALUE_INTERPOLATION_BILINEAR);

    g.setRenderingHint(RenderingHints.KEY_RENDERING,
    RenderingHints.VALUE_RENDER_QUALITY);

    g.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
    RenderingHints.VALUE_ANTIALIAS_ON);

    g.drawImage(image, 0, 0, width, height, null);
    g.dispose();
    return resizedImage;
}
The result is below (right image). If you pay attention to the details, it is somewhat better, but still trash:


Finally, The Trick


Now I will explain how to improve the quality of this image. Basically, the trick is to blur the image before resizing. The code that blurs an image in java is:
public static BufferedImage blurImage(BufferedImage image) {
    float ninth = 1.0f/9.0f;
    float[] blurKernel = {
        ninth, ninth, ninth,
        ninth, ninth, ninth,
        ninth, ninth, ninth
    };

    Map map = new HashMap();

    map.put(RenderingHints.KEY_INTERPOLATION,
    RenderingHints.VALUE_INTERPOLATION_BILINEAR);

    map.put(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY);
    map.put(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);

    RenderingHints hints = new RenderingHints(map);
    BufferedImageOp op = new ConvolveOp(new Kernel(3, 3, blurKernel), ConvolveOp.EDGE_NO_OP, hints);
    return op.filter(image, null);
}
Since the original image is in the JPG format, we can't blur it directly. We have to create a compatible image first:
private static BufferedImage createCompatibleImage(BufferedImage image) {
    GraphicsConfiguration gc = BufferedImageGraphicsConfig.getConfig(image);
    int w = image.getWidth();
    int h = image.getHeight();
    BufferedImage result = gc.createCompatibleImage(w, h, Transparency.TRANSLUCENT);
    Graphics2D g2 = result.createGraphics();
    g2.drawRenderedImage(image, null);
    g2.dispose();
    return result;
}
Blurring the image before resizing it isn't the only trick. You have to do this when the width or height of the image is 100px. Since small avatars are usually a square (width = height), you can resize it to 100x100, call the blur() method and resize again to 24x24:
private static BufferedImage resizeTrick(BufferedImage image, int width, int height) {
    image = createCompatibleImage(image);
    image = resize(image, 100, 100);
    image = blurImage(image);
    image = resize(image, width, height);
    return image;
}
(the resize() method is the one described in the second attempt)

Now you can compare the three results:


Conclusion


This was my contribution to the tough problem of shrinking images using the Java2D API. I would like to remember that this isn't the ultimate algorithm to achieve that goal, but it is good enough considering its simplicity. If you have comments or feedback, I would like to hear them.

Source code: ComponentHouseResizer.java
Hugo by Hugo @ in English
In this article jQuery is tested with different selectors in order to find specific elements in the DOM tree. The delay of each selector is precisely calculated and the idea is to find out which one is the fastest for the given goal.

jQuery is one of the best javascript libraries I have ever worked with. It is quite simple and usually reduces the amount of javascript code in web applications. Besides all the advantages it brings to the web community, we have to pay attention to a few details when reusing this library in order to get the best part of it.

I will describe a few tips on how to improve the performance of your javascript code. Most of these tips aren't a big deal if your pages are small and simple. But if you create complex html pages, you should follow them in order to prevent the browser from locking when the page loads up. Even if you are not concerned with performance at all, learning these things will bring benefits to your overall knowledge about this library.

jQuery has a bunch of different selectors - as you can see from the documentation here - and I won't consider all of them in this analysis. My idea is to explore different ways of finding a specific element in the html page by using different types of search. Benjamin Sterling has already researched this topic here, but I want to add a different point of view, which is more accurate and provides more alternatives for the developers.

Let me start talking about the test html page, which has over 20,000 elements separated in chuncks of 5,000. Basically, there are 5,000 <div> + 5,000  + 5,000 <p> and 5,000 <small> with the following characteristics:

<!-- 5000 'div' elements -->
<div id="a-0" class="div-0" row="a-0">Div 0</div>
<div id="a-1" class="div-1" row="a-1">Div 1</div>
...
<div id="a-4999" class="div-4999" row="a-4999">Div 4999</div>


<!-- 5000 'span' elements -->
<span id="b-0" class="span-0" row="b-0">Span 0</span>
<span id="b-1" class="span-1" row="b-1">Span 1</span>
...
<span id="b-4999" class="span-4999" row="b-4999">Span 4999</span>


<!-- 5000 'p' elements -->
<p id="c-0" class="p-0" row="c-0">Paragraph 0</p>
<p id="c-1" class="p-1" row="c-1">Paragraph 1</p>
...
<p id="c-4999" class="p-4999" row="c-4999">Paragraph 4999</p>


<!-- 5000 'small' elements -->
<small id="d-0" class="small-0" row="d-0">Small 0</small>
<small id="d-1" class="small-1" row="d-1">Small 1</small>
...
<small id="d-4999" class="small-4999" row="d-4999">Small 4999</small>

The 20,000 elements above are generated by javascript. They provide a good laboratory to check the speed of each selector, since we can expect more accurate results in this analysis. The page itself has a few more tags to display information and execute each test, but this shouldn't affect the final results.

The test page is available here. It takes a few seconds to load because the javascript must create the DOM tree as described above. So please be patient. Note also that each test uses the measure() function, which calculates the delay of the call in milliseconds.

Test 1 - Finding an element by ID


The first test is to find an element by its ID. I decided to get the element whose ID is "d-2642". We can do this in three different ways:

A - Using the ID selector
$('#d-2642').html()

B - Using attribute search
$('[id="d-2642"]').html()

C - Using attribute search + tag
$('small[id="d-2642"]').html()

Running this test for the first time in different browsers, I could reach the results displayed in the following table (in milliseconds). It is clear that the # operator is the most efficient one.
                                                                                                                                                                                                                                                                                                                                                                                                                                                               
FirefoxOperaIE6IE7Safari
A156031400
B36098282344841844
C57893406210172

Test 2 - Finding an element by Class


Although CSS classes are intended to be reused among elements, you might create some elements with a unique class name just to identify and retrieve them through javascript. This is exactly what we test in this second test by seaching the element whose class is "p-4781". We have four alternatives:

A - Using the class selector
$('.p-4781').html()

B - Using the class selector + tag
$('p.p-4781').html()

C - Using attribute search + tag
$('p[class="p-4781"]').html()

D - Using tag search + filter
$('p').filter('.p-4781').html()


After running this test for the first time in different browsers, I got:
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       
FirefoxOperaIE6IE7Safari
A28916411718631329
B4537831318078
C422109578201187
D20326637521094

The table above shows case B as the fastest selector for most browsers (except Firefox). It is easy to understand why case A isn't efficient, since the code has to iterate over all elements of the DOM tree. Case C and D aren't that bad, but I would say case B should be the preferred one for this goal.

Test 3 - Finding an element by Attribute


The third test is to find elements by a given attribute value. Sometimes this technique is useful and I decided to test it by searching for the element that has "c-3221" as the value of the row attribute. There are four possibilities in this case:

A - Using attribute search
$('[row="c-3221"]').html()

B - Using attribute search + tag
$('p[row="c-3221"]').html()

C - Using tag search + filter
$('p').filter('[row="c-3221"]').html()

D - Using (tag + attribute) search + filter
$('p[@row]').filter('[row="c-3221"]').html()


Running this test for the first time in different browsers, I could get the following results:
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               
FirefoxOperaIE6IE7Safari
A6610139025008011156
B1250360406200250
C1265968485231281
D40781000656320625

Case B is for sure the best approach to find an element by a specific attribute value.

Conclusions


This experiment was an attempt to find the right and fastest way of finding specific elements in the DOM tree using jQuery. Every jQuery developer should know and understand these details in order to create efficient code. Benjamin Sterling gave the first step in such performance analysis, but I could provide another point of view, which uses a big DOM tree and more alternatives to be checked.
Hugo by Hugo @ in Português
Introdução básica à especificação Service Component Architecture, a qual define regras para a criação de software baseado em componentes.

Voltando a falar sobre componentes após um bom tempo trabalhando com interfaces gráficas, farei uma introdução ao SCA – Service Component Architecture – visando criar uma base nesse site com os conceitos fundamentais sobre a área de componentes. Além de preparar o terreno para os artigos mais avançados (meu objetivo e interesse), você ainda ganha de presente aqui um resumo bem legal que o ajudará a compreender esse ramo da engenharia de software.

Se você tem o mínimo de experiência com desenvolvimento de software, você já deve ter percebido que uma aplicação é, na verdade, um conjunto de componentes que cooperam para realizar um determinado objetivo. Mesmo que o seu código seja o pior dos macarrões ou um verdadeiro ninho de ratos (o Code Comics que o diga), ele ainda sim apresenta conceitos de serviços independentes.

Em linhas gerais, não importa se o seu sistema só tem uma ou duas classes e roda na mesma máquina, ou está espalhado por diversos servidores e se comunicam usando diferentes protocolos. A questão por trás é sempre a mesma e o que muda é a granularidade do serviço. Portanto, o conceito de arquitetura de componentes deve ser escalável e atender a diversos tipos de aplicação, e é aí que a SCA entra em cena.

Service Component Architecture (SCA)


A SCA é uma especificação mantida pela OASIS e foi originalmente criada por um grupo de empresas, incluindo BEA, IBM, Oracle, SAP e outros. Dentre as principais contribuições, temos a organização de boa parte dos conceitos trazidos pela engenharia de software baseada em componentes (CBSE). Além disso, uma especificação não-proprietária ajuda muito na redução de monopólios e possíveis corvardias na indústria de software.

A SCA define como criar componentes e como conectá-los para montar aplicações. Os componentes podem ser criados em linguagens diferentes ou até mesmo com tecnologias diferentes (Spring Framework, BPEL, etc.). O que importa mesmo são as fronteiras que esses componentes disponibilizam para cooperarem entre si, algo imprescindível em qualquer arquitetura de componentes.

Componentes e Composições


Toda aplicação SCA é composta por um ou mais componentes. Sob um ponto de vista simples, podemos ver alguns componentes em java rodando em um mesmo processo. Complicando um pouco mais, poderíamos ter componentes distribuídos que se comunicam por uma LAN através de um protocolo qualquer. Em um caso mais extremo, poderíamos ter componentes em java e C++, somados de mais outros em BPEL rodando em máquinas distantes. Independente do caso, precisamos de um jeito de definir componentes e descrever como eles se comunicam.

Para fazer isso, a SCA apresenta uma definição genérica de componente. Ela também define como esses componentes podem ser combinados para criar composições. Uma composição é uma estrutura lógica que pode ser executada em uma mesma máquina ou distribuída pela rede. Além disso, uma aplicação completa pode ser feita com apenas uma composição ou pode ser uma combinação de diversas composições. Em uma composição, os componentes podem ser implementados em linguagens diferentes ou tecnologias diferentes, desde que eles obedeçam às regras preestabelecidas.


Figura 1: Exemplo de composição.

Conforme mostrado na Figura 1, a composição SCA pode ser acessada por software que não está definido dentro dos padrões SCA. Isso pode incluir páginas JSP, uma aplicação desktop ou qualquer outra coisa. Os componentes também podem acessar dados assim como qualquer outra aplicação. Uma forma de fazer isso é utilizar Service Data Objects para trocar dados, os quais são construídos a partir de tecnologias padrão como JDBC ou JPA. Mas você pode fazer os componentes acessarem diretamente o banco de dados ou os arquivos que você quiser. A SCA não força nenhuma implementação específica nesse sentido.

As composições de uma SCA precisam ser definidas em um arquivo chamado Service Component Definition Language (SCDL), o qual termina com a extensão ".composite". O arquivo SCDL – pronunciado como "skiddle" – possui o formato XML e descreve quais componentes a composição possui e como eles estão relacionados. Para o exemplo da Figura 1, teríamos uma configuração SCDL que pareceria com:

<composite name="ComponentHouse">
<component name="component1">
...
</component>

<component name="component2">
...
</component>

<component name="component3">
...
</component>

<component name="component4">
...
</component>

<component name="component5">
...
</component>
</composite>

Componentes e composições são elementos fundamentais de qualquer aplicação SCA. Entretanto, eles precisam estar definidos dentro de um domínio.

Domínios


Domínios são usados para agrupar composições e evitar que elas se misturem com composições de outros fornecedores. Como a SCA é um padrão seguido por diferentes fornecedores, essa idéia de domínio facilita a vida do desenvolvedor por limitar o escopo do software e evitar as complexidades das configurações que envolvem múltiplos fornecedores.


Figura 2: Domínio, composições, máquinas e processos.

O domínio mostrado na Figura 2 possui três composições. A composição vista na parte de cima da imagem é formada por dois computadores e roda em três processos. As outras duas composições (parte inferior da imagem) rodam em uma mesma máquina, dividida também em três processos.

É importante lembrar que composições não podem atravessar as fronteiras do domínio, englobando componentes de outros fornecedores. Não confunda isso com interoperabilidade com outros domínios, o que é perfeitamente normal. Em outras palavras, podemos ter dois domínios que se comunicam, mas cada um possui as suas próprias composições e componentes.

A comunicação entre componentes de um mesmo domínio pode ser implementada da forma que o fornecedor quiser. A SCA não impõe limitações nesse aspecto. Já a comunicação entre domínios (ou com software que não é SCA) precisa ser feita por algum padrão aceito pelo mercado, como web services, etc. A Figura 3 ilustra um exemplo.


Figura 3: Comunicação entre domínios.

Essa foi apenas uma visão geral sobre a especificação Service Component Architecture, a qual está ganhando terreno rapidamente na indústria de software. Em breve voltarei para falar mais sobre essa especificação, incluindo mais detalhes sobre os itens explicados nessa introdução.
Hugo by Hugo @ in English
Despite our best intentions, many of us don't always get to work on well organized and loosely coupled systems. In some cases, we may need to make our way around a code base that is old and has been written by another team whose quality criteria are not clear. Here you can find 10 reasons why I hate working on huge badly-developed legacy systems:

1 - The system is always growing. If a feature must be extended, developers tend to create new methods or classes just to avoid touching the existing code, which could impact on other (unknown) functionalities.

2 - It is almost impossible to create a new functionality using pure test-driven development. To successfully create code using such technique you must understand exactly what the code must do. If you only create tests for your new implementations (e.g., you create the test of a new method and then create the new method), you will succeed to some extent. But a good practice in TDD is to create tests that check the states of the system, and this is very difficult to achieve when you work on a system that is bad modularized and tightly coupled.

3 - Third-party components might not be supported anymore. When you try to upgrade the system (e.g., from java 1.4 to version 1.5 or a new Look-and-Feel is available) you will probably find out that some third-party components will start to behave strangely (e.g., bad layout, missing funcionality, etc). This gets even worse when you don't have the source code and the vendor is not supporting the component anymore.

4 - Unpredictability: when you make a change in the system, you have no clues if that change will affect other parts of the code. This is likely to happen with systems that use, for example, instrospection. To better illustrate this, imagine that you need to rename a method that is invoked through reflection by another part of the system. The time that you will spend to track down the bug caused by this change can take hours or even days.

5 - Long list of frameworks, techniques and approaches used in the development. You have to understand all of them to be able to work with the code. This reminds me of "Jack of all trades is a master of none". While keeping track of trends and technologies is something doable and recommended by experts, keeping track of their details requires time and dedication that we don't normally have.

6 - Too much time to understand the system as a whole. After several months working on the system, you are still a child when it comes to code knowledge. Since the productivity of the developers is a direct result of how much code they understand, they will probably be frustated to a certain extent.

7 - It is always difficult to use CASE tools focused on quality and/or productivity. How can you build class or sequence diagrams for your application if the code is an unpredictable mess? Even if you have good intentions and try to refactor the application, chances are that the spaghetti code will prevent you from reaching an acceptable state.

8 - The build time can be too long. There are systems that take more than 30 minutes to compile, run automated tests, deploy and startup. This is really bad to the productivity and leads to context switching, which is an evil in software development. The developer gets distracted because it is almost impossible to keep looking at the build process waiting for it to end.

9 - It is almost impossible to replace one technology concept by another. To better illustrate this, imagine that your monster application doesn't have a well-defined persistency layer (which is common in huge complex legacy systems) and you want to replace your object-oriented database by a relational database. How many places do you have to change to make things happen? How will you make sure that the change was successful without a test harness (automation)?

10 - The last item is a result of the nine reasons above: The bad productivity forces the developers to work more and they will get stressed and tired. Their motivation will suffer and they will probably start to look for another job unless the company has incredible ideas and benefits to overcome these problems.

I know that there are hundreds of exceptions in the real world regarding the ideas above, but my intention is to have a list with the worst cases. What do you think?
Hugo by Hugo @ in English
Learn how to combine JGoodies with other backend frameworks in your desktop application. The main problem is the need to create objects that extend the Model class while other frameworks might consider this a problem, either because they require POJOs or provide other specific rules.

If you create GUIs using the JGoodies Binding library, you will probably have to create bean classes that extend the com.jgoodies.binding.beans.Model class.

If your desktop application also uses a framework for other purposes (e.g., persistency) and you plan to use the same model object from the GUI with this framework, then you will have to make sure you don't have conflicting requirements.

This problem is reasonably common and happens because java doesn't allow multiple inheritance. So, any framework that is used in conjunction with JGoodies and has rules for the target object (e.g., it must be a POJO), then the implementation starts to become more complex.

Let's discuss one possible solution for those cases where the other framework requires the object to be a POJO (e.g., Hibernate, JPA, etc.). In such cases, we can create one class for the POJO (attributes + getters + setters) and another class that wraps this POJO, which has similar methods but has the advantage to execute other actions.

Example of POJO:

public class Student {
    private String name;
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
}

The POJO above can be used by the persistency framework without problems. Now we need a class to be used by the Binding library (GUI):

public class StudentModel extends Model {
    private Student student;

    public StudentModel(Student student) { this.student = student; }

    public String getName() { return student.getName(); }

    public void setName(String name) {
        String old = student.getName();
        student.setName(name);
        this.firePropertyChange("name", old, name);
    }
}

This isn't a perfect solution, but solves the problem. One disadvantage is the maintenance required by the two sets of methods that access the POJO, which could be automated by a small piece of code that uses java reflection.
Hugo by Hugo @ in English
This article explains the advantages of the Presentation Model pattern over the Model-View-Controller and Model-View-Presenter. This will improve your decisions about GUI implementations for desktop.

One of the major challenges in the development of desktop software is the effective use of unit tests that cover the GUI functionalities and its interactions with the remainder of the software. The complexity of this implementation lies in the control of selected items in lists and tables, modal dialogs, clicks and events. In fact, it is extremely difficult to develop good tests on the GUI when the application logic is tightly-coupled to UI components.

You probably have already heard about design patterns that could help in this case, especially those that separate the application logic from UI components. Perhaps the most famous is the Model-View-Controller (MVC), which has been widely used not only for desktop applications but also for web development.

There is a relevant question that we should ask ourselves at this point: Is this separation between logic and UI components enough to reduce the complexity of writing GUI unit tests?

Figure 1 presents the three most important presentation patterns for desktop development. Besides the MVC, there is one called Model-View-Presenter (MVP) that consists of a small variation of the first one (see Martin Fowler's description of them for more details).



Figure 1: Patterns for desktop application development.


The important thing to notice in this picture is that both MVC and MVP describe the controller/presenter with a reference to the view. So, to create an instance of the controller inside the test code, we need the view as well. This still makes the development of unit tests difficult.

There is a turnaround to this problem, which is basically to add an interface between the controller and the view to break this dependency and abstract the view’s components. But the idea behind this solution increases the amount of code and does not imply in less complexity and clean organization. In most of the cases, this resolution is not worth the effort when there is a third option such as the Presentation Model pattern.
123
New Post
feeds Feeds
Hugo liuhuan panpan2523 diemei
TineValen Willder Pillser osei
summeryang000 markbrown23 robertflick dsfds