DARE Domain Analysis and Reuse Environment סמינר: נושאים מתקדמים בהנדסת תכנה מרצה: ד"ר איריס ריינהרץ- ברגר סמסטר א', תשס"ז אהרוני ענת ברזני ערבה.

Slides:



Advertisements
Similar presentations
1 9 Moving to Design Lecture Analysis Objectives to Design Objectives Figure 9-2.
Advertisements

Systems Development Environment
Chapter 22 Product Line Engineering Week 1 CIS 673.
© 2005 by Prentice Hall Appendix 2 Automated Tools for Systems Development Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F.
Lecture 1 Introduction to the ABAP Workbench
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
Copyright 2002 Prentice-Hall, Inc. Chapter 4 Automated Tools for Systems Development 4.1 Modern Systems Analysis and Design Third Edition.
1 SWE Introduction to Software Engineering Lecture 22 – Architectural Design (Chapter 13)
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Copyright 2002 Prentice-Hall, Inc. Chapter 4 Automated Tools for Systems Development 4.1 Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer.
Application architectures
Requirements Analysis Concepts & Principles
1 IS 4420 Database Fundamentals Chapter 2: Database Development Process Leon Chen.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Supplement 02CASE Tools1 Supplement 02 - Case Tools And Franchise Colleges By MANSHA NAWAZ.
Course Instructor: Aisha Azeem
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 Tools of Software Development l 2 types of tools used by software engineers:
© 2005 by Prentice Hall Appendix 2 Automated Tools for Systems Development Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F.
Application architectures
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
MDC Open Information Model West Virginia University CS486 Presentation Feb 18, 2000 Lijian Liu (OIM:
Appendix 2 Automated Tools for Systems Development © 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 2 Slide 1.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
Lesson 7 Guide for Software Design Description (SDD)
INFORMATION SYSTEM APPLICATIONS System Development Life Cycle.
Requirements Analysis
Systems Life Cycle DESIGN STAGE
Implementation Yaodong Bi. Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute.
Chapter 7 Structuring System Process Requirements
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
2131 Structured System Analysis and Design By Germaine Cheung Hong Kong Computer Institute Lecture 2 (Chapter 2) Information System Building Blocks.
REUSE-Re-Engineering The Software Process By Venkat Praveen Medikonda.
Copyright Prentice Hall, Inc. 1 Computers: Information Technology in Perspective, 11e Larry Long and Nancy Long Chapter 11 Developing Business Information.
Chapter 9 Moving to Design
Chapter 7 System models.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
1 Introduction to Software Engineering Lecture 1.
Computing and SE II Chapter 9: Design Methods and Design Models Er-Yu Ding Software Institute, NJU.
Design Methods Instructor: Dr. Jerry Gao. Software Design Methods Design --> as a multistep process in which we design: a) data structureb) program structure.
CASE (Computer-Aided Software Engineering) Tools Software that is used to support software process activities. Provides software process support by:- –
Copyright 2002 Prentice-Hall, Inc. Chapter 4 Automated Tools for Systems Development 4.1 Modern Systems Analysis and Design.
Chapter 4 Automated Tools for Systems Development Modern Systems Analysis and Design Third Edition 4.1.
Software Reuse Course: # The Johns-Hopkins University Montgomery County Campus Fall 2000 Session 4 Lecture # 3 - September 28, 2004.
NURHALIMA 1. Identify the trade-offs when using CASE Describe organizational forces for and against adoption of CASE tools Describe the role of CASE tools.
Application architectures Advisor : Dr. Moneer Al_Mekhlafi By : Ahmed AbdAllah Al_Homaidi.
Final Review Systems Analysis and Design in a Changing World, 4th Edition 1 Final Review u Chapters 1-6, 8-10, 13, 14, 15 u Multiple choice, short answer,
CASE (Computer-Aided Software Engineering) Tools
Systems Analysis and Design in a Changing World, Fourth Edition
DARE: Domain analysis and reuse environment Minwoo Hong William Frakes, Ruben Prieto-Diaz and Christopher Fox Annals of Software Engineering,
Appendix 2 Automated Tools for Systems Development
Modern Systems Analysis and Design Third Edition
Architecture Concept Documents
Software Specification Tools
Computer Aided Software Engineering (CASE)
Modern Systems Analysis and Design Third Edition
Architecture Components
Business System Development
Abstract descriptions of systems whose requirements are being analysed
Tools of Software Development
Chapter 4 Automated Tools for Systems Development
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Modern Systems Analysis and Design Third Edition
Chapter 5 Architectural Design.
Modern Systems Analysis and Design Third Edition
Requirements Document
Modern Systems Analysis and Design Third Edition
Presentation transcript:

DARE Domain Analysis and Reuse Environment סמינר: נושאים מתקדמים בהנדסת תכנה מרצה: ד"ר איריס ריינהרץ- ברגר סמסטר א', תשס"ז אהרוני ענת ברזני ערבה

Domain Engineering DARE supports the following two phases: Domain analysis The activity of identifying and documenting the commonalities and variabilities in related software systems in a domain Domain implementation Usage of acquired knowledge in order to develop reusable assets for the domain (reusable components, application generators) DARE support creation of reusable assets repository

DARE -Supports domain analyst carrying out well defined domain analysis method -Provides Method and tools that help users perform domain analysis -Supports the collection of domain assets in a database and provides a library search facility. -Producing a repository of reusable assets for the domain

Primary Goal Creation of a generic architecture that describes architectural elements and their relationships, for family of systems. Support systematic and repeatable domain analysis process uses top-down and bottom- up strategy and automate it.

commonalities variabilities RecognizeAnalyze commonalities Generic Architecture varied Variabilities, commonalties

The Domain Book - the product of domain analysis.  To support creation of generic architecture, DARE uses a book metaphor  Contains all domain analysis inputs, outputs and supporting material  Domain book captured domain information from * domain experts * domain documents * code from systems in the domain The domain book provides a detailed specification of the domain

Domain Book User manuals, Requirements documents, Design documents etc. Provide descriptions of systems in the domain and their architectures Will be analyzed to discover architectural information about systems in the domain and provide reusable code components

Tools for producing parts of the book: A form based interface For acquiring general domain information from expertsA form based interface A graphical architecture editor Recording systems architectures (system may have several architectural representations – DFD, ERD, STRUCTURE CHARTS, OBJECT D., STATE D. FLOW CHARTS, LAYER OR ONION D. and MIXTURES OF THIS).A graphical architecture editor Creating and recording generic architectures A feature table For summarizing system commonalities and variabilitiesA feature table For recording decision about commonalities and variabilities in systems based on generic architecture

Tools for producing parts of the book (cont) : Text analysis tools For extracting a domain vocabulary from text sources A clustering tool A graphical way for analyzing and manipulating the similarities between different words and phrases within the domain to form the critical categories of words an phrases. A clustering tool A glossary, bibliography, index and appendices For collecting and organizing reference informationA glossary, bibliography, index and appendices

Cluster editor screen

DARE system description form

DARE system feature table screen

DARE – architecture editor

DARE – table of contents

Domain sources Created and updated continuously during Domain Analysis

Domain book include:  All domain sources  The results of vocabulary analysis  The result of architecture analysis, include code analysis  Summary information (glossary, a bibliography, user index, appendices Recording analyses and design decisions  generic architecture  source for repository of reusable components  The domain book organizes all domain information and become the product of domain analysis  Once complete, the domain book provides a detailed specification of the domain

The DARE-COTS tool Provides navigation support to browse in the domain book and for tracing outputs & inputs Domain book solves two vexing problems: What should the output of domain analysis be? The output of domain analysis is a domain book What are the criteria for analysis completion? The process is complete when all section of the domain book are written

The DARE – COTS implementation Implement third prototype using COTS and freeware  Domain book- In control  Source document – MS word  Text analysis – Concordance  Expert forms – MS word  Architecture – Inspiration  Stemming – Unix Tools  Code analysis – Unix tools Dare tool had 2 prototypes, they found them very slow to develop environment as time and project resources became short.

Organization decide to analyze one of its domain:  at least 1 analyst  domain experts: provide descriptions of systems in the domain and architectures  Source code from systems  Documentations for systems in the domain (user manuals, requirements, documents, design documents, and so on)

Experts: enter information by dare input forms. architectural information, reusable code components documentation: record and analysis in the domain book Source Code: record and analysis in The domain book Dare text analysis tools to extract terms & phrases Dare cluster editor & facet table tool to create facets Low Level Automated analysis code High Level Facet table Common & variable and system architecture Record & analysis Check and refine the system architecture System feature table : summary information about commonalities and variabilities

Facet table System feature table Code structures Generic architecture for the Domain Generic Feature table characterizing the stable common aspects and allowed variabilities Repository of reusable assets Source documents characterizing aspects of systems conform System built Software components implementing aspects of systems Placed

Generic architecture Feature table Repository of reusable assets Vocabulary BASE Domain implementation

Dare User Population DARE Write requirements for new systems in domain Specify architectures for New Systems in the Domain Look For Reusable components and can add new assets Asses Impact of changes on requirements Use domain models and information to create reusable parts and generators for domain Use domain models as a starting point for new domain analysis

DARE METHOD - conclusion  DARE Provides a systematic and organized method in order to build domains, but not for applications  Provide only knowledge for creating new applications

The CASE tool: DARE- COTS  DARE-COTS method partially based on STARS Reuse Library Process Model  STARS, FODA, ODM are insufficiently prescriptive for automation and focus on the analysis of low-level domain objects. Example: FODA provides very little guidance to the central activity of documenting generic architectures STARS method places too much emphasis on the bottom-up analysis of domain text. DARE: More highly perspective: information from experts

References Dr. Ruben Prieto-Diaz, Dr. Bill Frakes, Mr. B.K Gogia (1998): DARE: Domain analysis and reuse environment, Annals of Software Engineering Dr. Ruben Prieto-Diaz, Dr. Bill Frakes, Christopher Fox (1997): DARE- COTS- Domain analysis Support Tool, Proceedings.-17th- International-Conference-of-the-Chilean-Computer-Science- Society-Cat.-No.97TB100194, 73-7 Dr. Ruben Prieto-Diaz, Dr. Bill Frakes, Mr. B.K Gogia (1992): DARE: Domain analysis and reuse environment, phase 1 final report