Ari Jaaksi

Developing mobile browsers in a product line

Product lines must be product and application driven instead of reuse or platform driven, at least, that is the lesson learned at Nokia. The paper considers how the mobile phone company initiated and used a product line to develop and deliver mobile browser products. These products let mobile phone or personal digital assistant users access services over wireless telecommunications networks.

Experiences on Product Development with Open Source Software

This article discusses Nokia’s experiences of using open source in commercial product development. It presents the development model used in the creation of mobile consumer devices and highlights the opportunities and challenges experienced. This article concludes that the main benefits come from the utilization of already available open source components, and from their quality and flexibility. It illustrates the challenges and solutions faced when mixing open and closed development models at Nokia.

Implementing interactive applications in C

This paper presents an object‐oriented approach for the implementation of interactive systems. This approach applies the model‐view‐controller (MVC) paradigm, which is modified for the C++ environment. The modified paradigm is called MVC++. In this approach the design of interactive applications starts by constructing an object model that represents the key concepts of the problem domain. This object model does not contain any user interface elements. According to the MVC++ approach, the object model is called the model part of the application. Only after the model part has been created, is the user interface designed. A collection of user interface classes is called the view. The classes that connect the model and the view form the controller, which is designed to communicate with both the model and the view.

Open source legality patterns: architectural design decisions motivated by legal concerns

Complications emerge when various open source software components, governed by different licenses, are used in the same software system. For various reasons, these licenses introduce different privileges and requirements on the use and distribution of composed code, and are therefore often fundamentally incompatible with each other when combined arbitrarily. Consequently the way the different components can be integrated requires attention at the level of software architecture. In this paper, we introduce open source legality patterns -- architectural design decisions motivated by legal concerns associated with open source licensing issues and licenses themselves. Towards the end of the paper, we also review some related work and discuss why it is important to create common guidelines for designs that mix and match different open source systems and proprietary software, and provide directions for future work.

Object-oriented specification of user interfaces

This paper presents an object‐oriented approach for the specification of graphical user interfaces. Specification starts with the analysis of the end users operations. The user interface is then designed on the basis of this analysis. Operation analysis is followed by structure and component specification which presents the dialogue structure of the application and the contents of each dialogue. Visualization produces the final screen layouts, and task specification documents the usage of the user interface for the purpose of creating users guides.

Assessing software projects: tools for business owners

Executives need to assess ongoing software projects. They need truthful information to decide if projects should be redirected, cancelled, or strengthened. They need to verify that customer requirements are satisfied and business goals are met.We present a set of tools for executives to monitor the status of ongoing software projects. These tools allow executives that are not experts of software engineering to assess requirements, software architectures, development projects, and development organizations. Our tools, used commonly at Nokia and elsewhere, utilize use cases, views to architecture, frequent builds, and testing statistics. The fact that many projects already utilize these tools for software creation makes it easy to extend their use to serve executives and business management. We explain how managers can use these tools to get information, how to interpret this information, and how to integrate the tools into the interaction between the managers and their project teams.

Tried and true object development : practical approaches with UML

1. Developing interactive software systems 2. Object-oriented data management 3. Large-scale development 4. Small-scale development Summary of our standard process.

FAMOOS Workshop on Object-Oriented Software Evolution and Re-Engineering

Over the years, a large body of complex and expanding object-oriented software has accumulated, whose evolution and maintenance is placing an increasing burden on software developers. Dealing with large-scale, mature object-oriented systems and frameworks, and endowing them with flexibility is therefore a key area for the success of future software development projects.

Type-safe Callbacks with Abstract Partners

In C++, a caller must know the type of the object whose methods it is calling. The objects called are typically implemented previously, e.g., in object libraries, and therefore their types are known. However, in some cases, a library object or any other previously implemented object needs to call back a user whose type is not known. We should therefore not make restrictive assumptions about the types of the objects that are called back. This is not a trivial problem in C++.