# Introduction omain engineering is a reusable approach that focus on a selected application domain as like inventory control, finance management, word processing etc. The motto of domain engineering is find, catalog, construct and broadcast set of software artifacts that could apply for future software in specialized application domain. In domain engineering, we perform domain analysis and capture domain knowledge in the form of reusable software assets. By reusing the domain assets, an organization will be able to deliver a new product in the domain in a shorter time and at a lower cost. In industry, domain engineering forms a basis for software product line practices. Domain engineering is most often divided into three phases: domain analysis, domain design, and domain implementation. At present, from the point of domain engineering, little research has been carried on the accounting management domain. Based on the real project, this paper introduces domain engineering method into the development of accounting management system. In the domain analysis phrase, we use the FODA method to analyze the accounting management domain, expand its feature-oriented modeling method, establish the feature model of accounting management domain; in the domain design phrase, we design multi-tier system architecture of accounting management domain; In the domain implementation phrase, We combine AOP technology with OOP technology, separate crosscutting multi modules concerns in software, reduce the dependence between components effectively. Practice has proved the systems developed by this method have a better performance of maintainability, extendibility and reusability. # II. # Analysis of Account Management Domain a) Feature Oriented Domain Analysis A method specifically designed for DA is the Feature Oriented Domain Analysis (FODA) method developed at the SEI. This process is for domain analysis which supports the discovery, analysis, and documentation of commonality and differences within a domain. The feature oriented concept emphasis on findings the capabilities that are normally expected in applications in a given domain. The FODA domain model captures the similarities and differences among domain assets in terms of a set of related features. A feature is a distinctive aspect, quality, or characteristic of the domain asset. The features identified by the FODA method can be used to parameterize the system product line and Implementations of the domain assets. The features differentiating domain entities arise from differences in capabilities, operating environments, domain technology, implementation techniques, etc., i.e., a range of possible implementations within the domain. A specific implementation consists of a consistent set of feature values describing its capabilities. The feature diagram depicts the decomposition of features into sub-features in a hierarchical way. For each sub-feature below a certain feature it can be specified if it is compulsory, secondstringer or optional. The graphical notations introduced in are used here. We first briefly describe the representations used in illustrated in Figure 1. The compulsory feature is represented by being attached to an edge ending with a filled circle. So the feature F consists of both K1 and K2 in this case, and the feature instances here are {F, K1, K2}. The optional feature is ( D D D D ) C represented by being attached to an edge ending with an unfilled circle. So the feature F may or may not contain K1. The optional feature instances here are {F, K2} and {F, K1, K2}. The second-stringer feature is represented by connecting edges with an arch. So the feature F consists of exactly one of its child features. The second-stringer feature instances here are {F, K1} and {F, K2}. Note that if K1 is optional while K2 is compulsory, then the second-stringer feature instances here are {F}, {F, K1} and {F, K2}, because the child feature instances derived from the K1 side contain an empty feature. The OR feature is represented by connecting edges with a filled arch. The OR feature instances here are {F, K1}, {F, K2} and {F, K1, K2}. If there is an optional child feature, then the OR representation is actually equivalent to the situation that all the child features are optional, i.e., the OR feature instances will be {F}, {F, K1}, {F, K2} and {F, K1, K2}. Through domain analysis, we find common and variant features of different account management systems, from different requirements: business requirement, user requirement, and functional requirement. Business requirement depicts business ability that the software system should have. User requirement depicts the interaction process between user and system, and this process may reflect the generally accepted business process in this domain. Functional requirement depicts functions that software system must have in order to realize the specific business requirements. Through domain analysis, we divide the service of account management domain into the following types: Account Drafting, Account Auditing, Account Implementation, Account Adjustment, Account Analysis, Account assessment. Among them, account assessment is optional features. The second analysis is to identify functional features which the service has, analyze the specific functions which systems must have in order to complete special service. Taking account implementation control service as example, its functional layer includes compulsory features and optional features. And as Optional features include data import. Compulsory features, namely common features, exist in each member system of the special domain, but optional features are one type of representation style of variant features, and only exist in parts of member system of the special domain. Optional features represents the variability which is relative to whole features, its introduction enables the feature model to respond the different system's diversity of domain, and makes the feature model to have better tailorability and expansibility. The third Behavior characteristics layer analysis. The task of behavior characteristics layer analysis is to identify behavior characteristics what the function should be there, analyze behavior features of the early stages of functional implementation, such as preconditions of functional implementation, preparatory works; analyze the principal behavior characteristics of function part, find its outstanding features and its possible variability; analyze behavior features of the later period of function implementation, such as the postposition condition of functional implementation and the domination shift after the functional implementation. # III. Account Management Domain with Architectural Design Domain designing is the core architecture for a family of applications according to domain analysis model, namely a Domain-Specific Software Architecture (DSSA), and based on the DSSA, We can identify, develop and organize the reusable components. According to the requirements defined in the domain analysis stage, considering the actual development environment (such as operating system, database, communication mechanism, middleware, and so on, this paper designs Account Management domain architecture, This architecture uses the hierarchical architecture style. The hierarchical architecture style can avoid system component's coupling, protect and divide system function, improve maintainability, reusability and extendibility of software. This domain architecture has five components: foundation component layer, atomic business component layer, foundation business component layer, general business component layer, industry application component layer. (1) Industry application component:-This component is designed to satisfy special industry business requirements. It can be encapsulated by one or more atomic business components, or by one or more foundation business components, and even also can be combined by atomic business components, foundation business components and general business components. (2) General business component: -This component is a subsystem level application component which is formed by encapsulates foundation business components or atomic business components, such as revenue budget components, investment budget components, capital budget components, cash flow budget components. # General Business Component # Income budget Capital budget Expense budget # Cash flow budget # Foundation Business Component # Sales revenue target element # Period expense target Element # Business Component # Accounts receivable target element # Atomic Business Component # Implementation of Budget Management Domain In the part of domain design, we have putted required and harder structural DSSA and assigned the stable parts to the budget management domain system architecture and the variable parts to components. In the process of component implementation, we normally use OOP Object-Oriented Programming) for the simplifying the things and encapsulating the class. Aspect-oriented Programming (AOP) is a new programming technology which compensates the weakness of Object-Oriented Programming (OOP) for applying common behavior that spans multiple related object models. AOP introduces Aspect, it packages the behavior which impacts multiple classes into a reusable model, it allows programmers to model crosscutting concerns and eliminates the code tangling and scattering caused by OOP, the code is more readable and easier to maintain. The key to achieve AOP is to intercept normal method call. In order to complete some extra requirements, we will need to add extra features transparent "weaving" to these methods. Generally speaking, the weaving method includes two major types: Static weaving method and Dynamic weaving method. Static weaving method usually need to extend compiler's function, directly weave codes into the appropriate weaving point by modifying byte codes(Java) or IL code(.Net). Or, we need to add new syntax structure for original language to support AOP. As for dynamic weaving method, there are many specific implementation methods. In the Java platform, we can use Proxy pattern, or custom Class Loader to implement AOP features. Generally, at the .Net platform, the following methods can be used to achieve the dynamic weaving method: 1. Use Context Attribute and Context Bound Object to intercept the object methods. 2. Use Emit technology in the run-time to build new class which codes are woven into. 3. Use Proxy pattern V. # Conclusion In this paper it is depicts the application of domain engineering in account management system development. Domain analysis method of FODA this paper has extended its feature oriented modeling method and design multi-layer framework according to the domain analysis result. At the domain implementation segment we applied a lightweight AOP framework with the name of SJAOP. This technology with the help of OOP separates crosscutting multi modules concerns in software, reduces the dependence between components effectively, and implements the system with a better performance of maintainability, extendibility and reusability. 1![Figure 1:](image-2.png "Figure 1 :") Picture 2 : Architecture of Account Management System based on Component (3) Foundation business component: -On the basis of atomic business component, these components are able to complete certain business functions through aggregation of some atomic components. This type of component faces to application directly, such as sales revenue target components, period expense target components, business interface components. (4) Atomic business component: -According to the decomposition business object, this is made by * Feature-Oriented Domain Analysis (FODA) Feasibility Study JamesAHess WilliamENovak ASpencerPeterson 2000 Carnegie Mellon Software Engineering Institute (SEI), USA * Domain-Specific Modeling : Enabling Full Code Generation StevenKelly Juha-PekkaTolvanen 2008 Wiley-Interscience * An Object-Oriented Method for Domain Engineering WangQian-Xiang WuQiong LiKe-Qin YangFuqing Journal of Software 13 10 2002 * An outline of Domain Engineering LiKe-Qin ChenZhao-Liang MeiHong YangFuqing Computer Science 26 5 1996 * Feature Modeling Method Oriented to Traffic Domain Component WangFan TanGuo-Zhen WangHao Computer Engineering 35 1 2009 He Qinlai * Research on Enterprise Budget Management System Based On Domain Engineering ZhengminLiu International Journal of Digital Content Technology and its Applications 5 9 2011 * Towards a semantic anchoring infrastructure for domain-specific modeling languages KaiChen JanosSztipanovits SandeepNeema International Conference on Embedded Software 2005