Unit3.pdf

UNIT 3: Software Design ✓ Outline Looping ▪ What is Design? Software design work products Characteristics of good Design ▪ Design Models ▪ The FURPS quality attributes ▪ Design Concepts ▪ Design Principles ▪ Architectural Design & Styles...

UNIT 3: Software Design ✓ Outline Looping ▪ What is Design? Software design work products Characteristics of good Design ▪ Design Models ▪ The FURPS quality attributes ▪ Design Concepts ▪ Design Principles ▪ Architectural Design & Styles ▪ Component Level or Procedural Design ▪ Cohesion & Coupling ▪ User Interface Design ▪ Golden Rules of User Interface Design ▪ Web Application Design What is Design? A meaningful representation of something to be built It's a process by which requirements are translated into blueprint for constructing a software Blueprint gives us the holistic view (entire view) of a software Design Software SRS Process Design Problem Solution Domain Domain Software Design Process? Software design is the most creative part of the development process Requirement Analysis Design Design Engineering Model Engineering Model Blue Print for Process involves Constructing Diversification & Software Convergence Software design work products Characteristics of good Design For a design to be easily implemented in a The design must implement all explicit conventional programming language, the following requirements available in requirement items must be designed during the design phase. model Different modules required to implement the design The design must accommodate all implicit solution. requirements given by stakeholders Control relationship among the identified modules. The The design must be readable & relationship is also known as the call relationship or understandable invocation relationship among modules. The good design should provide complete picture of the software, addressing the Interface among different modules. The interface data, functional and behavioral domains. among different modules identifies the exact data items exchanged among the modules. Algorithms required to implement each individual module. Data structures of the individual modules. Design Models It is creative activity. It is most critical activity during system development Analysis Models Has great impact on testing and maintenance Scenario-based elements Design document forms reference for later phases Use cases - text Use-case diagrams Activity diagrams Swimlane diagrams Flow-oriented elements Data flow diagrams Control-flow diagrams Procedural Processing narratives Design Procedural description of Software Behavioral elements components State diagrams Interface Design Human computer Sequence diagrams interaction Architectural Design Relationship among structural Class-based elements elements Class diagrams Data/Class Design Data Analysis packages Structure CRC models Collabortion diagrams Design Models Cont. Data Design Architectural Design Interface Design Procedural Design It transforms structural It transforms class It defines the It defines how elements of models into design relationship software software into class realization between major communicates with procedural and prepares data structural systems & with description of structure (data elements of the humans. An interface software design) required to software implies flow of components implement the information & software. behavior. Gentle overview of – F U R P S “Quality is not an act, it is a habit.”— Aristotle Quality attributes of software design The FURPS quality attributes F Functionality U Usability assessed by feature set and capabilities of the assessed by considering human factors, program, generality of the functions & security overall aesthetics, consistency & of overall system documentations R Reliability P Performance assessed by measuring frequency & severity of measured by processing speed, response failures, accuracy of outputs, mean-time-of- time, resource consumption, throughput failure (MTTF), ability to recover from errors and efficiency S Supportability Ability to extend program, adaptability, serviceability, testability, compatibility Design Concepts The beginning of wisdom for a software engineer is to recognize the difference between getting program to work and getting it right Fundamental Each design concept helps to answer the following questions software design concepts provide 1. What criteria can be used to partition software into individual the necessary components? framework 2. How is function or data structure detail separated from a for conceptual representation of the software? “getting it right.” 3. What uniform criteria define the technical quality of a software design? Important Software Design Concepts Abstraction Architecture Pattern Separation of Concern Modularity Information Hiding Refactoring Refinement Aspects Functional Independence Abstraction At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At lower levels of abstraction, a more detailed description of the solution is provided. Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly implemented. Creation of procedural and data abstractions are done. A procedural abstraction refers to a sequence of instructions that have a specific and limited function. A data abstraction is a named collection of data that describes a data object.  Design Principles Design process should not suffer from “tunnel vision” Design should be structured to degrade gently, even when abnormal data, events, Design should be traceable to the analysis model or operating conditions are encountered Design should not reinvent the wheel Design is not coding, coding is not design Design should “minimize the intellectual distance” Design should be assessed for quality as it between the software and the real world problem is being created, not after the fact Design should exhibit (present) uniformity and integration Design should be reviewed to minimize Design should be structured to accommodate change conceptual (semantic) errors Reinvent the Wheel Tunnel Vision Coding Design Design Process Rough View Informal Design Outline Informal Design More formal Design Finished Design Design Process Requirements Specification Design Activities Architectural Abstract Interface Component Data Structure Algorithm Design Specification Design Design Design Design System Software Interface Component Data Structure Algorithm Architecture Specification Specification Specification Specification Specification Design Product Architectural Design Software Architecture & Design Large systems are decomposed into subsystems Sub-systems provide related services Initial design process includes ○ Identifying sub-systems ○ Establishing a framework for sub-system control and communication Why to document the Architecture? Stakeholder Communication: High-level presentation of system System Analysis: Big effect on performance, reliability, maintainability and other –ilities (Usability, Maintainability, Scalability, Reliability, Extensibility, Security, Portability) Large-scale Reuse: Similar requirements similar architecture Software Architecture & Design Architectural design represents the structure of data and program components It considers Architectural style that the system will take Structure and properties of the components that constitute the system Interrelationships that occur among all architectural components of a Marry in haste system repent at leisure Representations of software architecture are an enabler for communication between all parties (stakeholders). Architecture “constitutes a relatively small, intellectually True for Software graspable model of how the system is structured and how its Architecture Design components work together” Architectural Styles Each style describes a system category that encompasses Data-centered architecture style Data-flow architectures A set of components (Ex., a database, computational modules) that perform a function required by a Call and return architecture system. Object-oriented architecture A set of connectors that enable “communication, coordination and cooperation” among components. Layered architecture Constraints that define how components can be integrated to form the system. Semantic models that enable a designer to understand the overall properties of a system. Data-centered architecture style A data store (Ex., a file or database) resides at the center of this architecture and is accessed frequently by other components. Client software accesses a central repository. In some cases the data repository is passive That is, client software accesses the data independent of any changes to the data or the actions of other client software. Data-flow architectures This architecture is applied when input data are to be transformed. A set of components (called filters) connected by pipes that transmit data from one component to the next. Each filter works independently of those components upstream and downstream, is designed to ○ expect data input of a certain form, and ○ produces data output (to the next filter) of a specified form. Call and return architecture This architectural style enables a software designer (system architect) to achieve a program structure that is relatively easy to modify and scale. A number of sub styles exist within this category as below. 1. Main program/subprogram architectures This classic program structure decomposes function into a control hierarchy where a “main” program invokes a number of program components, which in turn may invoke still other components. 2. Remote procedure call architectures The components of a main program/subprogram architecture are distributed across multiple computers on a network. Object-oriented architecture The components of a system encapsulate data and the operations that must be applied to manipulate the data. Communication and coordination between components is accomplished via message passing. Layered architecture A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set. At the outer layer, components service user interface operations. At the inner layer, components perform operating system interfacing. Intermediate layers provide utility services and application software functions. Component Level or Procedural Design Component is a modular, deployable and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. Component-level design occurs after data, architectural and interface designs have been established. It defines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to Effective each component. programmers The intent is to translate the design model into operational should not waste software. their time in But the abstraction level of the existing design model is relatively debugging, they high and the abstraction level of the operational program is low. should not introduce bug to start with Function Oriented Approach The following are the features of a typical function-oriented design approach: 1. A system is viewed as something that performs a set of functions. ○ Starting at this high level view of the system, each function is successively refined into more detailed functions. ○ For example, consider a function create-new-library member which essentially creates the record for a new member, assigns a unique membership number to him, and prints a bill towards his membership charge. This function may consist of the following sub-functions: assign-membership-number, create-member-record and print-bill ○ Each of these sub-functions may be split into more detailed sub-functions and so on. 2. The system state is centralized and shared among different functions. ○ For Ex., data such as member-records is available for reference and updating to several functions such as: create-new-member delete-member update-member-record Object Oriented Approach In the object-oriented design approach, the system is viewed as collection of objects (i.e., entities). The state is decentralized among the objects and each object manages its own state information. For example, in a Library Automation Software, ○ each library member may be a separate object with its own data and functions to operate on these data. ○ In fact, the functions defined for one object cannot refer or change data of other objects. Objects have their own internal data which define their state. Cohesion & Coupling A good software design implies clean The primary characteristics of decomposition of the problem into neat module decomposition modules, and the neat arrangement of are high cohesion and low these modules in a hierarchy. coupling. A cohesive module A Coupling is an performs a single indication of the task, requiring little relative interaction with other interdependence components. among modules. Cohesion Cohesion is an indication of the relative functional Classification of Cohesion strength of a module. A cohesive module performs a single task, requiring little interaction with other components. Coincidental Low Classification of Cohesion Stated simply, a cohesive module should (ideally) do just one thing. Logical A module having high cohesion and low coupling is Temporal said to be functionally independent of other modules. Procedural By the term functional independence, we mean that a Communicational cohesive module performs a single task or function. Sequential Functional High Classification of Cohesion cont. Coincidental cohesion Logical cohesion A module is said to have coincidental A module is said to be logically cohesion, if it performs a set of tasks that cohesive, if all elements of the relate to each other very loosely. module perform similar operations. In this case, the module contains a random For Ex., error handling, data input, collection of functions. data output, etc. It is likely that the functions have been put in An example of logical cohesion is the the module out of pure coincidence without case where a set of print functions any thought or design. generating different output reports For Ex., in a transaction processing system are arranged into a single module In (TPS), the get-input, print-error, and this case, the module contains a summarize-members functions are grouped random collection of functions. into one module At the outer layer, components service user interface operations. Classification of Cohesion cont. Temporal cohesion Procedural cohesion When a module contains functions that are If the set of functions of the module related by the fact that all the functions must are all part of a procedure (algorithm) be executed in the same time span. in which certain sequence of steps For Ex., the set of functions responsible for have to be carried out for achieving initialization, start-up, shutdown of some an objective process, etc. For Ex., the algorithm for decoding a message. Communicational cohesion If all functions of the module refer to the same data structure For Ex., the set of functions defined on an array or a stack. Classification of Cohesion cont. Sequential cohesion If the elements of a module form the parts of sequence, where the output from one element of the sequence is input to the next. For Ex., In a Transaction Processing System, the get-input, validate-input, sort-input functions are grouped into one module. Functional cohesion If different elements of a module cooperate to achieve a single function. For Ex., A module containing all the functions required to manage employees’ pay-roll exhibits functional cohesion. Coupling Coupling between two modules is a measure of Classification of Coupling the degree of interdependence or interaction between the two modules. A module having high cohesion and low coupling is Data Low Classification of Coupling said to be functionally independent of other modules. Stamp If two modules interchange large amounts of data, then they are highly interdependent. Control The degree of coupling between two modules depends on their interface complexity. Common The interface complexity is basically determined by the number of types of parameters that are interchanged while invoking the functions of the Content High module. Classification of Coupling Cont. Data coupling Stamp coupling Two modules are data coupled, if they This is a special case (or extension) communicate through a parameter. of data coupling An example is an elementary (primal) data Two modules (``A'' and ``B'') exhibit item passed as a parameter between two stamp coupling if one passes directly modules, e.g. an integer, a float, a character, to the other a composite data item - etc. such as a record (or structure), array, or (pointer to) a list or tree. Control coupling This occurs when ClassB is declared If data from one module is used to direct the as a type for an argument of an order of instructions execution in another. operation of ClassA An example of control coupling is a flag set in one module and tested in another module Classification of Coupling Cont. Common coupling If data from one module is used to direct the order of instructions execution in another. An example of control coupling is a flag set in one module and tested in another module. Content coupling Content coupling occurs when one component secretly modifies data that is internal to another component. This violets information hiding – a basic design concept Content coupling exists between two modules, if they share code. User Interface Design Golden Rules of User Interface Design Place the User in Control Reduce the User’s Memory Load Make the Interface Consistent Golden Rules of User Interface Design Cont. Place the User in Control During a requirements-gathering session for a major new information system, a key user was asked about the following. Following are the design principles that allow the user to maintain control: Define interaction modes in a way that does not force a user into unnecessary or undesired actions. Provide for flexible interaction Allow user interaction to be interruptible and undoable. Streamline interaction as skill levels advance and allow the interaction to be customized. Hide technical internals from the casual user. Design for direct interaction with objects that appear on the screen. Golden Rules of User Interface Design Cont. Reduce the User’s Memory Load The more a user has to remember, the more error-prone the interaction with the system will be. Following are the design principles that enable an interface to reduce the user’s memory load: Reduce demand on short-term memory. Establish meaningful defaults Define shortcuts that are intuitive The visual layout of the interface should be based on a real-world metaphor Disclose information in a progressive fashion Golden Rules of User Interface Design Cont. Make the Interface Consistent The interface should present and acquire information in a consistent fashion. Following are the design principles that help make the interface consistent Maintain consistency across a family of applications If past interactive models have created user expectations, do not make changes unless there is a compelling (convincing) reason to do so User Interface Analysis and Design Models User profile model – Established by a software engineer ○ Establishes the profile of the end-users of the system ○ based on age, gender, physical abilities, education, cultural background, motivation, goals, and personality. Design model – Created by a software engineer ○ Derived from the analysis model of the requirements. ○ Incorporates data, architectural, interface, and procedural representations of the software. Implementation model – Created by the software implementers ○ Consists of the look and feel of the interface combined with all supporting information (books, videos, help files) that describe system syntax and semantics. User's mental model – Developed by the user when interacting with the application ○ Often called the user's system perception. ○ Consists of the image of the system; that users carry in their heads. The role of the interface designer is to merge these differences and derive a consistent representation of the interface. Web Application Design Design for WebApp encompasses technical and nontechnical activities that include: Establishing the look and feel of the WebApp Defining the overall architectural structure Developing the content and functionality that reside within the architecture Planning the navigation that occurs within the WebApp Web App Interface Design The objectives of a WebApp interface are to Design pyramid for WebApps Establish a consistent window into the content and functionality provided by the interface. Guide the user through a series of interactions with the WebApp. Organize the navigation options and content available to the user Interface Design One of the challenges of interface design for WebApps is the nature of the user’s entry point. Design pyramid for WebApps Cont. Aesthetic Design Content Design Architecture Design Also called graphic design, is an Generate content and design It is tied to the goals artistic endeavor (offer) that the representation for established for a WebApp, the complements the technical content to be used within a content to be presented, the aspects of WebApp design. WebApp. users who will visit, and the navigation that has been established. Component-Level Design Navigation Design Modern WebApps deliver increasingly sophisticated processing functions that Define navigation pathways Perform localized processing to generate content and navigation that enable users to access capability in a dynamic fashion WebApp content and Provide computation or data processing capability that are appropriate for functions. the WebApp’s business domain Provide sophisticated database query and access Establish data interfaces with external corporate systems