4 Domain-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 before

9 Three 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 users

10 Three Key Factors DomainMust have a domain to constrain the problem space and focus developmentDomainBusinessTechnology

11 Three Key Factors TechnologyMust have a variety of technological solutions—tools, patterns, architectures & styles, legacy systems—to bring to bear on a domainDomainBusinessTechnology

12 Three Key Factors Business Business goals motivate the use of DSSEMinimizing costs: reuse assets when possibleMaximize market: develop many related applications for different kinds of end usersDomainBusinessTechnology

13 Three Key Factors Domain + Business “Corporate Core Competencies”Domain expertise augmented by business acumen and knowledge of the marketDomainBusinessTechnology

14 Three Key Factors Domain + Technology“Application Family Architectures”All possible technological solutions to problems in a domainUninformed and unconstrained by business goals and knowledgeDomainBusinessTechnology

17 Three Key Factors Product-Line ArchitecturesA specific, related set of solutions within a broader DSSEMore focus on commonalities and variability between individual solutionsDomainBusinessTechnology

18 Becoming More ConcreteApplying DSSE means developing a set of artifacts more specific than an ordinary software architectureFocus on aspects of the domainFocus on domain-specific solutions, techniques, and patternsThese areA domain model andA domain-specific software architecture (DSSA)

19 Domain ModelA domain model is a set of artifacts that capture information about a domainFunctions performedObjects (also known as entities) that perform the functions, and on which the functions are performedData and information that flows through the systemStandardizes terminology and semanticsProvides the basis for standardizing (or at least normalizing) descriptions of problems to be solved in the domain

25 (Partial) Domain DictionaryLunar Module (LM): this is the portion of the spacecraft that lands on the moon. It consists of two main parts: the Ascent Stage (which holds the crew cabin) and the Descent Stage, which contains thrusters used for controlling the landing of the LM.Reaction Control System (RCS): a system on the Lunar Module responsible for the stabilization during lunar surface ascent/descent and control of the spacecraft’s orientation (attitude) and motion (translation) during maneuversVertical velocity (see also One-dimensional motion):For a free-falling object with no air resistance, ignoring the rotation of the lunar surface, the altitude is calculated as follows:y = ½ * a * t2 + vi * t + yiy = altitudea = constant acceleration due to gravity on a lunar body (see Acceleration for sample values)t = time in seconds; vi = initial velocity; yi = initial altitudeWhen thrust is applied, the following equation is used:y = ½ * (aburner – agravity) * t2 + vi * t + yiaburner = constant acceleration upward due to thrustagravity = constant acceleration due to gravity on a lunar(see Acceleration for sample values)Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

29 Feature Model: Feature Relationship DiagramFeature Relationship Diagram – Landing PhaseMandatory: The Lunar Lander must continually read altitude from the Landing Radar and relay that data to Houston with less than 500 msec of latency. Astronauts must be able to control the descent of the Lunar Lander using manual control on the descent engine. The descent engine must respond to control commands in 250msec, with or without a functioning DSKY…Optional/Variant: Lunar Lander provides the option to land automatically or allow the crew to manually steer the spacecraft.Quality Requirements:Real-time requirements: The thrusters and the descent engine must be able to respond to commands from the computer system in real-time.Fault tolerance: Lunar Lander must be able to continue in its flight-path even when the main computer system (Primary Navigation Guidance & Control) goes down. Lunar Lander must be able to maintain system altitude even when one of the thrusters and propellant supplies goes down in the Reaction Control System.Describes overall mission operations of a systemDescribes major features and decompositionSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

35 Reference RequirementsMandatoryMust display the current status of the Lunar Lander (horizontal and vertical velocities, altitude, remaining fuel)Must indicate points earned by player based on quality of landingOptionalMay display time elapsedVariantMay have different levels of difficulty based on pilot experience (novice, expert, etc)May have different types of input depending on whetherAuto Navigation is enabledAuto Throttle is enabledMay have to land on different celestial bodiesMoonMarsJupiter’s moonsAsteroidSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.

37 Reference ArchitectureDefinition. Reference architecture is the set of principal design decisions that are simultaneously applicable to multiple related systems, typically within an application domain, with explicitly defined points of variation.Reference architectures are still architectures (since they are also sets of principal design decisions)Distinguished by the presence of explicit points of variation (explicitly “unmade” decisions)

38 Different Kinds of Reference ArchitectureComplete single product architectureA fully worked out exemplar of a system in a domain, with optional documentation as to how to diversifyCan be relatively weak due to lack of explicit guidance and possibility that example is a ‘toy’Incomplete invariant architecturePoints of commonality as in ordinary architecture, points of variation are indicated but omittedInvariant architecture with explicit variationPoints of commonality as in ordinary architecture, specific variations indicated and enumerated

About project

Feedback

To ensure the functioning of the site, we use cookies. We share information about your activities on the site with our partners and Google partners: social networks and companies engaged in advertising and web analytics. For more information, see the Privacy Policy and Google Privacy &amp Terms.
Your consent to our cookies if you continue to use this website.