This action might not be possible to undo. Are you sure you want to continue?
• Basic terminologies in software design • Fundamental issues in design
– General definition of design
• “… the process of applying various techniques and principles for the purpose of defining a device, a process, or a system in sufficient detail to permit its physical realization.”
• To produce a model or representation depending on the SRS document, that will later be built
Engineering or Art?
Software Design • Design activities having two important parts – High-level design • Outcome is program structure or software architecture – Detailed design • The data structure and the algorithms of different modules are designed Question How to distinguish a good design from a bad design? .
Software Design – Good design is not accomplished by chance “The beginning of wisdom for a computer programmer is to recognize the difference between getting a program to work. and getting it right.” [Jackson] – Fundamental concepts provide the framework for “getting it right” .
Design Fundamentals – Abstraction – Refinement – Modularity – Software Architecture – Control Hierarchy – Data Structure – Software Procedure – Information Hiding .
use of abstraction also permits one to work with concepts and terms that are familiar in the problem environment… [Wasserman] • Types of abstractions – Procedural abstraction – Data abstraction .Design Fundamentals – Abstraction • Levels of detail/language used to describe a problem …notion of “abstraction” permits one to concentrate on a problem at some level of generalization without regard to irrelevant low level details.
– Different implementations of the abstraction can differ over details. may have side effects. may modify its parameters. may return a result • Procedural abstraction describes what a procedure does. ignore how to does it.Procedural Abstraction • A procedure maps from input to output parameters. one implementation can substitute others .
Data abstraction • Defining data abstractions: – Name the data type – List the operations – Give a procedural abstraction for each abstraction .
[Wirth] – Modularity • Divide software into separate components that are integrated to solve problem requirements .Design Fundamentals (cont. one or several instructions of the given program are decomposed into more detailed instructions.) – Refinement • Top-down strategy In each step. This successive decomposition or refinement of specification terminates when all instructions are expressed in terms of any underlying computer or programming language.
width.depth.Design Fundamentals (cont. fan-in • Visibility & connectivity .) – Software Architecture • The hierarchical structure of procedural components & the structure of data • Transition between analysis and design – Control Hierarchy/Program Structure • Organization of modules that implies a hierarchy of control • Metrics . fan-out.
Control Hierarchy Manager Module A Module B Module C Modu le D Module E Module K Module L Module M Module F Module G Module H Module N Module O Module P Module Q Module I Module J Module R .
data organization . sequential vector..Design Fundamentals cont. – Data Structure • Logical representation of the relationship among individual data elements • Scalar. array. hierarchical data structure – Software Procedure • Processing details of each module • Precise specification includes sequence of events. linked list. repetitive operations. decision points.
Design Fundamentals cont. – Information Hiding • Modules should be “characterized by design decisions that each hides from all others” • Modules are designed so that information within a module is inaccessible to other modules with no need for the information • Defines and enforces access constraints IEEE defines: “the technique of encapsulating software design decisions in modules in such a way that the module‟s interfaces reveal as little as possible about the module‟s inner workings.. thus each module is a „black box‟ to the other modules in the system” .
Information Hiding advantages • Leads to low coupling • Emphasizes communication through controlled interfaces • Reduces the likelihood of adverse effects • Limits the global impact of local design decisions • Results in higher quality software .
Developing a design model • To develop a complete specification of design four elements are used – Data design • This creates the data structure by converting data objects specified during the analysis phase • The data objects. attributes and relationships defined in E-R diagram provides the basis for data design activity .
Developing a design model – Architectural design: • Specifies the relationship between the structural elements of a software – Component level design • Converts the structural elements of software architecture into a procedural description of software components – Interface Design • Depicts how a software communicates with the system that interoperates with it and with the endusers .
Good Software Design • Can vary depending on the application for which it is being designed • Characteristics – Correctness : should correctly implement all the functionalities of the system – Understandability: should be easily understandable – Efficiency – Maintainability: easily adaptable to change .
that is it should use a cleanly decomposed set of modules • Should neatly arrange the modules in a hierarchy e.g.Understandability features • Should use consistent and meaningful names for various design concepts • Design should be modular. tree-like diagram .
Modularity • Take the advantage of divide and conquer principle • Problem is decomposed into modules. and make as much as possible functionally independent to each other • Reduces complexity of design solution .
Functionally independence Advantages • Performs a single task or function • Advantages: – Error Isolation: Reduce error propagation – Scope for reuse: reuse possible due to less dependency – Understandability: • Complexity is reduced and can be understood in isolation .
Clean decomposition • Modules should be less dependent of each other satisfying the property like high cohesion and low coupling M1 M1 M2 M3 M4 M2 M3 M4 M5 Modular design Poor design M5 .
Cohesion • Represents how tightly bound the internal elements of the module are to one another – Measure the functional strength of a module • Tries to capture the intra-module characteristics • Gives the designer an idea about whether the different elements of a module belong together in the same module • High cohesion of a module is desired .
Request_librarian_leave . Create_member. Compute_vendor_credit.Cohesion contd. • Different classes of cohesion exist Coincidental Logical Temporal Procedural Communicational Sequential Functional Low High Coincidental : performs a set of tasks which are relate to each other very loosely Ex: Module name : Random_operations Functions: Issue_book..
Cohesion contd. salary slips. • Logical : If all elements of the module perform similar operations » Ex: Module that performs all the inputs or outputs. annual reports etc. .. » Contains a set of print functions to generate various types of output reports such as grade sheets.
Temporal : Elements are related with time and executed together. update_inventory().. place_order_on_vendor(). Modules that perform activities like “initialization”.Cohesion contd. Procedural : if the set of elements are all part of a procedure to carry out some steps to achieve an objective Ex: Order processing in a trading house Functions are : login().. loading of OS etc. print_bill(). Ex: When a machine is booted up the functions they need to do is initialization of the I/O devices. “clean up” and ”termination” are usually temporally bound. place_order(). and logout() . check_order().
Sequential : if the elements of a module form the parts of a sequence. . check_item_availability(). place_order_on_vendor(). printGradesheet() etc.. Communicational: elements that are related by a reference to the same input/output data Ex: “Print and store record” – Operate on same data but the operations are different studentRecord data is operated by the functions enterMarks().Cohesion contd. where the output from one element of the sequence is input to the next Online store: ceate_order().
.Cohesion contd. Functional: All the elements of the modules are related to performing a single function Ex: Manage employee’s payroll computeOvertime() computeWorkHours() computeDeductions() Etc...
. • Another example of functional cohesion – Managing_Book_Lending: • Functions are: – – – – Issue_book() Return_book() Query_book() Find_borrower() .Cohesion contd.
shut down etc. after. – it possesses sequential or temporal cohesion – If it needs words such as initialize. – it has temporal cohesion . next. setup. then etc.How to determine the cohesiveness? • Try to write down the sentence to describe the overall work performed by the module – If you need a compound statement to describe – it has sequential or communicational cohesion – If you need word such as first.
Coupling • Measure the degree of interaction (or interdependencies) between the modules • All the modules in a system can not be independent of each other • The more connection between the modules more connected they are • The fewer and simpler the connections – easier to understand and modifiable • Low coupling is desired within the modules .
Coupling • Degree of coupling between two modules depends on their interface complexity – Interface complexity is determined by the number of types of parameters that are interchanged during invocation of function Interface Complexity Low Simple Obvious Complicated obscure Type of Connection To module by name To internal elements Type of Communication Data High Control or Hybrid .
Coupling contd. • Types of couplings – Data coupling: communicate using elementary data – Stamp coupling: communicate using composite data – Control coupling: data from one module used to direct the order of instruction execution in another – Common coupling: share same global data item – Content coupling: if their code is shared e. a branch from one module into another • Jump instruction from one of the module to another module’s instruction • C language not support it Data Low Stamp Control Common Content High .g..
Neat Arrangement • Represents the control hierarchy • Characterized by the following: • Layered solution M1 M2 M3 M4 0 – Modules are arranged in layers 2 – Superordinate/subordinate modules M5 – Visibility : if a module A directly/indirectly calls another module B then module B is visible to module A 1 • Control abstraction – Should invoke the functions of the modules in the layer immediate below to it • Depth and width – Provide an indication of the number of levels of control and overall span of control respectively • Fan-out – Measures the number of modules directly controlled by a given module • Fan-in – Number of modules directly invoking a given module. – High fan-in represents code-reuse and is encouraged .
each function is successively redefined into more detailed function • System state is centralized and shared among different functions – Object-oriented • System is viewed as a collection of objects • The system state is decentralized among objects and each object manages its own state information.Software Design Approach • Two design approach – Function-oriented • System can be viewed as something that performs some operations • Starting with a high level function. • Objects have their own internal data which define their state .
Function-oriented Design • Salient features: – Top-down decomposition • Example: create_new_library_member » Assign_membership_number » Create_member_record » Print_bill – Centralized system state • System state is the value of the certain data items that determines the response of the system to a user action or external event – These system state can be used by several modules. .
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.