Domain-Specific Software Architecture

Slides:



Advertisements
Similar presentations
Chapter 7 System Models.
Advertisements

Domain Engineering Silvio Romero de Lemos Meira
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Basic Concepts Software Architecture Lecture 3.
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
By Xiangzhe Li Thanh Nguyen.  Components and connectors are composed in a specific way in a given system’s architecture to accomplish that system’s objective.
System Modelling System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. Different.
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Domain-Specific Software Engineering (DSSE). Software Engineering Concerns  There are many of them  “Classical” software architecture research has focused.
Intro to Domain-Specific Software Engineering
CS 425/625 Software Engineering System Models
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
7M701 1 Software Engineering Software Requirements Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 5
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models September 29, 2008.
©Ian Sommerville 2000Software Engineering, 6/e, Chapter 71 System models l Abstract descriptions of systems whose requirements are being analysed.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
7M822 Software Engineering: System Models 14 September 2009.
Course Instructor: Aisha Azeem
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Domain-Specific Software Engineering Alex Adamec.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Software Engineering 8. System Models.
The Software Development Life Cycle: An Overview
Chapter 10 Architectural Design
CS 4310: Software Engineering Lecture 3 Requirements and Design.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models. System modelling System modelling helps the analyst to understand the functionality of the system and models are used to communicate with.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
An Introduction to Software Architecture
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
Basic Concepts Software Architecture. What is Software Architecture? Definition: – A software architecture is the set of principal design decisions about.
Chapter 7 System models.
Slide 1 System models. Slide 2 Objectives l To explain why the context of a system should be modelled as part of the RE process l To describe behavioural.
Architectural Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
System models l Abstract descriptions of systems whose requirements are being analysed.
Pertemuan 19 PEMODELAN SISTEM Matakuliah: D0174/ Pemodelan Sistem dan Simulasi Tahun: Tahun 2009.
CS 4310: Software Engineering Lecture 4 System Modeling The Analysis Stage.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, Hans Van Vliet, Software.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
1 Introduction to Software Engineering Lecture 1.
L8 - March 28, 2006copyright Thomas Pole , all rights reserved 1 Lecture 8: Software Asset Management and Text Ch. 5: Software Factories, (Review)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
CS 772: Global Knowledge Networks V. “Juggy” Jagannathan CSEE, West Virginia University.
Capturing the requirements  Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the.
Rational Unified Process Fundamentals Module 7: Process for e-Business Development Rational Unified Process Fundamentals Module 7: Process for e-Business.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Software Requirements: A More Rigorous Look 1. Features and Use Cases at a High Level of Abstraction  Helps to better understand the main characteristics.
Chapter 6 – Architectural Design Lecture 1 1Chapter 6 Architectural design.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Software Architectural Views By the end of this lecture, you will be able to: list and describe the views in the 4+1 view model of software architecture.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 Click to edit Master title style What is Business Analysis Body of Knowledge?
Basic Concepts and Definitions
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Chapter 6: System Models Omar Meqdadi SE 273 Lecture 6 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
 To explain why the context of a system should be modelled as part of the RE process  To describe behavioural modelling, data modelling and object modelling.
1 CEN 4020 Software Engineering PPT4: Requirement analysis.
© 2000 Franz Kurfess System Design Methods 1 CSC 205: Software Engineering I Dr. Franz J. Kurfess Computer Science Department Cal Poly.
Enterprise Architectures Course Code : CPIS-352 King Abdul Aziz University, Jeddah Saudi Arabia.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Software Engineering Lecture 4 System Modeling The Analysis Stage.
Abstract descriptions of systems whose requirements are being analysed
System models October 5, 2005.
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Software Development Process Using UML Recap
Presentation transcript:

Domain-Specific Software Architecture By Zhiying Lin

What is Domain-specific software engineering ( DSSE ) ? Agenda What is Domain-specific software engineering ( DSSE ) ? What is domain-specific software architecture ( DSSA ) ? How can DSSA be processed ? Summary.

What is DSSE ? An approach to software engineering that is characterized by extensively leveraging existing domain knowledge. example

Traditional Software Engineering Too many choices Different concepts

Architecture-Based Software Engineering How to implement? What’s the effective software architectures?

Domain-Specific Software Engineering How to implement? Reference architecture Application-specific architecture Which domain is it belong to?

What is domain-specific software architecture? Definition. A DSSA comprises: A reference architecture. A component library. An application configuration method for selecting and configuring components.

How DSSA can be processed? Stage 1. Define the Scope of the Domain Stage 2. Define/Refine Domain-Specific Concepts/Requirements Stage 3. Define/Refine Domain-Specific Design and Implementation Constraints Stage 4. Develop Domain Architectures/Models Stage 5. Produce/Gather Reusable Workproducts Recursively, iteratively, concurrently

Stage 1: Define the Scope of the Domain Define what can be accomplished -- emphasis is on the user's needs. Inputs Experts Existing systems Existing documentation (e.g. textbooks, articles)

Stage 1: Define the Scope of the Domain Outputs Block diagram of the domain of interest including inputs and outputs to the domain and high-level relationships between functional units/elements in the domain List of people's names to serve as future references or validation sources List of projects with pointers to documentation and source code List of needs to be met by applications in this domain

Stage 2: Define/Refine Domain-Specific Concepts/Requirements Similar to Requirements Analysis -- emphasis is on the problem space. Inputs Outputs from Stage 1 Selected systems Selected documentation (e.g., textbooks, articles)

Stage 2: Define/Refine Domain-Specific Concepts/Requirements Outputs Domain Models Scenarios Domain Dictionary Context Information Diagram Entity/Relationship Diagram Object Diagram Data-Flow Diagram State-Transition Diagram Functional requirements (Reference requirements) Feature model Information model Operational model

Stage 2: Define/Refine Domain-Specific Concepts/Requirements A domain model is a product of context analysis and domain analysis. Context analysis Define the boundaries of a domain and the relationship of the entities inside the domain to those outside. Domain analysis Identify, capture, and organize the domain assets. Eg customer usable, reusable

Scenarios The scenarios consist of a list of numbered, labeled scenario steps or events followed by a brief description.

Domain Dictionary The domain dictionary consists of commonly used words or phrases found in the scenarios and customer needs document (statement of work).

Context Information Diagram It describes the high-level data flow between the major components in the system. Data flow diagram difference

Entity/Relationship (ER) Diagram It describes the entity relationship in the problem domain. There are basically two types of relationships of interest: 1. Aggregation: "a-part-of" relationships 2. Generalization: "is a" relationships

Object diagram It identifies the objects in the application domain rather than in the software.

Data-Flow Diagram It focuses on the data exchanged within the system, with no notion of control.

State-Transition Diagram It describes the events and states that take place in the domain.

Functional Requirements It is a part of reference requirements. (Reference requirements are used to facilitate the mapping of the requirements for each system within a given domain to the canonical domain-specific solution) Three type: mandatory/optional/variable requirements. It defines characteristics of the problem space.

Stage 3: Define/Refine Domain-Specific Design and Implementation Constraints Similar to Requirements Analysis -- emphasis is on the solution space. Inputs Outputs from Stage 1, especially the context diagram Outputs from Stage 2, especially control and data flow diagrams, and rationale

Stage 3: Define/Refine Domain-Specific Design and Implementation Constraints Outputs Non-Functional Requirements Design Requirements Implementation Requirements

Non-Functional Requirements Eg, security, performance, reliability.

Design Requirements Eg, architecture style, user interface style.

Implementation Requirements

Stage 4: Develop Domain Architectures/Models Similar to High-Level Design --emphasis is on defining module/model interfaces and semantics. Input: The input to this stage consist of the inputs and outputs of the previous stages. Outputs A Reference Architecture

Reference Architecture What is it? Reference Architecture is the set of principal design decisions that are simultaneously applicable to multiple related systems, typically within an application domain, which explicitly defined points of variation. When to develop? Not too-early; not too-late.

Reference Architecture Reference Architecture Model Configuration Decision Diagram Architecture Schema/Design Record Reference Architecture Dependency Diagram Component Interface Descriptions Constraints and Rationale

Reference Architecture Model All designs start out with some simple abstraction based on the architecture style.

Stage 5: Produce/Gather Reusable Workproducts Eg, Implementation/collection of reusable artifacts (e.g., code, documentation, etc.). Input The interface specifications generated in Stage 4 and related artifacts from existing systems are the primary inputs to this stage. Output Reusable components and associated test cases and documentation Cross reference of components to requirements, constraints, and architecture

Summary What is Domain-specific software engineering ( DSSE ) ? The three principle concerns of the DSSE. What is domain-specific software architecture ( DSSA ) ? How can DSSA be processed ?

Reference Taylor , R.N; Medvidovic , N.; Dashofy , E.M.; , “Software Architecture: Foundations, Theory, and Practice,” Wiley, 2009. Will Tracz, “DSSA (Domain-Specific Software Architecture) Pedagogical Example”, Software Engineering Notes vol 20, no 3, Page 49-63, July 1995. Will Tracz, “Domain-Specific Software Architecture (DSSA) Frequently Asked Questions (FAQ)”, Software Engineering Notes vol 19, no 2, Page 52-57, Apr 1994. Will Tracz, Lou Coglianese, “A Domain-Specific Software Architecture Engineering Process Outline”, Software Engineering Notes vol 18, no 2, Page 40-50, Apr 1993.