Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Design Engineering 1
  2. 2. Fundamental Concepts  abstraction—data, procedure, control  architecture—the overall structure of the software  modularity—compartmentalization of data and function  Functional independence—single-minded function and low coupling  hiding—controlled interfaces  refinement—elaboration of detail for all abstractions  Refactoring—a reorganization technique that simplifies the design 2
  3. 3. Data Abstraction Abstraction is the intellectual tool that allows us to deal with concepts apart from particular instances of those concepts. During requirements definition an design, abstraction permits separation of the conceptual aspects of a system from the implementation details 3
  4. 4. Procedural Abstraction open details of enter algorithm implemented with a "knowledge" of the object that is associated with enter 4
  5. 5. Three widely used abstraction mechanism in s/w design are functional abstraction data abstraction control abstraction. 5
  6. 6. Functional Abstraction Functional Abstraction  6 It involves the use of parameterized subprograms. The ability to parameterize a subprogram and to bind different parameter values on different invocations of the subprogram is a powerful abstraction mechanism. Data Abstraction It involves specifying a data type or a data object by specifying legal operations on objects. Representation and manipulation details are suppressed.  
  7. 7. Control Abstraction  It is the third commonly used abstraction mechanism in software design. Control abstraction is used to state a desired effect without stating the exact mechanism of control. IF statements and WHILE statements in modern programming languages are abstractions of machine code implementations that involve conditional jump instructions. A statement of the form “for all I in S sort files I” leaves unspecified the sorting techniques, the nature of S, the nature of the files, and how “for all I in S” is to be handled 7
  8. 8. Architecture “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a] Structural properties. This aspect of the architectural design representation defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods Extra-functional properties. achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics. Families of related systems. The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability to reuse architectural building blocks. 8
  9. 9. Modular Design e se t b i d e se t c a g , e se t f x. . ai r o u , ai r o h n e ai r o i l . Modularity is the way of defining the system as a collection of well defined, manageable units with well defined interfaces among the units. Desirable properties of a modular system include: •Each module is a well defined subsystem that is potentially useful in other applications •Each module has a single, well defined purpose. •Modules can be separately compiled and stored in a library •Modules can use other modules. •Modules should be easier to use than to build •Modules should be simpler from the outside than from the inside. 9
  10. 10. Modularity: Trade-offs What is the "right" number of modules for a specific software design? module development cost cost of software module integration cost optimal number of modules 10 number of modules
  11. 11. abstraction architecture modularity functional independence hiding refinement refactoring Functional Independence COHESION - the degree to w hich a module performs one and only one function. COUPLING - the degree to w hich a module is "connected" to other modules in the system. 11
  12. 12. Coupling Coupling is the measure of the degree of interdependenc between modules. Two modules with high coupling are strongly interconnected and thus, dependent on each oth •Content/Pathological Coupling : (worst) When a module uses/alters data in another •Control Coupling : 2 modules communicating with a control flag (first tells second what to do via flag) •Common/Global-data Coupling : 2 modules communicating via global data •Stamp/Data-structure Coupling : Communicating via a data structure passed as a parameter. The data structure holds more information than the recipient needs. •Data Coupling : (best) Communicating via parameter passing. The parameters passed are only those that the recipient needs. 12
  13. 13. Cohesion Coincidental Cohesion : (Worst) Module elements are 13 unrelated Logical Cohesion : Elements perform similar activities as selected from outside module, i.e. by a flag that selects operation to perform Logical cohesion Temporal Cohesion : operations related only by general time performed (i.e. initialization() or FatalErrorShutdown?()) Procedural Cohesion : Elements involved in different but sequential activities, each on different data 
  14. 14. Cohesion Sequential Cohesion : operations on same data in significant 14 order; output from one function is input to next (pipeline) Informational Cohesion: a module performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure. Essentially an implementation of an Functional Cohesion : all elements contribute to a single, well-defined task, i.e. a function that performs exactly one operation
  15. 15. Communicational Cohesion : unrelated operations except need same data or input 15
  16. 16. abstraction architecture modularity functional independence hiding refinement refactoring Information Hiding module • algorithm controlled interface • data structure • details of external interface • resource allocation policy clients "secret" a specific design decision 16
  17. 17. Why Information Hiding? reduces the likelihood of “side effects” limits the global impact of local design decisions emphasizes communication through controlled interfaces discourages the use of global data leads to encapsulation—an attribute of high quality design results in higher quality software 17
  18. 18. abstraction architecture modularity functional independence hiding refinement refactoring Stepwise Refinement open walk to door; reach for knob; open door; walk through; close door. 18 repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat
  19. 19. abstraction architecture modularity functional independence hiding refinement refactoring Refactoring  Fowler [FOW99] defines refactoring in the following manner:  "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.”  When software is refactored, the existing design is examined for  redundancy  unused design elements  inefficient or unnecessary algorithms  poorly constructed or inappropriate data structures  or any other design failure that can be corrected to yield a better design. 19