DOC PREVIEW
UT EE 382V - Using Design History

This preview shows page 1-2-22-23 out of 23 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1USING DESIGN HISTORYBaykal Cakici, Imranul IslamOutline A Process for Consolidating and Reusing Design Knowledge Software Change Through Design MaintenanceA Process for Consolidating and Reusing Design KnowledgeGuillermo Arango, Eric Schoen, and Robert PettengillPresenter: Imranul IslamOverview Motivation Applications Strategy Books Contents of Books Evolution of Books Technology Book Structures Example 1 Composition of Design Rationale Example 2 Tool Environment Conclusions2Why Consolidate Knowledge? Design evolution and maintenance is the dominant activity. Industry data suggests that design evolution accounts form 70% to 90% of the cost of a software system. The lack of understanding of the existing implementations account for most of the risks involved in software development. The authors observed that one to two thirds of the evolution costs can be traced back to designer’s and maintainers lack of understanding of the consequences of incremental change.ApplicabilityThe projects in which consolidation may be used: Systems inherently difficult to understand Long-lived systems Systems customized for different applications Products with strict organizational constraintsThe Projects of this paper: Design cycles of 6 to 12 months The designs are highly constrained Embedded software Lifespan of 20 years High cost of maintenanceStrategyDomain AnalysisTechnology booksToolsStrategy (Cont.) Domain Analysis Techniques to consolidate critical analysis and design decisions for product families; the knowledge is not really product specific. Technology Books Representation of reusable information in structured form. Tools Devices for facilitating information reuse. The authors benefited from the strategywith minimal computer support. They observed that reuse of analysis and designs is more useful than reuse of software.3Technology Books They are analogous to engineering handbooks. They consolidate the best knowledge. Their information is narrowly defined. Solutions to a complex design problem draw from different domains. Technology books support domains specific to a certain generation of a product family. An embedded system of 32K lines of codemay produce 10 technology books. These are object oriented databases Relations with well-defined semantics are present They make the book navigable so that the information it contains can be reasoned about. Product Books They consolidate knowledge specific to individual system instances. They include specialized versions of analyses drawn from technology books. They also include histories of deliberations.The process of consolidation Define a language for the problem description. Produce formal models of the solutions to the problem. Demonstrate that the formal model explains our system. Identify good designs that map solutions to the selected implemented technology. Explicitly specify issues, assumptions, constraints, and dependencies in the designs. Explicitly show how the reusable software modules relate to the designs.Technology books collect and organize the result of this process.Contents of a Technology BookTechnology books contain: Analytical models of classes of solutions. Language definitions: more than the usual definition of terms. Computational design models for these analyses. Implementation of these designs. Explanations Justify the implementations in terms of designs, and the designsin terms of the underlying analytical model. As formal as mathematical proofs.4Technology Book Structures The books use a number of tags. The tags represent a careful compromise between usability and formality. Semantic tags identify, for example, issues, definitions, and design decisions. Syntactic tags identify, for example, authors, equations, and enumerations. Information is stored in typed nodes and in relation between nodes. A typical node may include encapsulated documents or other information fragments. The information nodes are organized into taxonomies according to their types. The major hierarchies include project entities, work product, resources, and analyses. The relationships are organized into a taxonomy based on their semantics and their use in building blocks. The general categories of relations include: history, derivation, use, justification, and ownership.Why Recording Analytical Models is important? Recovering a mathematical model governing a DSP task from 12K lines of assembly code took two scientists months. Sometimes synthesizing models may become as difficult as proving theorems in physics and mathematics. This high cost of recovering critical knowledge motivates formalizing it.Evolution of the Communication Medium Informal documentation Documentation is paper based. First technology books were actual books. The strength of this approach not based on technology, but the methodology. Structured Documentation Semiformal approach using template documents and commercial document preparation systems.Structured Documentation The engineers stored information in tagged documents for easy identification and reuse. Typical tags include: requirement, analysis, issue, and software module. Encoded dependencies between related paragraphs using cross-references. Paragraphs were also tagged to communicate type of information such as OC for output constraints, and AS for assumptions. Proved to be a powerful educational and technology transfer mechanism.5On-line RepositoryThe repository is an ObjectStore database.The paragraphs from the structured documentations became objects for the repository.There were tools to parse the documentation to extract information.Interactive tools navigated relationships which included classifications, and IBIS like deliberation networks.Final stage of the evolution is the suite of RADIO tools which is discussed later.Example 1Example 1(Cont.)Composition of Design Rationales How do the changes in data representation from floating point binary affect system performance?6Design Rationales Rationales that are indirect: Design history Trace of deliberations and negotiations Traces of work product developments Formal Rationales Basic principles, assumptions, and analytical derivations.Tool Environment RADIO An environment to access


View Full Document

UT EE 382V - Using Design History

Documents in this Course
Load more
Download Using Design History
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Using Design History and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Using Design History 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?