2.3 Software design  (Page 5/5)

Behavioral descriptions (dynamic view)

The following notations and languages, some graphical and some textual, are used to describe the dynamic behavior of software and components. Many of these notations are useful mostly, but not exclusively, during detailed design.

• Activity diagrams: used to show the control flow from activity (“ongoing non-atomic execution within a state machine”) to activity.
• Collaboration diagrams: used to show the interactions that occur among a group of objects, where the emphasis is on the objects, their links, and the messages they exchange on these links.
• Data flow diagrams (DFDs): used to show data flow among a set of processes.
• Decision tables and diagrams: used to represent complex combinations of conditions and actions.
• Flowcharts and structured flowcharts: used to represent the flow of control and the associated actions to be performed.
• Sequence diagrams: used to show the interactions among a group of objects, with emphasis on the time-ordering of messages.
• State transition and state-chart diagrams: used to show the control flow from state to state in a state machine.
• Formal specification languages: textual languages that use basic notions from mathematics (for example, logic, set, sequence) to rigorously and abstractly define software component interfaces and behavior, often in terms of pre- and post-conditions.
• Pseudocode and program design languages (PDLs): structured-programming-like languages used to describe, generally at the detailed design stage, the behavior of a procedure or method.

Software design strategies and methods

There exist various general strategies to help guide the design process. In contrast with general strategies, methods are more specific in that they generally suggest and provide a set of notations to be used with the method, a description of the process to be used when following the method and a set of guidelines in using the method. Such methods are useful as a means of transferring knowledge and as a common framework for teams of software engineers.

General strategies

Some often-cited examples of general strategies useful in the design process are divide-and-conquer and stepwise refinement, top-down vs. bottom-up strategies, data abstraction and information hiding, use of heuristics, use of patterns and pattern languages, use of an iterative and incremental approach.

Function-oriented (structured) design

This is one of the classical methods of software design, where decomposition centers on identifying the major software functions and then elaborating and refining them in a top-down manner. Structured design is generally used after structured analysis, thus producing, among other things, data flow diagrams and associated process descriptions. Researchers have proposed various strategies (for example, transformation analysis, transaction analysis) and heuristics (for example, fan-in/fan-out, scope of effect vs. scope of control) to transform a DFD into a software architecture generally represented as a structure chart.

Object-oriented design

Numerous software design methods based on objects have been proposed. The field has evolved from the early object-based design of the mid-1980s (noun = object; verb = method; adjective = attribute) through OO design, where inheritance and polymorphism play a key role, to the field of component-based design, where meta-information can be defined and accessed (through reflection, for example). Although OO design’s roots stem from the concept of data abstraction, responsibility-driven design has also been proposed as an alternative approach to OO design.

Data-structure-centered design

Data-structure-centered design (for example, Jackson, Warnier-Orr) starts from the data structures a program manipulates rather than from the function it performs. The software engineer first describes the input and output data structures (using Jackson’s structure diagrams, for instance) and then develops the program’s control structure based on these data structure diagrams. Various heuristics have been proposed to deal with special cases—for example, when there is a mismatch between the input and output structures.

Component-based design (cbd)

A software component is an independent unit, having well-defined interfaces and dependencies that can be composed and deployed independently. Component-based design addresses issues related to providing, developing, and integrating such components in order to improve reuse.

Other methods

Other interesting but less mainstream approaches also exist: formal and rigorous methods and transformational methods.

References:

http://en.wikipedia.org/wiki/Software_design, http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-171Fall2003/CourseHome/,http://www.cs.cornell.edu/courses/cs501/2008sp/, http://www.sei.cmu.edu/,http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7/,http://www.ee.unb.ca/kengleha/courses/CMPE3213/IntroToSoftwareEng.htm, http://www.developerdotstar.com/mag/articles/reeves_design.html,http://trace.wisc.edu/docs/software_guidelines/software.pcs/spec_gl.htm, etc...