Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!ajpo!eberard From: eberard@ajpo.sei.cmu.edu (Edward Berard) Newsgroups: comp.sw.components Subject: Re: Non-Code Software Components Summary: clarifications Message-ID: <612@ajpo.sei.cmu.edu> Date: 18 Oct 89 20:22:01 GMT References: <598@ajpo.sei.cmu.edu> Lines: 236 Don Dwiggins (dwiggins@atsun.a-t.com) writes: > OK, I'll pick up the thread with a request for setting the parameters. It > seems to me that the interpretation of the terms "analysis" and "design" is > less than well settled. Design, for example, can occur in several settings > and at several levels; it would be useful to distinguish among them, and > discuss reusability in the different contexts. If you study software engineering technology, and software engineering history, several things become apparent: - The development part of the software life-cycle is basically a series of transformations. Specifically, if a non-technical (in the software engineering sense) user could interact directly with the computer, without having to actually develop an application, there would be no need for software engineers for many everyday applications. However, users currently have to go through intermediaries (i.e., software engineers and their managers). The job of these intermediaries is to help formulate, clarify, and translate the users' requests into a form which the computer can understand. This formulation, clarification, and translation process is what we often refer to as the development part of the software life-cycle. Traditionally, (systems, requirements, and/or user) analysis was the first step in this transformation process. The idea was to help both the client and the software engineers better understand the problem to be solved. One of the outputs of the analysis process was a description of the system, _as_ _it_ _would_ _appear_ _to_ _the_ _client_. Equally traditionally, the process which followed analysis was referred to as design. The usual concept was that designers implemented the internal (software) architecture of the system. Designers were supposed to discuss things in terms of modules (e.g., subroutines), and other technical (from the software engineering perspective) issues. Design was traditionally followed by programming (coding). - Even in the "good old days" people had trouble differentiating between analysis and design. When did analysis stop? When did design begin? How do I systematically take the output of the analysis process and use it as the input to the design process? Some people began to realize that the boundaries between life-cycle phases really were fuzzy. - Some people realized that the development of a software product was more a continuous process than it was a series of discrete steps. Some even realized that the distinction between the analysis, design, coding, and testing phases were purely artificial, and were very often used by management as tools to control a software development effort. If you view a software development effort as a huge monolithic entity, that means that you may have to invest large sums of resources, for an extended period of time, with very little idea of what the final results will be. On the other hand, if you introduce phases into the life-cycle, and specify deliverables for each phase, you have much more control over the overall process. You can make "mid-course adjustments," "go/no go" decisions at the end of each phase, spot trouble earlier, and generally have a much better idea of actual progress. Please note, however, methods, methodologies, deliverables, well-defined phases, and the mere presence of management do not guarantee success. - Others have observed that analysis and design, for example, even take place in the maintenance phase of the software life-cycle. - There are many different overall approaches to the software life-cycle, e.g., waterfall, spiral, b-model, and recursive/parallel. (In some of my classes, I show people at least six different approaches.) In object-oriented software engineering, a very commonly used approach is recursive/parallel, sometimes referred to as "analyze a little, design a little, implement a little, test a little." Yes, this means that analysis, design, and implementation may take place at many different points during development. - Depending on how you view the terms: - Analysis and design are precursors to coding, and do not involve coding. - Each time a single character of source code is changed you are actually re-designing. (Notice that software maintenance differs from hardware maintenance in this respect. Specifically, hardware maintenance may involve replacing a defective part with an identical part, whereas software maintenance requires the introduction of different parts.) - Analysis may involve analysis of a piece of source code with the intent of finding a problem, or suggesting optimizations or extensions. - Et cetera ... > With regard to analysis, I have a question arising from your message. Early > on, you say that you've > > - conducted research in various aspects of software > reusability (e.g., domain analysis, ...... > > Later, you say > > This means that domain analysts (i.e., those charged with identifying, > documenting, and configuration managing reusable components) must > constantly balance the size of a component against its potential for > reuse. They must find both the granularities of components, and the > mix of components, which will provide the highest return. > > I had the impression that "domain analysis" was the sort of thing that would > be done for a class of applications intended to run in a common domain, to > identify common classes of data, algorithms, report types, etc. Your > characterization of the task of a "domain analyst" seems to be more like > that of a database administrator for a component database. Where am I > confused? I suspect it is in your interpretation of the word "component." I have no problem with "components" being "common classes of data, algorithms, report types, etc." However, I think we can better define what we are after in domain analysis. First, we need some definitions: - "An investigation of a specific application area that seeks to identify the operations, objects, and structures that commonly occur in software systems within this area." -- Dan McNicholl - "Systems analysis states what is done for a specific problem in a domain while domain analysis states what can be done in a range of problems in a domain. ... A domain analysis is only useful if many similar systems are to be built so that the cost of the domain analysis can be amortized of all the systems. "The key to reusable software is captured in domain analysis in that it stresses the reusability of analysis and design, not code." -- Jim Neighbors - "A horizontal domain analysis studies a number of different systems across a variety of applications." -- Grady Booch - "A vertical domain analysis studies a number of systems intended for the same class of applications." -- Grady Booch We can add some more clarifications: - Domain analysis is _not_ a software life-cycle activity. It has a beginning, but, usually, never stops. It runs in parallel with the life-cycles of many software products. - Domain analysts must identify reusable items in their application domains, however they will usually be able to classify what they find as: - reusable, and highly domain-specific, i.e., these items will have a very low potential for reuse outside of the defined domain. These items are usually in the minority of the items encountered. - reusable, and not specific to the defined domain, i.e., these items will have at least some "horizontal reuse potential." These items are usually in the majority of the items encountered. - Unfortunately, many people tend to focus on only low-level items (e.g., source code, object code, algorithms, data) during domain analysis. Much larger payoffs are achieved when higher-level items (e.g., plans, standards, design products, analysis products) are also considered. - A domain analyst must not only be familiar with the specific domain, he or she must also be familiar with what they are supposed to be looking for (e.g., objects and classes), he or she must have excellent abstraction skills, and he or she must be well-versed in software reusability technology. - In functional domain analysis, we are looking for things that fit a functional viewpoint of systems in our domain. That is, we are looking for reusable functions, libraries of functions, and, in general, items which will be useful to those software engineers who have taken a functional decomposition approach to the software life-cycle. - In object-oriented domain analysis, we are looking for objects, classes, systems of objects, and, in general, items which will be useful to software engineers taking an object-oriented approach to the software life-cycle. A domain analyst must do much more than simply point to an item and say that the item is reusable. There is much more work to be done. Without going into a full-blown course on domain analysis, some of the things a domain analyst can be expected to do are: - Concisely and precisely define the application domain. - Identify a representative sample of applications which span the domain, and use this sample to begin to extract potentially reusable items. - Accurately name and document each reusable item. Of course this brings up issues like nomenclature and definitions. - Clean up, parameterize, and otherwise refine potentially resuable items. - Identify additional reusable items suggested by those already identified. - Store and retrieve both the reusable items, and information associated with the items. - Develop guidelines for the (re)use of the reusable items. - Demonstrate reuse using the reusable items and the guidelines. - Interact with all those involved in the software engineering process, e.g., requirements analysts, testers, designers, coders, software quality assurance personnel, managers, and maintenance personnel. The specifics of these interactions are too involved to go into in this short message. There is much more I could say. (Yes, I do teach a course on the subject.) But this message is already too long. Thanks for listening. -- Ed Berard (301) 353-9652