The structure of the soft parts library (this paper is reproduced from the software engineering expert network www.21cmm.com) domain analysis from software engineering's view, the domain is to propose application requirements to the target software system and background knowledge. The main tasks of domain analysis are for single or family similar domains, to reuse the software reuse, explore and excavate the soft components that can be shared by multiple target software systems in software systems, and structural organizations for structuring . Domain analysis is similar to demand analysis activities, they are all based on the development activities of the application domain in the software project, and to complete different domain modeling tasks. However, domain analysis must have a broader perspective than demand: not only to serve the current software project, but also discover the commonality and difference points between software items in historical projects, and look at the same or similar application Future software project. The above figure shows the main input, output items, participants and control of domain analysis activities. Domain analysis input information can be obtained from a variety of channels: technical documentation, completed similar software projects (which include source code, design document, test plan, user manual, etc.), user review, expert advice, user needs, and current software The domain feature information feedback from the project. Domain analysis activities are generally completed by domain analysts, analytical assistants and domain experts. They submit the results information of domain analysis activities under the control of domain analysis methods and management mechanisms - the general domain structure model (concept and entity classification method in wrace), software development standards (including demand analysis and software method framework, Software development process standards, coding standards, interface standards, etc.), and domain languages for engraving the characteristics, domain objects, operations, and their relationships. Since domain analysis and demand analysis are main tasks in constructing a model in the field of application, some demand analysis techniques can play a role in domain analysis, demand description languages (data flow graph, entity-relational diagram, object-oriented demand) Description mechanism, etc.) can also be used as the foundation of the domain language. However, domain analysis must be generalized, abstractized, and parameterized, indicating the similarity between different software items in a similar domain, and performs differential graphics in different fields, so that the domain model elements are different Adaptability and flexibility of software projects. Thus, after omitting the technical details of modeling, the domain analysis process can generally summarize the following steps: (1) Discover and describe the reusable entities; (2) Abstract, generalization of the relationship between these test questions and them And parameterization; (3) Classify the reusable entity, return to, for future reuse. In addition to the domain analysis results shown above, domain analysis can also produce a reuse super structure to manage the possibility of software reuse in the various development phases of subsequent software items, and collecting various statistics on reusing activities. These data can be fed back to a domain analysis method for continuous improvement. In reuse super structures, soft parts library managers are responsible for the search and extraction of soft components, and soft parts are responsible for the quality control and standardization of soft components, and reuse administrators collect statistics related to reuse, coordinate all reuse activities. The result of the development domain analysis of the soft component provides guidelines for the selection of soft components. Once some software should be added to the part library as a reuse member, the developer must actually construct them. Since the life cycle of the soft part will cross the development project or even the application area, the development of soft components has considerable specificity, that is, how to make the soft component more general, easier to assemble into new software systems, and in the new operating environment What is better to show better? Code level reuse is the easiest and most popular.
