{'fraction_non_alphanumeric': 0.013230614637414168, 'fraction_numerical': 0.0008373806732540613, 'mean_word_length': 5.470205850487541, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
A Component Oriented Domain Architecture for Fish Farming

This paper presents experiences with applying the Magma model for component based software engineering for a family of applications supporting fish farming. It focuses on lessons learned from the design and evaluation of a common component based architecture as a means to cope with challenges such a rapidly changing requirements and a dynamic technology environment. It concludes that such an architecture is a good match in this case. INTRODUCTION The Magma model [2] is an approach to component based software engineering tailored for developing software for a market. Typical for such development is that requirements varies between different users and evolves rapidly over time. Furthermore the competition pushes for rapid exploitation of advances in underpinning technologies. The model was developed in a joint effort between the Norwegian association of the software industry (PROFF), SINTEF and a handful pilot users. In this paper we present experiences with the design of a component oriented domain architecture by Superior Systems, which is a small Norwegian company developing software products for the fish farming industry and that was one of the pilot users in the Magma project. This effort was one step in in a strategic move towards full adoption of the Magma model for all software development in Superior Systems. BUSINESS PROBLEM Fish farming is a rapidly growing business area. In a relatively short time it has evolved from a simple craft based production to a knowledge intensive industrialized production with rapidly growing needs for software systems that support optimal planning, control and documentation of the production process as well as common business processes like accounting and budgeting. As a result of this rapid evolution Superior experience a strong market pull for evolution of the software products they supply, both in terms of demands for new functionality and in terms of demands for distributed operation and internet based access to the system. In addition the Superior products are marketed and sold internationally and has to cope with variations between different countries in language, traditions and governmental regulations. It was realized that the monolithic architecture of the current system made it difficult and prohibitively expensive to accommodate the pace of evolution of the product that were foreseen as necessary to remain competitive in the marketplace. This situation was typical of the pilot users of Magma, and both earlier experience from software reuse projects and experiences from other engineering disciplines had convinced us that a component based approach was the most promising approach to achieving the flexibility called for in order to cope with such challenges as described above. TECHNICAL APPROACH Figure 1 illustrates the basic assumptions of the Magma Model. The typical user of the Magma model is a software developing company that specialises in providing software products for particular business domain. A business domain is characterised by business processes that usually involves human actors and manipulate business artifacts and that are common for businesses belonging to that domain, although considerable variation in how the business processes are carried out in detail is the norm. A domain is supported by an ensemble of software applications provided by software product companies that specialize in applications for that particular problem domain. Figure 1 Reference Model An application is a software product that is used by the actors to carry out business processes, and is typically tailored to support a particular subprocess or a particular type of actor in the business domain. Applications use components to implement the end user functionality that they offer. This structure of applications and components and the way they interact constitutes the domain architecture. Normally components are shared in the sense that the services they offer are being used by several applications or other components. Sharing takes place both at the type level (code reuse) and at the instance level (data sharing). Reference Architecture The Magma reference architecture is shown in Figure 2. Basically it may be seen as a macro pattern for a component oriented domain architecture. The reference architecture models a software system as a collection of software components collaborating through carefully designed interfaces and supported by a standardized component infrastructure (labeled Comp. MW in the figure) providing the basic mechanisms for creating and destroying and communicating between components in a distributed hardware environment. Components are distinguished units that are at the same time units of design, construction, configuration management, substitution and distribution and that conform to and provide the realization of a set of interfaces. The granularity of components may vary, but normally a component encapsulates a collection of collaborating programming level objects. The component are classified into five main categories according to their role in the system: i) User Interface, ii) Application, iii) Business, iv) Data storage & retrieval and v) IT services. Figure 2 The Magma Reference Architecture User Interface Components User Interface components are responsible of presenting information to the user. These are typically graphical components based on appropriate third party user interface component libraries such as Microsoft Foundation Classes (MFC), Java Abstract Windowing Toolkit (Java AWT) and Java Swing. Examples of common user interface components are: windows, forms, menus, buttons, grids and lists. Application Components Application components combine services offered by the business components with suitable user interface components into useful applications. Data S&R Comp MW IT sevices Business Application UI Concepts &Artifacts Processes