Yazılım Ürün Hattı

Yazılım ürün hattı, tanımlama yoluyla ortak öz varlıklar kullanılarak geliştirilen, belirli bir pazar kesiminin ya da görevin intiyaçlarına yönelik, yönetim altındaki ortak yetenek kümelerini kullanan yazılım-yoğun sistemler kümesine verilen isimdir [1].

YÜH yaklaşımının ortaya çıkmasına yol açan en önemli güdülerden biri de geçmiş yeniden kullanım yaklaşımlarından (Ör: Nesne yönelimli yaklaşım) çıkarılan derslerdir. Bu bağlamda genel kabul gören iki husus aşağıdaki gibi sıralanabilir [2]:

• Fırsatçı yeniden kullanım’ın (Opportunistic reuse), uygulamada etkin olmadığı görülmüştür. Yeniden kullanım planlı ve zorunlu olarak yönetilmelidir.
• Aşağıdan yukarıya (bottom-up) yeniden kullanım ile yeni sistemlerin soyut bileşenlerin bir araya getirilmesinden oluşturulması, başarılı sonuçlar vermemektedir. Başarılı yeniden kullanım yukarıdan aşağıya (top-down) yaklaşım gerektirmektedir (Bu tanımlama kısmen aşağıdan yukarı yaklaşım kullanımını dışlamaz).

Bu yeni yazılım geliştirme yaklaşımına geçişin nasıl ele alınacağı da diğer bir önemli konu olarak karşımıza çıkmaktadır. C. Krueger, kuruma faydası ne kadar yüksek olursa olsun, geçiş aşamasında yaşanacak üretim düşmesini ya da durmasını bazı kurumların göze alamadığını belirtmiştir [3].

Geçiş maliyetini en aza indirmek üzere tanımlanmış üç farklı uyum modeli bulunmaktadır [3]:

• Öngörüsel Yaklaşım (Proactive approach): Geleneksel yöntemdeki şelale (waterfall) benzeri bir yaklaşımdır. Tüm ürün çeşitleri çözümlenir, tasarlanır ve gerçekleştirilir. Köklü ve tümden bir değişimi daha hızlı getirdiğinden bu yaklaşıma büyük patlama (big bang) yaklaşımı da denilir.
• Tepkisel Yaklaşım (Reactive approach): Döngüsel ya da çevik yöntemlere benzer bir yaklaşımdır. Her bir döngüde bir ya da birkaç ürün çeşidi ele alınır.
• Çıkarımsal Yaklaşım (Extractive approach): Var olan bir ya da bir kaç ürün YÜH için temel alınır ve diğer ürünler sonrasında dahil edilir.

Kurumların olgunluk seviyeleri, ürün ailelerinin çeşitliliği gibi bir çok etken var olmakla birlikte, tüm gereksinimlerin önceden çok açık belirlenemediği durumlar için en uygun geçiş modelinin “tepkisel yaklaşım” olduğu söylenebilir.

YÜH bağlamında iki temel sürecin birbiri ile etkileşimi söz konusudur [4]:

• Alan Mühendisliği: Ürünlerin ortaklık ve farklılıklarının belirlenip tanımlandığı YÜH mühendisliği sürecidir. Tanımlanan ortaklık ve farklılıklar, üretim bandının temelini oluşturur.
• Uygulama Mühendisliği: YÜH’nın alan değerleri (domain artefacts) ve farklılık tanımlarından yararlanarak ürünlerin oluşturulduğu YÜH mühendisliği sürecidir.

Bu iki süreç belirli döngülerle birbirlerini besler ve geliştirir. Aşağıdaki şekil söz konusu döngüleri ve süreç adımlarını göstermektedir.

YÜH tasarımı hakkında daha fazla detay bu yazı kapsamı dışındadır. Başlangıç aşaması için, M. Matinlassi’nin farklı YÜH tasarım yöntemlerini (KobrA, FAST, FORM, …) karşılaştırmalı olarak incelediği belge’ye [5] başvurulabilir.

 

[1] P. Clements, L. Northrop, (2001), “Software Product Lines: Practices and Patterns”, Addison Wesley.

[2] Jan Bosch, (2000), “Design and Use of Software Architectures”, Addison-Wesley, ACM Press Books.

[3] C. Krueger, (2002), “Eliminating the adoption barrier”, IEEE Software, Volume 19, Issue 4.

[4] K. Pohl, G. Böckle, F. van der Linden, (2005), “Software Product Line Engineering”, Springer.

[5] M. Matinlassi, (2004), “Comparison of Software Product Line Architecture Design Methods: COPA, FAST, FORM, KobrA and QADA”.

UYMK 2008

Bu sene ikincisi düzenlenecek olan Ulusal Yazılım Mimarisi Konferansı (UYMK),  11-12 Eylül 2008 tarihlerinde İzmir'de gerçekleştirilecek. UYMK, iki senede bir düzenleniyor ve ilk konferans 2006 yılında İstanbul'da Yıldız Teknik Üniversitesi ev sahipliğinde gerçekleştirilmişti. Bu seneki ev sahibi ise Ege Üniversitesi.

Konu başlıklarını içeren bildiri çağrısına buradan erişebilirsiniz. Özetlerin gönderimi için son tarih 7 Nisan 2008.

How to make HTTP connection in J2ME

One of the most critical aspects of J2ME is network connectivity. Although J2ME devices can be useful when they are not connected to a network, the ability to make a network connection provides a means to tap into the powerful resources available on a network. In other words, a client-server paradigm is used to offload complicated work from the limited capabilities of the MIDP device to the more capable server environment.

Since network connectivity is so vital to J2ME it is important that the architecture be extendible to many different protocols while allowing applications to be portable across many devices. (MIDP 1.0 specification supports only HTTP connection) The piece of software within the J2ME architecture that addresses network connectivity is called the Generic Connection Framework (GCF). The Generic Connection Framework resides in the javax.microedition.io

• DatagramConnection : Manages a datagram connection.
• InputConnection : Manages an input stream-based connection.
• OutputConnection : Manages an output stream-based connection.
• StreamConnection : Manages the capabilities of a stream. Combines the methods of both InputConnection and OutputConnection.
• ContentConnection :Manages connection for passing content, such as HTML or XML. Provides basic methods for inspecting the content length, encoding and type of content.

Let’s talk about more specific sample, below code snippet demonstrates simple HTTP connection. First crucial point in snippet, connection type casting. How the Connector knows the right connection class? Answer is very forthright; when the URI is defined in open, Connector parses it (schema, address and parameters) and decides the class. For instance “http” token refers to HttpConnection class.

   1: String url = new String("http://sample.cs.hacettepe.edu.tr:1234/pusu/pusunotifier");

   2: try {

   3:     con = (HttpConnection) Connector.open(url);

   4:     con.setRequestMethod(HttpConnection.POST);

   5:     out = con.openOutputStream();

   6:     out.write(stringData.getBytes());

   7: } catch (IOException exp) {

   8:     // Handle IOException

   9: }

  10: // Final snippet 

Building HTTP header is another vital aspect of the connection. For MIDlet-to-Servlet connections, that’s quite simple, all you needed defining HttpConnection.POST in seRequestMethod. What about MIDlet-to-PHP interaction? That’s offtopic for this tutorial but I can briefly say that you have to build HTTP header manually. This method covers setting Boundary, Content-Disposition, Content-Type, etc… (That's valid for hybrid transmission. Only string based data transmission can be handled without manual building).

For client side final point is closing connection resources to avoid lack:

   1: // Connection snippet

   2: finally {

   3:     try {

   4:         if (out != null) {

   5:             out.close();

   6:         }

   7:         if (con != null) {

   8:             con.close();

   9:         }

  10:     } catch (IOException exp) {

  11:         // Handle IOException

  12:     }

  13: }

That’s all for the client side application. Let’s review implemented part of the application; client constructs sending data, requests HTTP connection and transmits concerning data. Server side requirements; establishing HTTP connection, receiving transmitted data and process it.

   1: public class PusuNotifier extends HttpServlet {

   2:     public void doPost(HttpServletRequest request, HttpServletResponse response) {

   3:         InputStream input = request.getInputStream();

   4:         BufferedReader bufReader = new BufferedReader(new InputStreamReader(input));

   5:         StringBuffer stringBuf = new StringBuffer();

   6:         String line;

   7:         while ((line = bufReader.readLine())!=null) {

   8:             stringBuf.append(line);

   9:         }

  10:         String receivedData = stringBuf.toString();

  11:         // Process received data

  12:     }

  13: }

Establishing connection is provided by container (server) application for Servlets so this requirement has been skipped. Standart HttpServlet specification defines doPost method in order to handle post requests and HttpServletRequest argument to encapsulate client’s request.

Receiving data via BufferedReader is a generic way to handle transmission. (Although it’s suitable way for hybrid transmission, not the only way). Finally, received data is server side and ready to be processed.

Originally posted by Orçun Dayıbaş in 2005.04.25 - The Pusu Project Blog