DARE D omain A nalysis and R euse E nvironment

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

2. 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

3. 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

4. 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.

5. Recognize Analyze variabilities Variabilities, commonalties commonalities Generic Architecture varied varied varied varied commonalities

6. 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

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

8. Tools for producing parts of the book: • A form based interfaceFor acquiring general domain information from experts • A graphical architecture editorRecording 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). • Creating and recording generic architectures • A feature tableFor summarizing system commonalities and variabilities • For recording decision about commonalities and variabilities in systems based on generic architecture

9. Tools for producing parts of the book (cont): • Text analysis toolsFor 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 glossary, bibliography, index and appendices For collecting and organizing reference information

10. Cluster editor screen

11. DARE system description form

12. DARE system feature table screen

13. DARE – architecture editor

14. DARE – table of contents

15. Domain sources Created and updated continuously during Domain Analysis

16. 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

17. 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 tool Provides navigation support to browse in the domain book and for tracing outputs & inputs

18. The DARE – COTS implementation Dare tool had 2 prototypes, they found them very slow to develop environment as time and project resources became short. 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

19. 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)

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

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

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

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

24. 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

25. 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

26. References • Dr. Ruben Prieto-Diaz, Dr. Bill Frakes, Mr. B.K Gogia (1998): DARE: Domain analysis and reuse environment, Annals of Software Engineering 5 125-141 • 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 • http://www.cs.umaine.edu/~ftp/wisr/wisr7/papers/frakes/frakes.html