Technical component
A business component is in the software engineering a software component that a particular set of services in a business application (the application domain offers).
definition
A component in the context of software development consists of various (software) artifacts . It is reusable, closed and marketable, makes services available via well-defined interfaces , hides their implementation and can be used in combination with other components that are not necessarily foreseeable at the time of development.
Based on this component definition, Turowski et al. explicitly between system and specialist components . System components are generic components that are used exclusively for the implementation of software functions and have no direct reference to operational functions. On the other hand, a component is referred to as a technical component if it offers a certain set of services in an operational application domain.
A number of characteristic concepts and technologies in a limited operational area are regarded as operational application domains . Typical operational application domains in this sense are, for example, production planning , warehouse management or financial accounting . The artifacts include Turowski et al. the executable program code , the data describing the initial status of the component , the documentation , tests and the specification . For the latter, a detailed methodological standard is proposed in the form of a memorandum , which stipulates the notations to be used for the specification of technical components and a framework of the facts to be specified organized in seven levels.
Specification of specialist components
The specification of a technical component is understood to be the complete, consistent and clear description of its external view. This shows which services a technical component provides in which framework, but not how these are implemented internally by the component. However , a case study carried out by Peter Fettke and Peter Loos shows that the standard proposed in the memorandum, especially the specification, is not practicable for internal use. Even simple behavioral characteristics of a technical component are difficult to specify because the specification becomes too extensive and, from a practical point of view, too many demands are made on formalisms.
The effort for a completely formal specification is not economically feasible, and the specification becomes inappropriately complex in relation to the content of the statements made and is difficult to understand by other reviewers. Established process models for software development proceed iteratively and incrementally. A full specification is usually only achieved at the end of development. At this point, however, this is no longer required in the required complexity and formalized form and then only serves the end in itself.
Individual evidence
- ↑ a b Standardized specification of specialist components . In: Klaus Turowski (ed.): Memorandum of the working group 5.10.3 Component-oriented operational application systems . Society for Computer Science, February 2002, p. 1 .