Your SlideShare is downloading. ×
Software design
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Software design


Published on

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Design modeling principles 1. Design should be traceable to the analysis model 2. Always consider the architecture of system to be built 3. Design of data is as important as design of processing functions 4. Interfaces (both internal and external) must be designed, with care 5. User interface design should be tuned to the needs of the end users 6. Component level design should be functionally independent 7. Components should be loosely coupled to each other and to external environment 8. Design representations (models) should be easily understandable 9. The design should be developed iteratively, with each iteration, the design should strive for greater simplicity. Design Process model Requirement specification Architectural Design It represents a critical link between the design and requirements engineering processes. It establishes a basic structural framework that identifies the major components of a system and the communications between these components. 1. Repository model: Large amounts of data are organized around a shared database or repository. 2. Call and Return: The system is organized as a set of main program and services and associated servers and clients that access and use the services. 3. The layered model: It organizes a system into layers, each of which provides a set of services. 4. Pipes and Filter: where input from one goes to the other component. 5. Object oriented architecture: accomplishes coordination via message passing.
  • 2. There are architectural models that are specific to a particular application domain. There are two types of domain-specific architectural models: 1. Generic models are abstractions from a number of real systems. 2. Reference models are most abstract and describe a larger class of systems Repository model Client-server architecture Documenting Architecture Design A document describing the architecture should contain the following: 1. System and architecture context 2. Description of architecture views 1. Element catalog describes the purpose of the element and its interfaces and their semantic information 2. Architecture rationale gives the reason for selecting the different elements and composing them in the way it was done. 3. Behavior description is added to help aid understanding of the system execution. 4. Other information includes description of all those decisions that have not been taken during architecture creation. 3. Across views documentation Evaluating Architectures The architectural tradeoff analysis method (ATAM) helps in identifying dependencies between competing properties and performs a tradeoff analysis. The basic ATAM has the following steps: 1. Collect scenarios 2. Collect requirements or constraints
  • 3. 3. Describe architectural views 4. Attribute-Specific analysis 5. Identify sensitivities and tradeoffs: Sensitivity is the impact an element has on the attribute value and tradeoff points are those elements that have sensitivity points for multiple attributes. Design concepts Abstraction It is a tool that permits a designer to consider a component at an abstract level without worrying about the details of the implementation of the component. It is an important concept for problem partitioning. During the detailed design and implementation, it is essential to implement the modules so that the abstract specifications of each module are satisfied. There are two common abstraction mechanisms: • Functional abstraction and • Data abstraction Modularity A system is considered modular if it consists of discreet components so that each component can be implemented separately, and a change to one component has minimal impact on other components. Modularity helps in system debugging, system repair, and in system building. Cohesion Cohesion of a module represents how tightly bound the internal elements of the module are to one another. There are several levels of cohesion: 1. Coincidental cohesion is the lowest and occurs when there is no meaningful relationship among the elements of a module. 2. Logical cohesion exists if there is some logical relationship between the elements of a module and elements perform functions that fall in the same logical class. 3. Temporal cohesion is same as above except that elements are also related in time and are executed together. 4. Procedural cohesion contains elements in the same procedural unit. 5. Communicational cohesion has elements related by reference to the same input or output data. 6. Sequential cohesion exists when the output of one form is the input to another. 7. Functional cohesion binds the elements performing a single function. Coupling Coupling between modules is the strength of interconnections between modules or a measure of interdependence among modules. Coupling increases with the complexity and obscurity of the interface between modules. There are 8 types of coupling: 1. Content coupling occurs when one component modifies data that is internal to another component.
  • 4. 2. Common coupling occurs when a number of components all make use of a global variable. 3. Control coupling occurs when operation A() invokes operation B() and passes a control flag to B. 4. Stamp coupling occurs when class B is declared as a type for an argument of operation of class A 5. Data coupling occurs when operations pass long strings of data arguments. 6. Routine call coupling occurs when one operation invokes another. 7. Type use coupling occurs when component A imports or includes a package or the content of component B 8. External coupling when a component communicates or collaborates with infrastructure components. Patterns: are existing designs that are standardized and can be used the same format in other designs. Software reuse Almost all artefacts associated with software development, including project plan and test plan can be reused. Some prominent items that can be effectively reused are requirements specification, design, code, test cases, knowledge etc. The software units that are reused may be of radically different sizes like: 1. Application system reuse i.e. whole of an application system 2. Component reuse from sub-systems to single objects. 3. Object and function reuse e.g library files Benefits of software reuse 1. Increased dependability as the reused software is tested and tried 2. Reduced process risk as cost of component is known, thus no error in cost estimation 3. Effective use of specialists who develop these reusable software. 4. Standards compliance in reusable components 5. Accelerated development by reduced production time. Software reuse requires consideration of the following points: • Component creation: It should be decided in advance what should be created. • Component indexing and storing: Classification of reuse components is essential • Component search: Component matching the requirements has to be identified correctly • Component understanding: Proper understanding of the component is necessary before applying it to use. • Component adaptation: Customization should be possible • Repository maintenance: New components added should be stored and should be traceable. Increasing reusability • Name generalization helps identification with the application of the component
  • 5. • Operation generalization increases applicability • Exception generalization involves providing for all exceptions that might occur in advance. Component Based Software Engineering CBSE process User Interface Design To make visual interfaces more attractive, 14 guidelines are laid. The important ones being: 1. Limit the number of colors employed and be conservative how these are used. 2. Use color change to show a change in system status. 3. Use color coding to support the task users are trying to perform. 4. Use color coding in a thoughtful and consistent way. 5. Be careful about color pairings to avoid eye straining.
  • 6. One should anticipate the background and experience of users when designing error messages. Error messages should be polite, concise, consistent and constructive. Factors to be considered while designing messages are context, experience, skill level, style and culture. User Interface Design process Sometimes the interface is separately prototyped and at times generated iteratively. The three core activities are: 1. User analysis: It is the analysis of user activities. 2. User interface prototyping: There are three approaches for UI prototyping 1. Script driven approach where a script is associated with each element like menu or button. 2. Visual programming language allows access to reusable object to develop interfaces quickly 3. Internet-based prototyping using java, which is fast to develop 2. Interface evolution is the process of assessing the usability of an interface and checking that it meets user requirements. Some techniques for UI evaluation are: 1. Questionnaires to users and their views on UI 2. Observation of user at work 3. Snapshots of typical system use 4. Most common errors and most used facilities User Interface Design issues Design issues 1. User interaction Styles of interaction depend upon the type of application and user. A few styles are discussed below: 1. Direct manipulation using pointer devices like mouse 2. Menu selection through direct manipulation 3. Form fill 4. Command language 5. Natural language 2. Information presentation Information can be presented in the form of tables, pictures or graphs. But information should be isolated from presentation. Changing information can be shown graphically. Large pieces of information can be shown visually. Mapping data flow into software architecture Transform flow: Information enters the system along paths that transform external data into an internal form. 1. Review the fundamental system model 2. Review an refine data flow diagram for the software 3. Determine whether the DFD has transform or transaction flow characteristics 4. Isolate the transform centre by specifying incoming and outgoing flow boundaries 5. Perform first level factoring
  • 7. 6. Perform second level factoring 7. Refine the first iteration architecture using design heuristics for improved software quality Transaction flow: Information flow is often characterized by a single data item, called a transaction that triggers other data flow along one of many paths. 1. Review the fundamental system model 2. Review and refine data flow diagram for the software 3. Determine whether the DFD has transform or transaction flow characteristics 4. Identify the transaction centre and the flow characteristics along each of the action paths. 5. Map the DFD in a progress structure amenable to transaction processing 6. Factor and refine the transaction structure and the structure of each action path 7. Refine the first iteration architecture using design heuristics for improved software quality. Software Design Approaches 1. Function-oriented design 1. The system is viewed as something that performs a set of functions. This function may consist of sub-functions which may be split into more detailed sub-functions. 2. The system state is centralized and shared among different functions
  • 8. 2. Object-oriented design 1. The system is viewed as a collection of objects. The system state is viewed as a collection of objects. 2. The system state is decentralized among the objects and each object manages its own state information. 3. Objects have their own internal data which define their state. Similar objects constitute a class . 4. Objects communicate by message passing. Object oriented Vs Function oriented Function-oriented Object-oriented • Basic abstraction are not real world • Basic abstraction are real world entities functions • State information is distributed among • State information is represented in a the objects of the system and objects centralized shared memory communicate with messages • Functions are grouped together if they • No class grouping is performed constitute a higher level function. Pure object oriented development starts from object oriented approach from requirement gathering to design and development. Object oriented design concepts 1. Classes and objects are basic building blocks of an OOD. Encapsulation is a property of objects, by which objects encapsulate the data and information it contains and supports a well defined abstraction 2. Inheritance is a relation between classes that allows for definition and implementation of one class based on the definition of existing classes. Inheritance can be strict inheritance where all features of the super-class plus additional features exist in base class; or non-strict inheritance, where some features of super-class do not exist in base class and some features are redefined. When a class inherits from more than one class then it is called multiple inheritances. Polymorphism deals with the ability of an object to be of different types. 3. Objects communicate by message passing often implemented as calls 4. Abstraction is the elimination of the irrelevant and amplification of the essentials. 5. Coupling is of three types: 1. Interaction coupling occurs due to methods of a class invoking methods of other classes. The worst form of coupling exists if methods directly access internal parts of other methods. Coupling reduces if methods of a class interact with methods in another class by directly manipulating instance variables of objects of other classes. Coupling is least if methods communicate directly through parameters. 2. Component coupling refers to the interaction between two classes where a class has variables of other class. 3. Inheritance coupling is due to the inheritance relation between classes. The worst form is when a subclass B modifies the signature of a method in B. The least coupling scenario is when a subclass only adds instance variables and methods but does not modify any inherited ones. 6. Cohesion is of three types:
  • 9. 1. Method cohesion focuses on why the different code elements of a method are together within the method. 2. Class cohesion focuses on why different attributes and methods are together in this class. 3. Inheritance cohesion focuses on why classes are together in a hierarchy. Main two reasons for inheritance are to model generalization-specialization relationship and for code-reuse 7. Open closed principle states: Software entities should be open for extension, but closed for modification. The inheritance and polymorphism concepts allow extension in behavior of existing classes without changing original class Object oriented analysis and design (OOAD) The fundamental difference between object-oriented analysis (OOA) and object-oriented design (OOD) is that the former models the problem domain, leading to an understanding and specification of the problem, while the latter models to solution to the problem. Detailed design Design can be expressed in any of the following ways: 1. Process design language (PDL) minmax(infile) ARRAY a DO UNTIL end of input READ an item into a ENDDO max, min:=first item of a DO FOR each item in a IF max<item THEN set max to item IF min>item THEN set min to item ENDDO END 1. Logic/ algorithmic design involves statement of the problem, development of a mathematical model, design of the algorithm, verification of correctness. 2. State modeling represents the logical state of an object such as finite state model Software Design Strategies • Top-down design Advantages 1. It has a strong focus on specific requirements that help to make a design responsive to its requirements. Disadvantages 1. Component-reuse is missed as the system boundaries are specification oriented 2. Misses the benefits of well-structured simple architecture. • Bottom-up design Advantages 1. General solution can be reused
  • 10. 2. It can hide low-level details of implementation Disadvantages 1. It is not so closely related to structure of the problem 2. It may not fit a given need 3. Hard to construct and thus under-designed 4. It leads to proliferation of potentially useful functions rather than the most appropriate ones Metrics for Software Design (detailed design) 1. Cyclomatic complexity for a graph G with n nodes , e edges and p connected components is 1. V(G)=e-n+p 2. The number of regions, 3. The number of decisions+1 2. Data binding captures the module level concept of coupling. It is defined as a triplet (p, x, q) where p and q are modules and x is a variable within the static scope of both p and q. An used data binding exists when both p and q use the variable x for reference or assignment. An actual data binding exist when the module p assigns a value too x and q references x therefore information flow exists. 3. Cohesion metrics CM=∑i=nC(Ri) where C(Ri)=|S| Dim (S) where |S| is the set of statements and |G|=(no. of |G|dim (G) nodes-1) for a reduced graph and dim() is the dimension of a set of statements which is the max. no. of linearly independent paths for S. Metrics for software design (functional) 1. Network metrics focuses on the structure chart. The graph impurity increases with the increase in the number of interactions. Graph impurity=n-e-1 2. Stability metrics tries to quantify the resistance of the design to ripple effects that are caused by changes in modules. Jx= {modules that invoke x} J’x= {modules invoked by x} Rxy= {passed parameters returned from x to y, y Є Jx} R’xy= {parameters passed from x to y, y Є J’x} GRx= {Global data referenced in x} GDx= {Global data defined in x} TPxy= {total number of assumptions made by module y about parameters in Rxy} TP’xy= {total number of assumptions made by y called by module x about elements in R’xy} TGx= {total number of assumptions made by other modules about the elements in GDx} Design Logical ripple effect (DLRE) = TGx + ΣTPxy + ΣTP’xy Design Stability (DS) = 1/(1+DLREx) Program Design Stability (PDS) = 1/(1+ΣDLREx)
  • 11. 3. Information flow metrics is the amount of interaction with other modules Complexity = fan-in*fan-out + inflow*outflow where Fan-in is the number of modules that call module x Fan-out is the number of modules called by module x Inflow is the amount of information sent to module x Outflow is the amount of information sent out by module x Metrics for software design (object-oriented) 1. Weighted methods per class (WMC) WMC=∑i=nCi where Ci is the complexity of methods Mi(M1, M2..) being all the methods of class. Complexity can be estimated size, interface complexity or data flow complexity. 2. Depth of inheritance tree (DIT) is the length of the shortest path from the root of the tree to the node representing C or the number of ancestors C has. 3. Number of children (NOC) is the number of immediate subclasses of C 4. Coupling between classes (CBC) is the total number of other classes to which the class is coupled. 5. Response for a class (RFC) is the cardinality of the response set for a class. The response set of a class C is the set of all methods that can be invoked if a message is sent to an object of this class. 6. Lack of cohesion in methods (LCOM) LCOM=|P|-|Q|, if |P|>|Q|, 0 otherwise, where Q is the set of all cohesive pairs of methods and P is the set of non cohesive pairs. Design Verification methods 1. Design walkthrough is a manual method of verification and is done in an informal meeting called by designer or the leader of the designer’s group. In a walkthrough designer explains the logic step-by-step, and the members of the group ask questions, point out possible errors or seek clarification. 2. Critical design review ensures that the detailed design satisfies the specification laid down during system design. The process is same as inspection with aim of revealing design errors or undesirable properties. The use of checklists ensures focus of discussion on the search of errors. A sample checklist might include following questions: 1. Does each module in system design exist in detailed design 2. Are all assumptions explicitly stated 3. Are all exceptions handled 4. Is the design standardized 5. Is the module logic too complex 6. Are data structures properly created 3. Consistency checkers are essentially compilers that take as input the design specification in a design language. A consistency checker can ensure that any modules invoked or used by a given module actually exist in the design that the interface used by the caller is consistent with the interface definition of the called module.