BY BART KLEIN COMPAS – A METHOD ENGINEERING APPROACH.

Slides:



Advertisements
Similar presentations
Domain Engineering Silvio Romero de Lemos Meira
Advertisements

Chapter 22 Product Line Engineering Week 1 CIS 673.
Modelling Class T05 Conceptual Modelling – Domain References: –Conceptual Modeling of Information Systems (Chapters 1.2.1, 2, 3) –A practical Guide to.
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.
1 Introduction to Requirements Specification. 2 Outline Requirement Engineering Software Lifecycle and Software Processes.
Software IMprovement using Product LinEs Project Presentation (I) - Domain Analysis Results Liana Lisboa - PM Project: Starship Games PL.
UML CASE Tool. ABSTRACT Domain analysis enables identifying families of applications and capturing their terminology in order to assist and guide system.
Essential Software Architecture Ian Gorton CS590 – Winter 2008.
CSE 300: Software Reliability Engineering Topics covered: Software metrics and software reliability.
1 CSC-3324: Chapter 4 Title: What is a requirement? Mandatory reading: Sommerville 6, 7 th ed., Chap.: 7.
Architectural Styles, Design Patterns, and Objects Architectural Styles, Design Patterns, and Objects By Robert T. Monroe, Andrew Kompanek, Ralph Melton,
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Autonomic Software Product Lines (ASPL) Nadeem Abbas, Jesper Andersson, Welf Löwe Linnaeus University, Sweden Monday, August 23, st International.
Software Product Lines Krishna Anusha, Eturi. Introduction: A software product line is a set of software systems developed by a company that share a common.
Software Product Line Architectures (SPLA) Nipun Shah
Domain-Specific Software Engineering Alex Adamec.
Business Rules INFS 770 – KM for E-Business Professor L. Kerschberg Spring 2004.
The Double Diamond Design Process. Establish Project parameters; aims & objectives of project Recommendation of Client Confidentiality Agreement or Non-Disclosure.
CASE Tools And Their Effect On Software Quality Peter Geddis – pxg07u.
The Double Diamond Design Process. Establish Project parameters; aims & objectives of project Recommendation of Client Confidentiality Agreement or.
Ekrem Kocaguneli 11/29/2010. Introduction CLISSPE and its background Application to be Modeled Steps of the Model Assessment of Performance Interpretation.
Slide 12.1 © The McGraw-Hill Companies, CS 4310: Software Engineering Lecture 7 Systems Analysis Object-Oriented Design.
J. David Szwarcberg MSCS Candidate Graduate College of Union University Domain Engineering and Software Reuse.
Robert Tairas, Marjan Mernik, Jeff Gray Using Ontologies in the Domain Analysis of Domain-Specific Languages Workshop on Transformation and Weaving Ontologies.
SYSE 802 John D. McGregor Module 6 Session 1 Systems Engineering Analyses II.
SYSE 802 John D. McGregor Module 3, Session 3 Assignment.
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
AMA INTERNATIONAL UNIVERSITY BHARAIN SOFTWARE ENGINEERING PROJECT - SBI 302 SOFTWARE ENGINEERING PROJECT - SBI 302A SOFTWARE ENGINEERING PROJECT - SBI.
Basic Concepts Software Architecture. What is Software Architecture? Definition: – A software architecture is the set of principal design decisions about.
SOFTWARE SYSTEMS DEVELOPMENT 4: System Design. Simplified view on software product development process 2 Product Planning System Design Project Planning.
Chapter 7 Applying UML and Patterns Craig Larman
Feature-Oriented Nonfunctional Requirement Analysis for Software Product Line Mats Hofman.
Lecture 7: Requirements Engineering
Introducing Software Product Lines (SPL) Silvio Romero de Lemos Meira Eduardo Santana de Almeida
1 Introduction to Software Engineering Lecture 1.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
Component Based SW Development and Domain Engineering 1 Component Based Software Development and Domain Engineering.
ARCH-2: UML From Design to Implementation using UML Frank Beusenberg Senior Technical Consultant.
Modeling system requirements. Purpose of Models Models help an analyst clarify and refine a design. Models help simplify the complexity of information.
Object Oriented Reverse Engineering JATAN PATEL. What is Reverse Engineering? It is the process of analyzing a subject system to identify the system’s.
Software Product Line Material based on slides and chapter by Linda M. Northrop, SEI.
RUNA SEWRADJ GROUP A EXTRACTING AND MODELING PRODUCT LINE FUNCTIONAL REQUIREMENTS.
Object-Oriented Analysis and Design. Lesson 1: Introduction to Software Engineering.
A Goal Based Methodology for Developing Domain-Specific Ontological Frameworks Faezeh Ensan, Weichang Du Faculty of Computer Science, University of New.
System Context and Domain Analysis Abbas Rasoolzadegan.
Domain Classes – Part 1.  Analyze Requirements as per Use Case Model  Domain Model (Conceptual Class Diagram)  Interaction (Sequence) Diagrams  System.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
IWSFT /11/ A Layered Formal Specification of Contactless IC Card "FeliCa" Kyushu University (JAPAN) Xiaojing ZHANG, Yoichi OMORI and Keijiro.
CSCI 578 Software Architectures Exam #1 Review. Materials you are responsible for Chapters 1-8 in the text book All lecture material up to but not including.
On the design and development of program families Presented by: M. Deng and J. Zhang 4/15/2002 CSE870 Advanced Software Engineering, Spring 2002.
Developing Product Line Components Jan Bosch Professor of Software Engineering University of Groningen, Netherlands
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 9: Design Engineering Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
A Use Case Based Approach to Feature Models’ Construction Jeroen Eissens
Toward product architecture oriented requirements analysis for product line development in systems engineering Kei Kurakawa Nara Institute of Science and.
SE Seminar – IS Department Mazor Maya & Yuval Efrat December 2010 Griss, M.L.; Favaro, J.; d'Alessandro, M.;
Introduction to Embedded Systems. The embedded systems is wide and varied, and it is difficult to exact definitions or descriptions. Chapter 1 introduces.
CIS 375 Bruce R. Maxim UM-Dearborn
Software Configuration Management
Modern Systems Analysis and Design Third Edition
Component Based Software Engineering
CS 425/625 Software Engineering Architectural Design
Modern Systems Analysis and Design Third Edition
Descriptive Statistics vs. Factor Analysis
Requirements Engineering for Product Lines
SYS466 Domain Classes – Part 1.
OBJECT ORIENTED ANALYSIS AND DESIGN
Energy-Efficient Storage Systems
National University of Laos
Chapter 8, Design Patterns Introduction
Presentation transcript:

BY BART KLEIN COMPAS – A METHOD ENGINEERING APPROACH

INTRODUCTION Compas : A new approach to commonality and variability analysis with applications in computer assisted orthopaedic surgery (CAOS) (2009) Gisèle Douta MEM Research Center for Haydar Talib Orthopaedic Surgery Frank LanglotzUniversity of Bern Oscar NierstraszSoftware Composition Group University of Bern

INTRODUCTION Software reuseability more efficient way to develop software systems CompAS is an analysis method which focusses on the commonality and variability between systems in a particular field Show the evolution of features in CAOS systems over a period of several years Applied to the CAOS domain, and currently the only scientific reference.

INTRODUCTION Two different phases Phase A: Functional evolution based commonality and variability identification Gather a data source, functional system descriptions Extract a set of features Compute and build evolution matrices Identify evolution patterns Phase B: Business-oriented variation capture Gather a data source, justification of system evolution List the features that are proposed to modify and improve Define the most influential evolution factors for each feature Use the results of the two previous steps to build a taxonomy

RELATED LITERATURE Component based software development Lower development time and cost A set of prebuild, standardized software components available to fit a specific architectural style for some application domain (Capretz, Capretz & Li, 2001) Several comparable methods exist Feature oriented domain analysis FODA (Kang, Cohen, Hess, Novak & Peterson, 1990) Feature oriented reuse method FORM (Kang, Lee & Donohoe, 2002)

RELATED LITERATURE Phase A Deliverable: Evolution matrix Lanza (2001) combines software visualization and software metrics into the evolution matrix Phase B: Focus on gathering non-functional requirements An attribute of or a constraint on a system (Glintz, 2007)

PROCESS DELIVERABLE DIAGRAM Phase A: functional evolution based commonality and virability identification Main deliverables Evolution matrices Commonality and virability report

EXAMPLE PHASE A Example of an evolution matrix (knee family) Five metrics are encoded: x- and y-axis, width, height and colour

EXAMPLE PHASE A Deduced from the evolution matrix Part of a commonality and variability report Evolution pattern names: Red Giant: A feature that keeps on being very wide over time, a common feature White Dwarf: Used to be a certain width, slowly decreases, a common feature decreasing to variable Idle: remains small over time, a rarely used variation

QUESTIONS?