Software Design ‘More creative than analysis + Problem solving activity WHAT IS DESIGN “HOW. ™. Software design document (SDD) Software Design design Satisty Customer Developers (Implementers) Fae oo Gane sears, ps ae oe LE) Caro eosin Bigs Depa fatework Software Design Conceptual Design and Technical Design customer ———. Fig. 2: A two part design processSoftware Design Conceptual design answers Software Design "Technical design describes 4 Hardware configuration Where will the data come from ? What will happen to data inthe system? Software nesds 4 Communication interfaces How will the system look to users? % Wofthe system What choices will be offered to users? 4 Software architecture Whats the timings of evens? Network architecture How will the reports & sereen look ike? 4 Any other thing that translates the requirements into a solution tothe customer's problem, Software Design Software Design The design needs to be > Correct & complete Taformal] mail| MO |_Jrinicnea design [> Informal |» formal} Finishes > Understandable setive | | design | | geen | | design > Atthe right level > Maintainable Fig. 3: The transformation of en informal design to a detailed designSoftware Design MODULARITY ‘Tere are many definitions of the term module, Range is from i. Fortran subroutine fi, Ada package ii, Procedures & functions of PASCAL & C iv. C+ Java classes ¥. Java packages vi. Work assignment for an individual programmer Software Design Software Design Alll these definitions are correct. A modular system consist of well defined manageable units with well defined interfaces among the units. Software Design Properties i, Well defined subsystem ii, Well defined purpose iii, Can be separately compiled and stored in a library. iv. Module can use other modules v. Module should be easier to use than to build vi, Simpler from outside than from the inside. Modularity is the single attribute of software that allows a program to be intellectually manageable. It enhances design clarity, which in turn eases implementation, debugging, testing, documenting, and maintenance of software product,Software Design Fig. 4: Modularity and software cost Software Design Loosely coupled: Highly coupled: some dependencies many dependencies (B) © Fig. $= Module coupling Software Design Module Coupling Coupling is the measure of the degree of interdependence between modules O O O O (incoupled: no dependencies) Software Design ‘This can be achieved as: O Controlling the number of parameters passed amongst modules. Avoid passing undesired data to calling module. a ( Maintain parent / child relationship between calling & called modules. a Pass data, not the control information.Software Design Consider the example of editing a student record in a “student information system’ Taraason Taso reso reco susertrare.| Tsen susen| | suaon address. ‘ecord D record course: For For Revove Tete sudo reco scot reson oor design’ Tight Coupling Goad design’ Loose Coupling Fig. 6 Example of coupling Software Design Software Design [Data coupling Best [Stamp coupling [Control coupling [External coupling [Common coupling [Content coupling Worst Fig. 7: The types of module coupling Given two procedures A & B, we can identify number of ‘ways in which they can be coupled. Software Design Data coupling “The dependency between module A and B is said wo be data, coupled if their dependency is based on the fact they communicate by only passing of data. Other than communicating through data, the two modules are independent, Stamp coupling Stamp coupling occurs between module A and B when ‘complete data structure is passed from one module to another. Control coupling Module A and B are said to be control coupled if they ‘communicate by passing of control information, This is usually ‘accomplished by means of flags that are set by one module and reacted upon by the dependent module. Common coupling With common coupling, module A and module B have shared data, Global data areas are commonly found in programming languages. Making a change tothe common data means tracing ‘back to all the modules which access that data to evaluate the effec of changes.Software Design Software Design Pm» Content coupling — = Content coupling occurs when module A changes data of ‘module B or when control is passed from one module to the ‘middle of another. In Fig. 9, module B branches into D, even, though D is supposed to be under the control of C. Fig. 8: Example of common coupling Software Design Software Design Module Cohesion Cohesion is a measure of the degree to which the elements of a module are functionally related | EA Ey ci $y EA rength of relations within modules Fig. 9: Example of content couplingSoftware Design ‘Types of cohesion > Functional cohesion > Sequential cohesion > Procedural cohesion > Temporal cohosion > Logical cohesion > Coincide Software Design Software Design Fundional Cohesion Best (ah) ‘Sequential Cohesion 7 Commuricatonal Gonesion Procedural Cohesion Temporal Cohosion Togieal Cahasion Comneidontal Cohesion Worst (ow) Fig. 11 Types of module cohesion Software Design Functional Cohesion >A and B ave par of a single functonal task. This is very good reazon for them fo be contained inthe same procedure, ‘Sequential Cohesion > Module A outputs some data which forms the input to B, This ie the reason for them to be contained in the eame procedure. Procedural Cohesion > Procedural Cohesion occurs in medules whose instructions although accempssh dlifrent tasks yat have been combined because there Is a specitc order in which the tasks aro to be competed Temporal Cohesion Module exhibits temporal cohesion when it contains tasks that ‘aro rotated by the fact that all tasks must be xeeuted in tho ‘samo time span.Software Design Logical Cohesion > Logical ehesion occurs in modules that contain instructions ‘hat appear tobe related because they fallinto the same logical cass of unctions Coincidental Cohesion > Coincidental cohesion exists in modules that contain instuetions that have le er no relationship to one another. Software Design STRATEGY OF DESIGN {A good system design strategy is to organize the program modules Jn such a way that are easy to develop and latter to, change. Structured design techniques help developers to deal withthe size and complexity of programs. Analysts create instructions for the {developers about how code should be written aad how pieces of code should fit together to form a program. I is important for wo > First, even pre-existing code, if any, needs to be understood, ‘organized and pieced together. > Second, its sill eommon forthe project team to have to write some code and produce original programs that support the pplication logic ofthe system, Soft . ‘Relationship between Cohesion & Coupling IF the software is not properly modularized, a host of seemingly ‘wivial enhancement or changes will result into death of the project. ‘Therefore, a software engineer must design the modules with goal of| bigh cohesion and low coupling, (—er] 4 oncaing os costa Fig. 12: View of eohesion and coupling Software Design Bottom-Up Design Fig. 13 : Bosomup tee structureSoftware Design ‘Top-Down Design Atop down design approach starts by identifying the major modules ofthe system, decomposing them into their lower level modules and iterating until the desired level of deal is achieved, This is stepwise refinement; starting from an abstract design, in each step the design is refined to a more concrete level, until We reach a level where no ‘more refinement is needed and the design can be implemented ddireety Software Design Software Design Hybrid Design For top-down approach to be effective, some bottom-up approach is «essential forthe following reasons: > To pormit common sub modules, > Near the bottom of the hierarchy, where the intuition is simpler, land the need for bottom-up testing is greater, because there are ‘mare numberof modules at aw levels than high loves. > In tho use of prewritn library modules, in particular, rouse of modules. Software Design FUNCTION ORIENTED DESIGN Function Oriented design isan approach to software design where the design is decomposed into a set of interacting units where each unit as a clearly defined function, Thus, system is designed from functional viewpointSoftware Design ‘We continue the refinement of cach module uni we rach he statement level of our programming language. A tat point, we can describe the structure of our program asa tee of refinement as indesign top-down structure a shown in fig. 1, QO Sido Software Design Design Notations Design notations ave largaly meant to be used dung the process of design and are used to represent design or design decisions. For a function oriented design, the design can be representod ‘raphicaly or mathematicaly by the folowing Data tow diagrams Data Dictionaries ‘Stwcture Charts Peoudocede Software Design 1a program is created top-down, the modules become very specialized, [As one can easily se in top down design tructite, each module is used by at most one other module, its parent For 2 module, however, we rust requite that several other males asin design reusable stuctre as shown in Bg. 15 APP Fig. 15 Design reusable structure Software Design Structure Chart 1 partion a system into block boxes. black Box means th Tunetionaity is known ta the user without the knowledge of internal design. MO IOS. 1 rq Fig. 16: Hierarchical formas of«srycture chartcont Nove {T21] Boca tne Nace bh Fig. 17: Structure chart notations Software Design Software Design A structure chart for “update file” is piven in fg. 18. = —s Prt oe weal yom ww (he [at] ety fer ate Fig. 18 Update file Software Design A tcansaction centered stricture describes a system that processes & ‘umber of different types of transactions Iti illustrated in Fig. 19, Fig. 19 : Transation-centered structure Inthe above figure the MAIN module controls the system operation its funtion ist: > invoke the INPUT module to read a transaction > determine the kind of transaction and select one of @ number ‘of transaction modules o process that transaction, and > output the resuts of the processing by calling OUTPUT ‘module.Software Design Pseudocode Pseudocade notation can be used in both the preliminary and detailed esign phases, Using pseudocode, the designer describes system characteristics sing shor, concise, English language phrases that are srectured by ey words such I Then-Flse, While Do, and End Software Design > Level Function Parameters (problem variables, types, purpose, tc) Global variables (problem variable, type, purpose, sharing information) Routines called y the function + Side ottects + InpuvOutput Assertions Software Design Functional Procedure Layers > Function aro builtin layers, Additional notation Is used to > specty dotals. Level 0 Function or procedure name + Relationship to other hich syste tem components (e., part of called by which routines, st.) Bet description ofthe function purpose. + Author, date Software Design rl + Local data structures (variable etc) Timing constraints + Excopton handling (condition, responses. events) Any ether limitations Levels + Body (stuctured chat, Engish pseudo code, decision tables, flow enars, ete)Software Design IEEE Recommended practice for software design descriptions (IEEE STD 1016-1998) > Scope {An SDD isa representation of a software system thts used asa mediom for communicating sofware desig information. > Reterences |. IEEE etd 890-1998, IEEE recommended practice for software requirements specticatons. li IEEE std 610.12-1990, IEEE glossary of software engineering terminology. Software Design > Purpose of an SDD ‘The SDD shows how the sofware system will be siructured to satisfy the requirements idenified in the SRS. It is basicaly the ‘wanslation of requirements into a description of the sofware siructure, sofware components, interaces, and data necessary for ‘he implomentaton phase. Hence, SDD becomes the blue print for ‘he implomentaton acy. > Design Description Information Content + troduction + Design entities + Design entity atributes Software Design > Definitions |. Design entity. An element (Component) of a design that is sirucuraly and functionally astnet from other elements ard ‘hat is separately named and referenced, Ji, Design View. A suoset of design entty atribute information that is specticaly suited to the needs of a sofware project activity Ii, Entity attributes, A named property or charactristos of a design entiy. lt provides statement of fact about the enti Iv, Software design description (SDD). A ropresentation of a software system created to facitale analysis, planning plementation and decision making Software Design ‘The attibutes and associated information ems are defined inthe {allowing subsections a) Identitication f) Dependencies b) Type 9) Interface ©) Purpose 1) Resources ) Function 1) Processing ©) Subordinates ) DataSoftware Design > Design Description Organization Each design descripton writer may have a diferont vow of what are considered the essential aspects of a software design. The ‘organization of SOD is given in table 1. This is one of the possible ways to organize and format the SDD. [A recommended organization of the SDD into separate design views {0 facitae information access and assimilation is givan in table 2 Software Design OP mpd 2 teoreee apna SI" Moshe sa Prowse SEI" eee dein Organization of Bia feoatacneo ORE 62) Data deta ese Software Design 11 Pare 12, Spe 18 Defnitons anlage 2 Reference BLA Malu 1 desertion 8:2 Caneurent Pras decompo B21 Prose 1 dverigtion 2 Data deception 82 Daactiy 2 desipima ——Cant Software Design econ | oseneaie a “Table 2: Design viewsSoftware Design Object Oriented Design Cbjact ranted design isthe result of focusing attention not an the function partermed by the program, but instead onthe data tral aro to do manipulated by the program. Thus itis orthogonal to functon conted design Object Oriented Design begins with an examination of the real ‘world “things" that are par of tho problem to be solved. Those. things (which we wil cal objects) are characterized indivdualy In terms of ther atrbtes and behavior Software Design “The various torms related to objec design are: 1 Objects ‘Tho word “Objot” is usod vory troquonty and convoys tferont rmesring in diferent croumsiances. Here, mesring is an ety able to ‘V0 2 stato (information) and which offrs a number of oporatons [ohavior to siher examina or affect ths stata. An objact i characterized by number of operations and a stale which romembers the eet of theaa operations Software Design > Basie Concepts ‘Object Orented Design isnot dependent on any specie implementation language. Probioms are modeled using cbjcts. ‘Objects nave: + Bohavior (they de things) + State (which changes wen they do things) Software Design ji. Messages ‘Objects communica by message passing. Mossages consist of tho idantty of the targat object, the name of the requested eperaton and any ath operaton noodod to periarm the funtion, Message ave often implamentod as procedure or function cal li, Abstraction In object oriented design, compleny is managed using abstraction, [Abstraction i the eimination ofthe rolevant and the ampiitation of the essentasSoftware Design v. Class In any system, there shall be number of objects. Some of the objects may have common characters. and we can group the objects ‘cording to these characteristic. This type of grouping s Kron 8 & Glass. Hence, a class st of objects that shares common structure ‘anda commen bohaviox. Wo may detino a class “oa” and each abjct that roptsont a car becomes an instanceof this class. in this cass ‘car, Inlca, Sant, Maruti ndigo are instances of tis class as shownin ig 20. Classes are useful because they act as a buopsn or objects. we ‘want 2 new square we may use the square class and simpy lin the partevar deals. colour and poston) fig. 21 shows how can wo Fepresert the square class. Software Design oo ’ SN ine a A ue 5 Fg.20: indica, Sar, Mira, Indigo are all nsanes of the cans “eae Software Design Software Design cine Ste tae) Name real } Attebites ecto || cpa Fig. 21: The square class v. Attributes ‘An attbutos is data valu hold by tho objects Ina class. Tho square ‘os has two attributes: colour and eray of points. Each atrbut has a vale for each ebjoct instanop. Tho altibutos aro shown 86 ‘cond pat of the ass as shown in .21, vi. Operations {An operation i a function o* transformation that may bo apaled to or by objects in a class. In th square class, we have "Wo operatons: set colour) and draw(). All objects in a class share the samo oporaions. [An object “snows” fs class, and hence the right implementation of the ‘operation. Operation are shown in the thie part of the cass as indicted ini 21Software Design vil. Inheritance Imagine that. as wol as squares, we have tangle class. Fig. 22 shows, the cass fora wiangle. cass Tangle anole ‘coour Point} “Set Cobourg Draw) Fig. 22: The angle class Software Design Now, comparing fig. 21 and 22, we can see that there is some Steps to Analyze and Design Objact Oriented System “Thote are various stops in the analysis and design of an object avientd systom and ae given in ig. 25, Software Design Create use case model Fst stop is to idntly the actors interacting with tho system. We ‘Should thon write the use ease ard draw tho use caso diagram li. Draw activity diagram (If required) ‘Actvty Diagram lust the dynamic nature ofa systom by modeling ‘tne flow of ortrel form activity to acy. An activity represents an ‘aperation on some cass inthe syst that results in a change inthe fata ofthe aystom, Fig, 26 shows the actly diagram processing an ‘ardor To eller some goods‘ent Fig. 26: Activity diagram Software Design ‘The object types used in tis araiys's model ave ently objects, Intartace objects and contal objacs as gvon inf. 27. A / on O FO O att Fig. 27: Object pes Software Design ii, Draw the interaction diagram [An interaction diagram shows. an ineracton, consisting of set of ‘objects and thar relationship, inuding the messages hat may be ‘Sspatened among them. lteracton grams adaress the dynamic vow ofa systom. ‘Stops to draws interaction dlagrams are as under: 8} Fst, we shoud ident that the objects with respects to every 1) We draw the soquonce cagrams for ovary uso caso. 4) Wo craw tho collaboration dagrams or ovary use eas. Software Design Iv. Draw the class diagram “Tho class diagram shows tho relationship amongst classes, Thore are {eur typos of relaionships in class diagrams. 8) Association are semantic connection between classes, When fan association connects two classes, each class can send ‘messages to the other ina sequence or a collaboration lagram. Associations can be bisrectonal or unidirectionalSoftware Design b) Dependencies connect two classes, Dependencies are always undirectonal and show that one cia, depends on the Cetintlons In another clase > ©) Aggregations are stionger_ form of association. An aggregation isa relationship between a whole and its parts, o—_ 4d) Generalizations are used to show an inheritance relationship between two classes, —> Software Design Software Design ¥v.Dasign of state chart diagrams slate chan dagram is used fo show the slate space of a given class, the event that eause a transition tom one state to anther. and the acton that result rom a stale change. A stale transtion agra fora “book inthe rary system is gen i hg. 28 ae ver Hemp saet_ [a] wae] dooas fs) es vom ee! Li | Software Design vi. Draw component and development diagram ‘Componant diagrams adcrass the state implementation view of system thay 16 rolated fo class dlagrams in that a component ypealy ‘aps fo ono oF more classes, intofacos or colaberation Deployment Diagram Captures relationship between physica ‘components and te hardware. ‘A sofware has to be developed fr automating the manual rary of @ Unversity. Tho systom shouldbe stand alone in nature. It shoul be esigned to provide functonaiy’s 8s explained below: Iseue of Books: ‘© A student of any course shoud be able to got books issued + Books trom General Section are isued to all but Book bank books are issued only aha respective courses, + A limtation' imposod on the number of books student ean '& K maximum of 4 books ftom Bock bank and 8 books ‘rom General socton issued for 18 days ony:The sofware takes the curont syst date asthe cto of issue and calculates date otro.Software Design “© Abar code detector is used to save the student 3s wall as book information + The due date for rotum ofthe books stamped onthe book. Return of Books: ‘© Any porson can rotum tho issued books (@ The student information is displayed using the bar code setoctor ‘© The system esplays the studont deta on whose name the books were sued as well asthe date of issue ard tum ofthe book ‘© The syslom operator verifies the duration for tho issu, ‘@ The information is saved and the coresponding updating take acelin the database, Software Design ‘Query Processing: {© Tho systom should beable to provide information tke: + Avallabilly of parcular book. + Avalabilly of book of any paroular author. + Number of copies available ofthe desired book ne system should also be able to gonerate raprts regarding the detais of the Books avaale in the library st any given time. Tha ‘otresponding printouts for each enty (asuatrtum) made in the System should be generated. Securty provisions ike the logn ther shouldbe provdod Each usor should have a usor id and '& password. Record o! the users af the system should be kept inthe Jag fo, Provision shouldbe made for us Backup ofthe syst