<query kit=pl src=local.pl cmd=X:email_address(X)>
  <param format=" \%s">
  <param result="">
  <param display="<h4>The query</h4>">
  <param header="<h4>The adresses</h4> <ul>">
  <param footer="</ul>">
  email_address(E) :-
  	person(X),
  	property(X,name:N),
  	property(X,familyname:F),
  	email(X,E),
  	cout(['
', N,' ',F,' has email adress ']),
  	cout([ '<a href=mailto:', E, '>', E, '</a>',nl]).
  </query>
  

The query tag is an element of one of the text processing filters to provide hypermedia support for software engineering described in  [HypermediaSE]. Processing the fragment above results in an HTML list of names and email addresses. The collection of filters itself is written in lex, yacc and C++. To process the query, an embedded logic programming interpreter is invoked. To merge the output from the query, a handler is installed for the cout command.

The query example was motivated by the need to maintain Web pages for the administration of a colloquium within our group. The actual knowledge base consists of a list of people and some rules to determine their affiliations and email addresses. The knowledge base is made available by consulting the file local.pl.

As concerns the implementation, the Java fragment below indicates how to access the logic programming interpreter from a (Java) program.

  query pl = new query("kit=pl src=remote.pl"); 
   logic.java  
  pl.eval("X:assistant(X)");
  String res = null;
  while ( (res = pl.result()) != null ) {
              System.out.println("
 " + res);
              }
  

  
   remote.pl  
  :- source('www.cs.vu.nl/~eliens/db/se/people.pl').
  :- source('www.cs.vu.nl/~eliens/db/se/institute.pl').
  :- source('www.cs.vu.nl/~eliens/db/se/property.pl').
  :- source('www.cs.vu.nl/~eliens/db/se/query.pl').
  

However, processing the information accessed by url is still done locally. So, the next step that may be suggested is to distribute the knowledge processing itself, for example by using CORBA.

  interface query { 
   query.idl  
  
          void source(in string file);
          long eval(in string cmd);
          string result(in long id);
  
          oneway void halt();
          };
  

• representation -- object(Handler,Class,ID,REF,Ancestors)
• object definition -- class_method(This,...)
• object invocation -- self(This):method(...)
• state variables representation -- value(ID,Key,Value)
• state variable access -- var(Key) = Value, Var = value(key)
• native binding - native(Handler,Method,Result)

requirements

• low overhead, especially when not needed
• natural syntax for object clause definitions
• support for native objects

Objects (or classes of objects, if you prefer) are defined by a collection of clauses with a head predicate of the form class_method(This,...), specifying the class, method and object identity parameter. The actual invocation of the method takes the form self(This):method(...), where the colon acts as the familiar dot object access parameter. Note that the identity parameter (This) does not occur among the method parameters, but is instead contained in the object specifier. Instead of the keyword self, we may also use a class name to enforce a cast to specific object type when invoking the method. In the actual object extension, we also support object state instance variables, which are however not relevant for our discussion here.

Object methods may be defined as native by including a goal of the form native(Handler, Method, Result), where Handler specifies the (native) handler to be invoked, Method the actual request, and Result a variable to store the possible outcome of the request. When the Handler parameter is left unspecified, the handler defined for the object will be taken to effect the native call.

Let's look at some examples first, to augment this admittedly concise description.

  
          midi(This):midi,  // create midi object
          Self = self(This),
          Self:open('a.mid'),
          Self:header(0,1,480),
          Self:track(start),
          Self:melody([48,50,51,53,55]), // c d es f g, minor indeed
          Self:track(end), // end track
  

  
   midi  
  :- use(library(midi:[midi,lily,music,process])).
  :- declare(midi:object,class(midi),[handler]). 
  
  midi_midi(This) :- // constructor
          midi(This):handler(H),   // gets Handler from class
          declare(H,new(midi(This)),[],[],_).
  
  

  
 native methods
  midi_read(This,F) :- native(_,This,read(F),_). 
  midi_analyse(This,I,O) :- native(_,This,analyse(I,O),_).
  midi_open(This,F) :- native(_,This,open(F),_).
  midi_header(This,M) :- native(_,This,header(M,0,480),_).
  midi_track(This,X) :- native(_,This,track(X),_).
  midi_tempo(This,X) :- native(_,This,tempo(X),_).
  midi_event(This,D,C,M,T,V) :-
  		      native(_,This,event(D,C,M,T,V),_).
  

  midi_note(This,D,C,T,V) :- 
          Self = midi(This), // cast to midi
          Self:event(D,C,note_on,T,V),
          Self:event(D,C,note_off,T,V).
  
  midi_melody(This,L) :- self(This):melody(480,1,L,64).
  
  midi_melody(_This,_,_,[],_).
  
  midi_melody(This,D,C,[X|R],V) :-
          Self = self(This),
          Self:note(D,C,X,V),  
          midi_melody(This,D,C,R,V).   // direct invocation
  

As outlined in section Reactor, in the hush framework we use an event-based mechanism to effect foreign language bindings. This means that the information concerning the native call is stored in an event object that is passed to a handler, which invokes the operator function on the occurrence of an event. In the code fragment below it is shown how native method dispatching is taken care of in the operator function of a C++ kit_object, for which a corresponding object in Prolog is assumed to exist.

  int kit_object::operator()() {
          event* e = _event;
  
          vm<kit> self(e);  // smart pointer
          string method = e->_method();
  
          if (method == "kit") { // constructor
                  kit* q = new kit(e->arg(1));
                  _register(q);
                  result( reference((void*)q) );
          } else if (method == "eval") {
                  long res = self->eval(e->arg(1));
                  result( itoa(res) );
          } else if (method == "result") {
                  char* res = self->result( atoi(e->arg(1)) );
                  result(res);
          } else { // dispatch up in the hierarchy
                  return handler_object::operator()();
          }
  
          return 0;
          }
  

  template <class T>
  class vm  { 
   smart pointer class  
  public:
  
  vm(event* e) {
          int p = 0;
          char* id = e->option("ref");
          if (id) {
  		p = atoi(id);
  		}
          _self = (T*) p;
          }
  
  
  virtual inline T* operator->() { return _self; }
  
  private:
  T* _self;
  };
  

In summary, the constructor converts the event argument to a reference to the parameterized object type T, which is used as the result of the dereference operator. This allows for invoking methods for object type T without further ado. As a comment, our presentation here is somewhat simplified, since we do not take into account the possibility of upcalls, that is the invocation of Prolog code from C++. We will deal with these additional details when discussing the Java/C++ binding in the next (sub)section.

Combining Java and C++

The designers of the Java language have created an elegant facility for incorporating native C/C++ code in Java applications, the Java Native Interface (JNI). Elegant, since native methods can be mixed freely with ordinary methods. When qualifying methods as native, the implementer must provide a dynamically loadable library that contains functions, of which the names and signatures must comply with the JNI standard, defining the functionality of the methods. Nevertheless, the JNI does not provide for generic means to establish a direct correspondence between an object class hierarchy in C++ that (partially) implements a corresponding object class hierarchy in Java. In this section, we will study how such a correspondence is realized in the hush framework, using the Java Native Interface.

The solution to establishing corresponding object class hierarchies in Java and C++ that we have adopted relies on storing a reference to the native C++ object in the Java object and the conversion of this reference to a smart pointer encapsulating access to the native C++ object. Upcalls, which occur for example when Java handlers are invoked in response to an event, require some additional machinery, as will be explained shortly.

Each Java class in hush is derived from the obscure class, which contains an instance variable _self that may store a C++ object reference, encoded as an integer.

  package hush.dv.api;
  
  class obscure { 
   obscure  
  public int _self; // peer object pointer
  ...
  };
  

The class obscure has been introduced so as not to pollute the handler class, which is the base class for almost every hush class. The (Java) handler class is derived from obscure.

As an example, look at the (partial) Java class description for kit below.

  package hush.dv.api;
  
  public class kit extends handler { 
   kit  
  
  public kit() { _self = init(); }
  protected kit(int x) { }
  private native int init();
  
  public native void source(String cmd);
  
  public native void eval(String cmd);
  
  public String result() { 
  	String _result = getresult();
  	if (_result.equals("-")) return null;
  	else return _result;
  	}
  
  private native String getresult();
  
  public native void bind(String cmd, handler h);
  
  ...
  };
  

Recall that the kit class is used to encapsulate an embedded interpreter, such as a Tcl or Prolog interpreter. When a kit is constructed, the instance variable _self is initialized with the reference obtained from the native init method, which will be given below. The other methods of kit are either native or result in invoking a native method, possibly with some additional processing.

Each native method must be implemented as a function, of which the name and signature are fixed by the JNI conventions, as illustrated below.

  
   kit.c  
  include @lt;hush/hush.h>
  include @lt;hush/java.h>
  include @lt;native/hush_dv_api_kit.h>
  
  #define method(X) Java_hush_dv_api_kit_##X
  JNIEXPORT jint JNICALL method(init)(JNIEnv *env, jobject obj)
  {
    jint result = (jint) kit::_default; // (jint) new kit();
    if (!result) {
  	kit* x = new kit("tk");
  	session::_default->_register(x);
  	result = (jint) x;
  	}
    return result;
  }
  

The init method, the full name of which is obtained by expanding the macro call method(init), results in an integer-encoded reference to a kit object, which is newly created if it doesn't already exist.

  JNIEXPORT jstring JNICALL method(getresult)(JNIEnv *env, jobject obj)
  {
    java_vm vm(env,obj);
    char *s = vm->result();
    if (s) return vm.string(s);
    else return vm.string("-");
  }
  

In the getresult method, we see how a smart pointer, instantiated for the kit class, is used to obtain the result from the C++ kit object. The smart pointer takes care of converting the reference stored in the Java object to an appropriate pointer.

  JNIEXPORT void JNICALL method(bind)(JNIEnv *env, jobject obj,
  	       jstring s, jobject o)
  {
    java_vm vm(env,obj);
    java_vm* vmp = new java_vm(env,o,"Handler");
    const char *str = vm.get(s);
    handler* h = new handler();
    session::_default->_register(h);
    h->_vmp = vmp;
    h->_register(vmp);
    vm->bind(str,h);
    vm.release(s, str);
  }
  

In the bind method, which is used to bind a (Java) handler object to some (Tcl or Prolog) command, a new C++ handler is created. This handler is modified to contain a reference to the smart pointer, which (indeed) also gives access to the Java handler object. Notice that calling the Java handler object is an upcall, when viewed from the native implementation.

In somewhat more detail, the Java handler object is invoked through the C++ handler object created in the bind method of the kit. The C++ handler is activated when an event occurs, or a Tcl or Prolog command is given. Activating the handler amounts to calling the dispatch method with an appropriate event. To decide whether the activation must be passed through to the Java handler object, the handler::dispatch method checks for the availability of a smart pointer, as illustrated below.

handler::dispatch

  
  event* handler::dispatch(event* e) {
  _event = e;
  if (_vmp) {
          return ((vm*)_vmp)->dispatch(e);
  } else {
  
           int result = this->operator()();
  
           if (result != OK) return 0; 
           else return _event;
           }
  }
  

When the C++ handler contains a smart pointer, the dispatch method is called for that pointer.

The Java smart pointer template class for the Java/C++ binding is derived from the smart pointer template class introduced in the previous (sub)section.

  #include <hush/vm.h> 
  #include <jni.h>
  
  template< class T >
  class java_vm : public vm< T > { 
   java_vm  
  public:
  
  java_vm(JNIEnv* env_, jobject obj_) {
  	_env = env_;
  	_obj = obj_;
  	_self = self();
  	}
  
  ...
  
  
  event* dispatch(event* e) { 
 java dispatch
  	call("dispatch",(int)e);
  	return e;
  	}
  
  
  T* operator->() { return _self; }
  
  T* self() {
  	jfieldID fid = fieldID("_self","I");
  	return (T*) _env->GetIntField( _obj, fid);
  	}
  
  
  void call(const char* md, int i) { // void (*)(int)
  	jmethodID mid = methodID(md,"(I)V");
  	_env->CallVoidMethod(_obj, mid, i);
  	}
  
  private: 
  JNIEnv* _env;
  jobject _obj;
  T* _self;
  };
  

Notice how the value of the _self reference field is obtained from the _self attribute of the Java object. Also notice that calling dispatch for the Java handler is mediated by an additional call function, which obtains an explicit reference to the method that must be invoked. In general, there are many possible method signatures for which such a call function could be supplied, but in our case we only need one, to invoke dispatch.

Discussion

Interfacing Java and C++ is at first sight not very difficult, especially not when the majority of calls consists of downcalls (from Java to C++) only. The smart pointer device may then be used as a handy abbreviation. The problems occur, however, when upcalls come into play. Due to the simple design of hush, upcalls occur (almost) exclusively through the dispatch method. This is not the result of explicit design, but in retrospect just sheer luck. When upcalls are spread over the code and may vary in signature, they will most likely bring along significant software engineering and maintenance effort.

object-oriented programming

[] readme course preface 1 2 3 4 5 6 7 8 9 10 11 12 appendix lectures resources

Architectural patterns and styles

subsections:

• From technology to style
• Case study -- perspectives in visualization

When constructing a system, how does one determine an appropriate style? There is no simple answer to this question. According to  [Practice], several forces play a role, for example quality requirements concerning availability and performance and technological constraints that have to do with the platform on which the system is intended to run. Also, as frankly admitted in  [Practice], personal experiences and preferences of the architect play a role.

Architectural choices lead to a particular decomposition into components and a characterization of the relation between components. Classifying groups of software architectures, we may speak of architectural styles, which may be defined, following  [Shaw96], as descriptions of component types and patterns of runtime control and data transfer.

In this section we will look at architectural styles for distributed object systems. Three styles will be introduced, and we will discuss how these styles are related to technological constraints imposed by particular component technologies. Then we will investigate how these styles work out in practice, by a simple case study in which we explore the consequences of a particular style for the solution of a specific problem, in our case the problem of dynamically changing a viewpoint or perspective in an interactive visualization system.

From technology to style

We distinguish between three different architectural styles:

• the distributed objects style
• the (dynamically) downloadable code style
• the mobile objects style

This distinction is arbitrary, in the sense that other distinctions are conceivable. However, the distinction above is well motivated by the technology matrix introduced in section Technology, as reflected in the feature-based description given below.

The distributed objects style comprises software architectures which consist of software components providing services to client applications. Each object is located at a single, fixed place. Objects on different machines are connected by an ORB (Object Request Broker). Example technologies supporting this architectural style are CORBA and DCOM.

The second architectural style is the (dynamically) downloadable code style. Classes may be downloaded, to be used on client machines for instantiating objects, which will run on the client machine. Example technologies supporting this style are Java applets, JavaBeans, and ActiveX controls.

Finally, in the mobile objects style, objects may migrate from host to host, carrying both functionality and data when they move. Consequently, mobile objects may communicate with the local objects of the host they currently reside on. Mobile objects are a means to implement agents which wander through a network, collecting information, negotiating with other agents, periodically reporting back results to the user who launched the agents. Technologies supporting the mobile object style are agent ORBs such as Voyager.

Features

In slide Features, an overview is given of the characteristic features of each style. Clearly, the styles differ in what are considered as constituent parts (components and connectors), location issues (which determine where objects are created and where they are located during their lifetime), and functionality issues (that is whether either the client or server is functionally extensible).

We may regard the location issues as the prime discriminators of the architectural styles discussed. Adopting the distributed objects architectural style, new objects can be added at the server-side, where they will stay for the remainder of their lifetime. In contrast, adopting the downloadable code style, objects may be created at the client-side, from classes obtained from the server. Most flexible is the mobile objects style, which allows for objects to reside on either server or client machines.

The location properties directly affect the way that the system is extensible with new functionality. Clearly, the mobile code style offers the maximum of flexibility and functional extensibility. Nevertheless, as we will discuss shortly, there are tradeoffs involved. The maximum in flexibility and extensibility does not necessarily offer the optimal solution!

Case study -- perspectives in visualization

To determine which architectural style to use, or which mix of styles, is to a large extent determined by practical experience. Nevertheless, at the end of this section, we will discuss some rules of thumb that may guide you in the choice of a particular style. However, first we will look at an example that illustrates the consequences of the choice of a particular style. The example comes from the distributed visualization architecture (DIVA) that is explained in more detail in section DIVA. DIVA is being developed in cooperation with ASZ/GAK, the largest social security provider in the Netherlands, for experimenting with business visualization to support decision making. Our case study focuses on how to support the sharing of perspectives in visualizing shared information. For example, one of the users discovers a new way to display information, uncovering aspects that would otherwise remain hidden. This new perspective must then be shared with other users to coerce them, so to speak, to this new point of view. What we will look at, here, is how the choice of a particular style affects the solution for the sharing of perspectives problem.

---

---

slide: Exchanging perspectives

---

Distributed objects style

New functionality can be added by creating a new object at the server. In this case, slide Perspectives(a), the user discovering a new perspective acts as the server. Then, assuming that the discovery of a new perspective is somehow announced to the other users, a user can connect to the server and request for that particular perspective (1). Then, a new visualization object is created (2), which is made accessible to the user requesting for the new perspective (3).

Downloadable code style

When a new visualization perspective is discovered, a class is created that can be downloaded by the interested user, slide Perspectives(b). The user connects to the server that contains the new visualization class (1), downloads the class, and instantiates a new visualization object (2). Finally, the information is retrieved from the shared information server and accordingly visualized (3).

Mobile objects style

Similar as in the downloadable code style, the new visualization perspective is downloaded from a server to the client, slide Perspectives(c). However, in this case, when a user requests for a new perspective (1), it is not a class, but an object, actually a clone of the object residing at the server, that is transferred to the client's machine (2). The clone, which contains all relevant information, does not have to contact the shared information server to update the user's visualization with a fresh viewpoint.

Guidelines for selecting a style

In the DIVA system, we have experimented with all these styles. In our system, we eventually made a choice of the mobile object style for sharing perspectives, since it turned out to provide the most flexible solution. It was also the most natural solution to create display agents for managing perspectives. See section DIVA.

Nevertheless, for other parts of the system we were forced to choose a different solution. For example, since we use a C++ simulation library for obtaining the information, we had to use distributed objects (read CORBA) for making the information available. And for developing control applets, agent technology seemed to be a bit of an overkill so we restricted ourselves to plain Java technology, that is the downloadable code style.

Generalizing, from our experience we can formulate the following rules of thumb, listed in slide Guidelines.

---

Rules of thumb -- selecting an architectural style

• Dedicated hardware or legacy code

distributed objects



• Strategic or secret code

distributed objects



• Many users

downloadable code



• Periodic updates

downloadable code



• Communication and negotiation

mobile objects

---

slide: Rules of thumb

---

Because interoperability is a key feature of distributed objects, the distributed objects style is particularly recommended for wrapping dedicated hardware or legacy software systems. Additionally, distributed objects only expose the interface and do not give away the implementation. This may be necessary for strategic or security reasons.

When a large amount of clients is running an application on a server, the server can easily become overloaded. In this case, moving the processing to the client, by deploying dynamically downloadable classes, is a natural solution. Additionally, when (parts of) an application are updated often, for example because of changing legislation, architectures based on downloadable code are much easier to keep up-to-date. Clients are then automatically using the latest version of the available software.

The latter guidelines hold for the mobile objects style as well. However, agent technology is much more complex. And there is, generally, an efficiency price to pay. So, it is reasonable to introduce agent technology only when real benefits can be expected from the migration of objects, for example when the communication and negotiation with local objects is substantial.

Concluding, we may state that the adoption of a style will often be dictated by the technological constraints a system must satisfy. Nevertheless, a word of warning is in place here. Choosing a style may well have consequences for the overall complexity of the system. Minimalism is to be strived for, in this respect. For example, adopting the mobile object style, that is the use of agents, may significantly complicate the semantics of the system, and consequently induce an increased verification and validation effort.

object-oriented programming

[] readme course preface 1 2 3 4 5 6 7 8 9 10 11 12 appendix lectures resources

Cross-platform development

Platform dependencies form an important category of architectural constraints. In particular, the opportunities offered by one platform may prohibit the deployment of software on other platforms. Nowadays, there are a number of (flavors of) competing platforms, as there are the Unix flavors (of which Linux is becoming a strong contender) and the Windows family, including 3.1 (almost extinct), Windows 95, NT, 98 and (in beta release) Windows 2000. Unix (for example Sun Solaris and SGI IRIX) has by tradition a strong position in the server market. However, Windows NT is growing rapidly in importance. The Windows family, clearly, dominates the (client) desktop market.

---

Cross-platform development

Unix vs NT

• open toolkits and standards -- OMG CORBA

Research/GNU

• AT&T U/WIN -- Posix for 95/NT
• Cygnus -- GNU-win32

Commercial

• NuTCracker/MKS -- porting Unix applications to Windows
• Wind/U, Mainwin -- porting Windows applications to Unix
• Tributary -- developing Unix applications from Windows IDE

---

slide: Cross-platform development

---

Nevertheless, the need to support a variety of platforms will exist at least for some time, and consequently questions with regard to portability and cross-platform development may be important architectural issues.

Considering the opportunities for platform-independent or cross-platform development, we may distinguish between three approaches:

• deploying platform-independent toolkits
• porting applications from Unix to Windows
• porting applications from Windows to Unix

As we have discussed previously, many of the open standards, such as OMG CORBA, and proprietary standards such as Sun Java, aim at platform independence. Also, there are numerous GUI toolkits available that offer platform-independent support. A possible disadvantage of this approach is that the platform specific technology can usually not be profited from.

When it comes to porting applications from Unix to Windows 95/98/NT, we may look at AT&T U/WIN, which provides a POSIX extension for Win32, or Cygnus GNU-win32 support, which offers many of the GNU utilities and libraries for the Windows platform. Similar functionality, as well as support for Motif/X11 GUI capabilities, is offered by the (commercial) NuTCracker environment. (A detailed discussion of the technical merits of the various offerings is beyond the scope of this book. However, the interested reader may find more information in the online version of this book.)

The Windows platform is not only popular with end-users but also with many developers, who enjoy using the Microsoft Visual Studio suite of tools and (object-oriented) frameworks such as MFC. Recently, toolkits have entered the market that allow for porting Microsoft technologies (including Visual Basic, ActiveX and MFC applications) to the Unix platform, in particular Wind/U from bristol.com and Mainwin from mainsoft.com. As a word of warning, these toolkits are still terribly expensive. Yet for more information, consult the online version of this book.

For those who wish to develop directly on the Unix platform, but using Microsoft Visual Studio, there is Tributary, from bristol.com, which offers a Unix-server and client-extensions to Visual Studio.

Discussion

From an architectural perspective, it should not matter what platform is used for the actual development, nor for what target platform the software is being developed. In practice, however, given the preferences of the developers, the particularities of the platforms, and the instability of the (beta) software running on these platforms, the actual choice may make a big difference. As an admittedly weak advice, tune your strategy to your needs and experience! (And your budget.)

object-oriented programming

[] readme course preface 1 2 3 4 5 6 7 8 9 10 11 12 appendix lectures resources

Summary

object-oriented programming

[] readme course preface 1 2 3 4 5 6 7 8 9 10 11 12 appendix lectures resources

This chapter explored the notion of software architecture, and in particular how both problem-related issues and technological constraints determine the adoption of a particular architectural style.

---

Elements of architecture

1

• processing elements -- transformation on data
• data elements -- contain information
• connections -- glue that holds elements together

---

slide: Section 7.1: Elements of architecture

---

In section 1, we looked at a number of definitions of the notion of software architecture, including the definition given in  [Practice]. We also looked at the technological infrastructure underlying client/server architectures and discussed some selected distributed object patterns.

---

Case study -- multimedia feature detection

2

• feature grammar -- structure
• embedded logic -- rules for recognition
• architecture -- multimedia information system

---

slide: Section 7.2: Case study -- multimedia feature detection

---

In section 2, we looked at an experimental musical feature detector, as an example architecture, that uses both a grammar to describe the structural properties of the media items involved, and (embedded) logic to express the rules governing the determination of properties and the retrieval of specified media items.

---

Crossing boundaries

3

• embedded logic -- crossing the paradigm boundary
• native objects -- crossing the language boundary
• combining Java and C++

---

slide: Section 7.3: Crossing boundaries

---

In section 3, we discussed some of the implications of the architecture sketched in section 2. We looked at embedded logic, as an example of crossing paradigm boundaries, and native objects, as an example of crossing language boundaries. In addition, some of the technical details involved in coupling (native) C++ objects to Java objects were presented.

---

Architectural patterns and styles

4

• technology matrix -- from technology to style
• case study -- visualization perspectives

---

slide: Section 7.4: Architectural patterns and styles

---

In section 4, we discussed how to decide which architectural style to adopt, based on technological constraints on the one hand and application requirements on the other hand. As an illustration, we discuss the alternatives that may arise when realizing an extension to a distributed visualization architecture.

---

Cross-platform development

5

• from Unix to Windows -- AT&T U/Win, Cygnus GNU-win32
• from Windows to Unix -- Wind/U, Mainwin

---

slide: Section 7.5: Cross-platform development

---

Finally, in section 5 we discussed some of the solutions that are available for platform-independent and cross-platform development.

object-oriented programming

[] readme course preface 1 2 3 4 5 6 7 8 9 10 11 12 appendix lectures resources

Questions

1. What are the elements of a software architecture? What role does a software architecture description play in development?
2. Give a definition of software architecture. Can you think of alternative definitions?
3. What kind of patterns can you think of for distributed object architectures?
4. Give an example of a complex software architecture. Can you relate the description of the architecture to the definition given earlier?
5. Discuss the possible motivations for deploying embedded logic.
6. How would you extend a given imperative or declarative language with objects?
7. Discuss the Java Native Interface. Does it provide a solution for the problem posed in the previous question? Explain.
8. What determines the choice for an architectural style? Give an example!

object-oriented programming

[] readme course preface 1 2 3 4 5 6 7 8 9 10 11 12 appendix lectures resources

Further reading

An excellent book on software architectures is  [Practice]. You may also want to visit the SEI architecture site at www.sei.cmu.edu/architecture, which provides definitions, and a wealth of other information. As a discussion of the software engineering implications of CORBA, you may want to read  [CorbaPatterns]. If you are interested in multimedia information systems, read  [MM]. For more information on ACOI, visit the ACOI website on www.cwi.nl/~acoi .

---

[] readme course(s) preface I 1 2 II 3 4 III 5 6 7 IV 8 9 10 V 11 12 afterthought(s) appendix reference(s) example(s) resource(s) _

---

(C) Æliens 04/09/2009

You may not copy or print any of this material without explicit permission of the author or the publisher. In case of other copyright issues, contact the author.