Intro to Domain-Specific Software EngineeringObjectivesSlide 3Domain-Specific Software EngineeringExamples of DomainsTraditional Software EngineeringArchitecture-Based Software EngineeringSlide 8Three Key Factors of DSSEThree Key FactorsSlide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Becoming More ConcreteDomain ModelSlide 20Slide 21Slide 22Slide 23Slide 24(Partial) Domain DictionaryInfo Model: Context Info DiagramInfo Model: Entity-Relationship DiagramInfo Model: Object DiagramFeature Model: Feature Relationship DiagramFeature Model: Use Case DiagramFeature Model: Representation DiagramOperational Model: Data Flow DiagramOperational Model: Control Flow DiagramOperational Model: State Transition DiagramReference RequirementsDomain-Specific Software ArchitectureReference ArchitectureDifferent Kinds of Reference ArchitectureExample Reference ArchitectureCopyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.Intro to Domain-Specific Software EngineeringSoftware ArchitectureLecture 232Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureObjectivesConceptsWhat is domain-specific software engineering (DSSE)The “Three Lampposts” of DSSE: Domain, Business, and TechnologyDomain Specific Software ArchitecturesProduct LinesRelationship between DSSAs, Product Lines, and Architectural StylesExamples of DSSE at work3Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureObjectivesConceptsWhat is domain-specific software engineering (DSSE)The Three Key Factors of DSSE: Domain, Business, and TechnologyDomain Specific Software ArchitecturesProduct LinesRelationship between DSSAs, Product Lines, and Architectural StylesExamples of DSSE at work4Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureDomain-Specific Software EngineeringThe traditional view of software engineering shows us how to come up with solutions for problems de novoBut starting from scratch every time is infeasibleThis will involve re-inventing many wheelsOnce we have built a number of systems that do similar things, we gain critical knowledge that lets us exploit common solutions to common problemsIn theory, we can simply build “the difference” between our new target system and systems that have come before5Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureExamples of DomainsCompilers for programming languagesConsumer electronicsElectronic commerce system/Web storesVideo gameBusiness applicationsBasic/Standard/“Pro”We can subdivide, too:Avionics systemsBoeing JetsBoeing 747-400Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.6Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureTraditional Software EngineeringOne particular problem can be solved in innumerable waysSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.7Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureArchitecture-Based Software EngineeringGiven a single problem, we select from a handful of potential architectural styles or architectures, and go from these into specific implementationsSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.8Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureDomain-Specific Software EngineeringWe map regions of the problem space (domains) into domain-specific software architectures (DSSAs)These are specialized into application-specific architecturesThese are implementedSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.9Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureThree Key Factors of DSSEDomainMust have a domain to constrain the problem space and focus developmentTechnologyMust have a variety of technological solutions—tools, patterns, architectures & styles, legacy systems—to bring to bear on a domainBusinessBusiness goals motivate the use of DSSEMinimizing costs: reuse assets when possibleMaximize market: develop many related applications for different kinds of end users10Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureDomain BusinessTechnologyThree Key FactorsDomainMust have a domainto constrain the problem space and focus development11Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureDomain BusinessTechnologyThree Key FactorsTechnologyMust have a variety of technological solutions—tools, patterns, architectures & styles, legacy systems—to bring to bear on a domain12Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureDomain BusinessTechnologyThree Key FactorsBusinessBusiness goals motivate the use of DSSEMinimizing costs: reuse assetswhen possibleMaximize market: develop many related applications for different kinds of end users13Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureDomain BusinessTechnologyThree Key FactorsDomain + Business“Corporate CoreCompetencies”Domain expertiseaugmented bybusinessacumen andknowledge ofthe market14Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureDomain BusinessTechnologyThree Key FactorsDomain + Technology“Application FamilyArchitectures”All possibletechnologicalsolutions toproblems in adomainUninformed and unconstrained bybusiness goalsand knowledge15Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureDomain BusinessTechnologyThree Key FactorsBusiness + Technology“Domain independentinfrastructure”Tools andtechniques forconstructingsystems independent of anyparticular domainE.g., most generic ADLs, UML, compilers, word processors, general-purpose PCs16Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureDomain BusinessTechnologyThree Key FactorsDomain + Business +
View Full Document