1. Domain Specific Software Engineering (DSSE) Software Engineering, just as other engineering disciplines, needs to take into account of the different domain in which it is working. Consider the “electrical engineering” of Electric Coffee Machine (household appliance) versus the “electric engineering” of Airplane (avionics): a)We may design the electric Coffee Maker in such a manner that it is focused on properties such as speed of heating, electric safety, and looks; but we know if it breaks the user will just go buy a new one --- do NOT worry about maintenance (reusable parts & replacement) too much. b)We may design commercial Airplanes for super reliability and safety first. Thus we want to design for frequent maintenance (reusable parts and replacement). Then we are concerned with speed and comfort. We are not concerned with the “looks” of the airplane. Our design concerns differ based on the different problem domain.

2. DSSE (cont.) Each Different Domain require potentially different: –Principles –Techniques –Processes –Tools Domain Specific Software Engineering is an approach to developing software by leveraging the existing domain knowledge (usually the “common” part) extensively: 1.Dividing requirements between those common across application domain and those that are unique to the system 2.Common requirements can be tied to existing solutions, allowing design focus on domain specific areas 3.Many of the software development activities are simplified through reuse of the common material and focusing only on the domain specific areas separately 4.Separation of the tools and environments for common and domain specific needs will make the development and support activities a lot clearer 5.Separation of the common from the domain specific will allow communications to the various stakeholders easier, especially that the domain specific areas may have their own “parochial” vocabulary.

3. General vs Domain Specific Software Engineering..... Problem Space General Solution Space Problem Space by Domains Solution Space by Domains.... ? searching for solution - - - a big frustration mapping specific domain problems to domain specific reference architecture

4. DSSE in terms of 3 Areas: Domain, Business & Technology Technology Business Domain DSSE; Product Lines Interest lies where (Domain ∩ Business ∩ Technology) defines different industry domain concerns defines different business goals such as efficiency or money defines various tools, methodologies & processes

5. Domain Specific Software Architecture Domain Specific Software Architecture is a set of principal design decisions composed of: 1)A reference architecture which describes a general computational framework for a significant domain of applications 2)A component library of reusable chunks of domain expertise 3)An application configuration method for selecting and configuring components within the architecture to meet particular application requirements DSSA is not free and is built over time upon deep experiences with the domain

6. A “Process” View of DSSE and DSSA Reference Architecture Dev. Domain Analysis Framework & Component Dev. Product line Development Application Development Domain Model Domain Specific App. Product Arch. Model Framework & Comp. Library Ref. Arch. Model DSSE done over time additional reqs. Parts of DSSA Note: Only for “Large” Organizations?

7. Domain Model Domain model characterizes the problem space: –Standardizes the domain terminologies and semantics forming a domain ontology or domain system –Provides the basis for standardized descriptions of problems to be solved in that domain Consider the term, “lot”. What does this mean? A) It means a “parcel of land” in the real estate industry. B) It means a “set of same type of items” in manufacturing. C) It means “role in life” in sociology and psychology. Domain model is created as a result of: 1.Context analysis of those items within the domain context and relating to those items outside of the domain context 2.Domain analysis via identifying, capturing, and organizing those entities, functionalities, properties, and data which recur across multiple applications within the specific domain.

8. Domain Model (cont.) A domain model is made of 4 main components : 1)Domain dictionary composed of domain specific terms 2)Information model which is a collection of models built from context analysis and information analysis (domain analysis- describes the domain) 3)Feature model which describes the user/customers expectations of the capabilities of the application in the given domain 4)Operational model identifies how the applications within the domain works:

9. Elements of Domain Model Domain Dictionary Information Model Feature Model Operational Mode Context info Diagram * Class (object) diagram Semantic Network * Entity-Relation diagram State Transition diagram Control-flow diagram Data-flow diagram Representation Diagram * Use Case diagram Feature Relation Diagram * How application Control and Data “flow” Dictionary Of “domain” terms Capabilities (reqs.) of the domain application “Interdependence” of entities in the domain

10. A Few Possibly-Unfamiliar Diagrams The domain model may use part or all of the different diagrams to depict the models. Most are familiar to software engineers but a few may not be: –Context-information diagram - captures high level information flow among entities within and outside of the domain system (reminds one of “use case diagram”) –Semantic network – a network diagram to represent relations among concepts (entities) in the domain –Feature-relation diagram – describes overall-all mission of the domain application –Representation diagram – describes how information is made available to users (e.g. UI looks and flow )and other applications

11. Domain Specific Software Architecture (DSSA) & Reference (canonical) Requirements DSSA is focused on the “standard” or canonical parts of a specific domain to create the reference architecture. It still depends on the requirements specified. Such “standard’ or canonical requirements for the domain is called the “Reference Requirements” Reference Requirements are derived from customers in the same application domain and contains: –Functional requirements –Non-functional requirements –Design requirements –Implementation requirements Reference requirements contains 3 parts: –Mandatory features : applicable to all systems in the domain –Optional features: applicable to only subsets of systems in the domain –Variable features: known to differ in nature by “specific application” in the domain Note that reference requirements are similar to what is shown in feature model

12. Reference Architecture From the reference requirements & the domain model (which speaks to business, technology, and a specific domain), we can develop the Reference Architecture which was defined earlier as: Def: Reference Architecture is the set of principal design decisions that are (1) simultaneously applicable to multiple-related-systems, typically within an application domain, (2) with explicitly defined points of variation. A reference architecture may be “defined” via: 1.An architecture derived completely from a complete, single product in the domain that serves as guidance for the future (not ideal –too narrow) 2.Incomplete variant architecture containing a specified common part among products in the doamin and an unspecified part, which may vary. (drift & erosion?) 3.Domain-specific invariant architecture with explicitly “defined” points of variation As you study “sample” retail apps ---- which way are you going to approach your assignment ?

13. Developing Reference Architecture There is no “simple” path to when and how to develop a reference architecture. –Timing must be just right: not too early when not enough is know or too late when everything is already developed. This is a tall order ---- the best way may be do this incrementally as enough information and knowledge are acquired. –The form of the reference architecture can not be based on a single product (too restrictive), nor just incomplete invariant (may lack too much detail, especially on the incomplete variable parts) ---- the best is the invariant architecture with explicit points of variation. Caution : too many points of variation can be combinatory nightmare! e.g. 6 potential points of variation can give you 2 6 = 64 combinations of variations!

14. Product-Line Architecture The software industry has been building products in the form of product-line. (e.g. Oracle database, Oracle HRM, MS Office Suite, SAP ERP, etc.) Product-line architecture is similar to reference architecture in DSSA, except in scope and completeness: –product-line architecture captures the complete set of design decisions of well-defined, multiple related products in the product- line – while DSSA reference architecture may have incomplete and undefined parts Product-line architecture - design decisions which simultaneously capture all the related products in the product-line. Some of these decisions will be 1) common among all products, 2) some will be common among a subset of the products and 3) some will be unique to individual product in the product-line.

15. Tabular Method to specify Product-Line (requirements and/or architecture) Features or Comp/connectors Office Suite: Product-Line Basic Complete Advanced word processor spread sheet presentations layout support spell check grammar check file import/export auto save task management multi-lingual XXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXX You can pick or “select” your own a)Combinations - single product b) add more features such as: - re-do - pagination c) add more functions - statistical calc.

16. Advantages of Product-line Biggest Rationale for Product-line is to gain “re-use”. –Less cost (spread the cost across multiple products in the family and lower the individual cost → lower pricing) –Shorter schedule for subsequent products that share common features and functionalities –Better quality for subsequent products that share already tested and proven features and functionalities Re-used common parts also reduces individual product maintenance cost –Share fix to common parts –Share cost on improvements to the common parts

17. Domain Specific Architect Can you be a domain specific architect. Yes, if you know: –Software design  Some specific application domain –Technologies –Standards that has to be kept  Business economics Domain Technology Business

18. Example: Payroll “Product-Line” Technology Based Re-Architecting Oracle DB AS/400 DB MS SQL UNIX based Payroll MS Window based Payroll IBM AS/400 based Payroll UNIX Oracle DB AS/400 MS/ Window Payroll web cloud Common UI Common DB

19. Now Consider the Domain & Business Domain Specific Considerations: –Universal Part: inputting employee payroll information, modifying employee payroll info, computing pay check, printing pay check, performing direct deposit of pay check, - ------ etc. –Variable Parts: benefits management; retirement pension management; amount of reports and history maintained ----- etc. Business Specific Considerations: –There will be 3 products in the product line: 1) Core, 2) Complete, 3) Deluxe for customer “pricing” purposes –International Versions based off US version and includes: Spanish, French, Chinese, Japanese, Arabic versions for international marketing purpose –There will be two “maintenance” updates per year, which includes: bug fixes, annual tax law change, minor updates for customer satisfaction purpose You can imagine the version control and configuration management nightmare for this!

20. Example of Product “Family” ---- and Versioning General Requirements French ( version 1 ) Brazilian ( version 1 ) Japanese ( version 1 ) General Requirements (Version 2) French ( version 2 ) General Requirements (Version 3) French ( version 3 ) Japanese ( version 2 ) Japanese ( version 3 ) Brazilian ( version 3) Brazilian ( version 2 ) French (version 2.1) If Fench Version 2.1 came after Version 3, we may need to build a French V3.1 US (common) code v1 US (common) code v2 US (common) code v3