Design Software

Design is the process of producing a specification for constructing something. A “logical design” focuses on a system's behavior, which may include details of external interfaces, but overlooks many of the internal workings of the system. A logical design is different from a requirements specification in that a design begins to address how requirements are accomplished. It need not (should not) reiterate those requirements.

A design needs to precisely specify what the system does, however the inputs and outputs, and the transformations or algorithms that are relevant to the application. These may appear in the system's requirement. The design makes decisions about how the requirements are to be implemented. If the requirements contain algorithm specifications or procedures, the design addresses the form these will take in the system. The design will specify components which provide these algorithms or procedures. A logical design is merely an abstraction of the system, with many details left out. In a logical design many decisions about implementation are postponed, in order to create a first-cut design that can be understood and verified by domain experts, and serve as the basis for a prototype. There is really no other qualitative or substantive difference between logical and detailed system designs, except the level of abstraction and postponement of decisions which hinge on detailed design analysis and technology choices. A logical design may therefore be viewed as a model, since it describes a hypothetical and simplified implementation. Most projects employ a “detailed design” phase prior to coding. In a detailed design, features and terminology should match actual components and constructs in the real system to be built, and for this reason a detailed design is sometimes referred to as a “physical design.” In contrast, only the behavior of the major components of a logical model need match the actual system. A detailed design begins with a specification of the actual top-level physical architecture of the planned system. A detailed design specification must also include decisions on issues that are postponed in a logical model; in a detailed design, no major issues are postponed. The level of detail to be included in the logical and detailed design—and even whether to separate these tasks or combine them—is a critical decision. It has been my experience that if a proof-of-concept and technology evaluation prototype is developed during the logical design phase, the knowledge gained can be used to produce a highly complete detailed design, and drastically reduce risk for the project.


—A Universal Modeling Language We are fortunate that there has finally been a convergence in the various object oriented system modeling notations. Universal Modeling Language (UML), which has rapidly become the accepted standard for specifying object-oriented systems, defines a set of diagrammatic conventions for representing virtually every aspect of a system. The different kinds of diagrams specified by UML are:

Use Case Diagram

Identifies actors and the functions (use cases) they perform in a diagrammatic manner. Useful for showing the roles users play in a system, in terms of which use cases they interact with. Appropriate for giving an overview of work processes.

Class Diagram

Identifies interfaces and classes, their attributes and operations (i.e., methods), and the cardinal, compositional, and derivational relationships between them. Most applications will have a core object model expressed with class diagrams. In a database application, certain classes will be labeled persistent.

Sequence Diagram, Collaboration Diagram

Time-based diagramming techniques to show the messaging behavior of a system. A sequence diagram is a two dimensional chart showing the flow of messages between objects versus time. A collaboration diagram does not impose a two-dimensional organization, but identifies the sequence of message flows by assigning them numbers that increase with time. A collaboration diagram has somewhat the appearance of a data flow diagram, and can be used effectively to give a high-level view of what is happening in a system. Often object instances will be represented instead of classes, to show a “typical” scenario.

Package Diagram

Shows system partitioning. This is directly applicable to a Java application, since Java has a very analogous package construct. This is perhaps the hardest diagram to do right, although on the surface it looks like the simplest kind of Universal Modeling Language diagram. The challenge is that in many systems—even some well designed ones—everything uses everything, and one can end up with a package diagram that has lines between every component.

Implementation Diagram

Similar to a class diagram, but for large-grain components. This can be used to show communication between large-grain components, such as a server object and clients. It can also be used to show how a software system is configured or deployed, in terms of which components reside in which machines.

Activity Diagram, Statechart Diagram

State-based diagramming techniques for showing concurrent behavior. These are very useful for specifying aspects of a design that uses multithreading. Let’s now look at what goes into a Java design, and which of these modeling diagrammatic formats can help.

Extract from "Advanced Java Development for Enterprise Application" written by Clifford J. Berg Published by Prentice Hall PTR New Jersey 1998