Domain engineering

'''Domain engineering''' is the entire process of reusing domain knowledge in the production of new software systems. It is a key concept in systematic software reuse and product line engineering. A key idea in systematic software reuse is the domain. Most organizations work in only a few domains. They repeatedly build similar systems within a given domain with variations to meet different customer needs. Rather than building each new system variant from scratch, significant savings may be achieved by reusing portions of previous systems in the domain to build new ones.

The process of identifying domains, bounding them, and discovering commonalities and variabilities among the systems in the domain is called domain analysis. This information is captured in models that are used in the domain implementation phase to create artifacts such as reusable components, a domain-specific language, or application generators that can be used to build new systems in the domain.

In product line engineering, as defined by ISO26550:2015, Domain Engineering is complemented by Application Engineering which takes care of the life cycle of the individual products derived from the product line.<ref>{{cite ISO standard|csnumber=69529|title=ISO 26550:2015 – Software and systems engineering — Reference model for product line engineering and management}}</ref>

==Purpose== Domain engineering is designed to improve the quality of developed software products through reuse of software artifacts.<ref name="Frakes 2">{{harvnb|Frakes|Kang|2007|p=2}}</ref> Domain engineering shows that most developed software systems are not new systems but rather variants of other systems within the same field.<ref name="Frakes 1">{{harvnb|Frakes|Kang|2007|p=1}}</ref> As a result, through the use of domain engineering, businesses can maximize profits and reduce time-to-market by using the concepts and implementations from prior software systems and applying them to the target system.<ref name="Frakes 2" /><ref name="Cza 19">{{harvnb|Czarnecki|Eisenecker|2000|p=19}}</ref> The reduction in cost is evident even during the implementation phase. One study showed that the use of domain-specific languages allowed code size, in both number of methods and number of symbols, to be reduced by over 50%, and the total number of lines of code to be reduced by nearly 75%.<ref name="Batory 19">{{harvnb|Batory|Johnson|MacDonald|von Heeder|2002|p=19}}</ref>

Domain engineering focuses on capturing knowledge gathered during the software engineering process. By developing reusable artifacts, components can be reused in new software systems at low cost and high quality.<ref name="Cza 20">{{harvnb|Czarnecki|Eisenecker|2000|p=20}}</ref> Because this applies to all phases of the software development cycle, domain engineering also focuses on the three primary phases: analysis, design, and implementation, paralleling application engineering.<ref name="Cza 21">{{harvnb|Czarnecki|Eisenecker|2000|p=21}}</ref> This produces not only a set of software implementation components relevant to the domain, but also reusable and configurable requirements and designs.<ref name="Harsu 8">{{harvnb|Harsu|2002|p=8}}</ref>

Given the growth of data on the Web and the growth of the Internet of Things, a domain engineering approach is becoming relevant to other disciplines as well.<ref name="ReinhartzBerger 24">{{harvnb|Reinhartz-Berger|Sturm|Clark|Cohen|Bettin|2013|p=xii}}</ref> The emergence of deep chains of Web services highlights that the service concept is relative. Web services developed and operated by one organization can be utilized as part of a platform by another organization. As services may be used in different contexts and hence require different configurations, the design of families of services may benefit from a domain engineering approach.

==Phases== Domain engineering as compared to application engineering. The outputs of each phase of domain engineering feed into both subsequent phases of domain engineering as well as corresponding phases in application engineering.|thumb|330px Domain engineering, like application engineering, consists of three primary phases: analysis, design, and implementation. However, where software engineering focuses on a ''single'' system, domain engineering focuses on a ''family'' of systems.<ref name="Cza 21" /> A good domain model serves as a reference to resolve ambiguities later in the process, a repository of knowledge about the domain characteristics and definition, and a specification to developers of products which are part of the domain.<ref name="Falbo 2">{{harvnb|Falbo|Guizzardi|Duarte|2002|p=2}}</ref>

===Domain analysis=== Domain analysis is used to define the domain, collect information about the domain, and produce a domain model.<ref name="Cza 23">{{harvnb|Czarnecki|Eisenecker|2000|p=23}}</ref> Through the use of feature models (initially conceived as part of the feature-oriented domain analysis method), domain analysis aims to identify the common points in a domain and the varying points in the domain.<ref name="Cza 38">{{harvnb|Czarnecki|Eisenecker|2000|p=38}}</ref> Through the use of domain analysis, the development of ''configurable'' requirements and architectures, rather than ''static'' configurations which would be produced by a traditional application engineering approach, is possible.<ref name="Kang 7">{{harvnb|Kang|Lee|Kim|Kim|2004|p=7}}</ref>

Domain analysis is significantly different from requirements engineering, and as such, traditional approaches to deriving requirements are ineffective for development of configurable requirements as would be present in a domain model. To effectively apply domain engineering, reuse must be considered in the earlier phases of the software development life cycle. Through the use of selection of features from developed feature models, consideration of reuse of technology is performed very early and can be adequately applied throughout the development process.<ref name="Kang 3">{{harvnb|Kang|Lee|Kim|Kim|2004|p=3}}</ref>

Domain analysis is derived primarily from artifacts produced from past experience in the domain.<ref name="Cza 23" /> Existing systems, their artifacts (such as design documents, requirement documents and user manuals), standards, and customers are all potential sources of domain analysis input.<ref name="Cza 23"/><ref name="Kang 4">{{harvnb|Kang|Lee|Kim|Kim|2004|p=4}}</ref> However, unlike requirements engineering, domain analysis does not solely consist of collection and formalization of information; a creative component exists as well. During the domain analysis process, engineers aim to extend knowledge of the domain beyond what is already known and to categorize the domain into similarities and differences to enhance reconfigurability.<ref name="Cza 23" />

Domain analysis primarily produces a domain model, representing the common and varying properties of systems within the domain.<ref name="Cza 23" /> The domain model assists with the creation of architectures and components in a configurable manner by acting as a foundation upon which to design these components.<ref name="Frakes 3">{{harvnb|Frakes|Kang|2007|p=3}}</ref> An effective domain model not only includes the varying and consistent features in a domain, but also defines the vocabulary used in the domain and defines concepts, ideas and phenomena, within the system.<ref name="Cza 23" /><ref name="Cza 84">{{harvnb|Czarnecki|Eisenecker|2000|p=84}}</ref> Feature models decompose concepts into their required and optional features to produce a fully formalized set of configurable requirements.<ref name="Cza 86">{{harvnb|Czarnecki|Eisenecker|2000|p=86}}</ref>

===Domain design=== Domain design takes the domain model produced during the domain analysis phase and aims to produce a generic architecture to which all systems within the domain can conform.<ref name="Cza 24">{{harvnb|Czarnecki|Eisenecker|2000|p=24}}</ref> In the same way that application engineering uses the functional and non-functional requirements to produce a design, the domain design phase of domain engineering takes the configurable requirements developed during the domain analysis phase and produces a configurable, standardized solution for the family of systems. Domain design aims to produce architectural patterns which solve a problem common across the systems within the domain, despite differing requirement configurations.<ref name="Cza 25">{{harvnb|Czarnecki|Eisenecker|2000|p=25}}</ref> In addition to the development of patterns during domain design, engineers must also take care to identify the scope of the pattern and the level to which context is relevant to the pattern. Limitation of context is crucial: too much context results in the pattern not being applicable to many systems, and too little context results in the pattern being insufficiently powerful to be useful.<ref name="Buschmann 42">{{harvnb|Buschmann|Henney|Schmidt|2007|p=42}}</ref> A useful pattern must be both frequently recurring and of high quality.<ref name="Buschmann 31">{{harvnb|Buschmann|Henney|Schmidt|2007|p=31}}</ref>

The objective of domain design is to satisfy as many domain requirements as possible while retaining the flexibility offered by the developed feature model. The architecture should be sufficiently flexible to satisfy all of the systems within the domain while rigid enough to provide a solid framework upon which to base the solution.<ref name="Cza 28">{{harvnb|Czarnecki|Eisenecker|2000|p=28}}</ref>

===Domain implementation=== Domain implementation is the creation of a process and tools for efficiently generating a customized program in the domain.

==Criticism== Domain engineering has been criticized for focusing too much on "engineering-for-reuse" or "engineering-with-reuse" of generic software features rather than concentrating on "engineering-for-use" such that an individual's world-view, language, or context is integrated into the design of software.<ref name="Mettler">{{harvnb|Mettler|2017|p=5}}</ref>

==See also== * Domain-driven design * Product family engineering

==References== {{Reflist}}

===Sources=== {{refbegin}} * {{cite journal | title = Achieving extensibility through product-lines and domain-specific languages: a case study | last1 = Batory | first1 = Don | last2 = Johnson | first2 = Clay | last3 = MacDonald | first3 = Bob | last4 = von Heeder | first4 = Dale | publisher = ACM | year = 2002 | pages = 191–214 | doi = 10.1145/505145.505147 | citeseerx = 10.1.1.100.7224 | journal = ACM Transactions on Software Engineering and Methodology | volume = 11 | issue = 2 | s2cid = 7864469 }} * {{cite book | first1 = Frank | last1 = Buschmann | first2 = Kevlin | last2 = Henney |author-link2= Kevlin Henney | first3 = Douglas C. | last3 = Schmidt |author-link3= Douglas C. Schmidt | title = Pattern-Oriented Software Architecture: On Patterns and Pattern Languages | volume = 5 | isbn = 978-0-471-48648-0 | year = 2007 | publisher = John Wiley & Sons }} *{{cite book | last1 = Czarnecki | first1 = Krzysztof | last2 = Eisenecker | first2 = Ulrich W. | title = Generative Programming: Methods, Tools, and Applications | publisher = Addison-Wesley | location = Boston | isbn = 0-201-30977-7 | year = 2000 }} * {{cite book | last1 = Falbo | first1 = Ricardo de Almedia | last2 = Guizzardi | first2 = Giancarlo | last3 = Duarte | first3 = Katia Cristina | title = Proceedings of the 14th international conference on Software engineering and knowledge engineering | chapter = An ontological approach to domain engineering | pages = 351–358 | year = 2002 | publisher = ACM | citeseerx = 10.1.1.19.2577 | doi = 10.1145/568760.568822 | isbn = 1581135564 | s2cid = 16743035 }} * {{cite journal | title = FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures | journal = Annals of Software Engineering | publisher = Springer Netherlands | last1 = Kang | first1 = Kyo C. | last2 = Lee | first2 = Jaejoon | last3 = Kim | first3 = Kijoo | last4 = Kim | first4 = Gerard Jounghyun | last5 = Shin | first5 = Euiseob | last6 = Huh | first6 = Moonhang | doi = 10.1023/A:1018980625587 | pages = 143–168 |date=October 2004 | citeseerx = 10.1.1.95.7568 | volume = 5 | s2cid = 1830464 }} * {{cite journal | title = Software Reuse Research: Status and Future | last1 = Frakes | first1 = William B. | last2 = Kang | first2 = Kyo | journal = IEEE Transactions on Software Engineering | volume = 31 | issue = 7 |date=July 2007 | pages = 529–536 | citeseerx = 10.1.1.75.635 | doi=10.1109/tse.2005.85| s2cid = 14561810 }} *{{cite report | last = Harsu| first = Maarit | title = A Survey on Domain Engineering |publisher=Institute of Software Systems, Tampere University of Technology |date=December 2002 | issue = Report 31 | pages = 26 | url = http://practise2.cs.tut.fi/pub/papers/domeng.pdf | isbn = 9789521509322 }} * {{cite journal | title = Contextualizing a Professional Social Network for Healthcare: Experiences from an Action Design Research Study | last1 = Mettler | first1 = Tobias | journal = Information Systems Journal |date=2017 | volume = 28 | issue = 4 | pages = 684–707 | doi=10.1111/isj.12154| s2cid = 49411423 | url = https://serval.unil.ch/resource/serval:BIB_72ABD7CEFC7D.P002/REF.pdf }} * {{cite book | first1 = Iris | last1 = Reinhartz-Berger | first2 = Arnon | last2 = Sturm | first3 = Tony | last3 = Clark | first4 = Sholom | last4 = Cohen | first5 = Jorn | last5 = Bettin | title = Domain Engineering: Product Lines, Languages, and Conceptual Models | publisher = Springer Science+Business Media | isbn = 978-3-642-36654-3 | year = 2013 }} {{refend}}

Category:Software design Category:Ontology (information science) Category:Software development process Category:Systems engineering Category:Business analysis