1. Unit-4 Design and Implementation

2. Design Engineering Design engineering encompasses the set of principles, concepts and practices that lead to the development of a high quality system or product Good Design should have Firmness: A program should not have any bugs that inhibit its function. Commodity: A program should be suitable for the purposes for which it was intended. Delight: The experience of using the program should be a pleasurable one.

3. Purpose of Design Design is where customer requirements, business needs, and technical considerations all come together in the formulation of a product or system The design model provides detail about the software data structures, architecture, interfaces, and components The design model can be assessed for quality and be improved before code is generated and tests are conducted – Does the design contain errors, inconsistencies, or omissions? – Are there better design alternatives? – Can the design be implemented within the constraints, schedule, and cost that have been established?

4. Purpose of Design (continued) A designer must practice diversification and convergence – The designer selects from design components, component solutions, and knowledge available through catalogs, textbooks, and experience – The designer then chooses the elements from this collection that meet the requirements defined by requirements engineering and analysis modeling – Convergence occurs as alternatives are considered and rejected until one particular configuration of components is chosen Software design is an iterative process through which requirements are translated into a blueprint for constructing the software – Design begins at a high level of abstraction that can be directly traced back to the data, functional, and behavioral requirements – As design iteration occurs, subsequent refinement leads to design representations at much lower levels of abstraction

6. From Analysis Model to Design Model Each element of the analysis model provides information that is necessary to create the four design models  The data/class design transforms analysis classes into design classes along with the data structures required to implement the software  The architectural design defines the relationship between major structural elements of the software; architectural styles and design patterns help achieve the requirements defined for the system  The interface design describes how the software communicates with systems that interoperate with it and with humans that use it  The component-level design transforms structural elements of the software architecture into a procedural description of software components

7. 7 From Analysis Model to Design Model (continued) Data/Class Design (Class-based model, Behavioral model) Architectural Design (Class-based model, Flow-oriented model) Interface Design (Scenario-based model, Flow-oriented model Behavioral model) Component-level Design (Class-based model, Flow-oriented model Behavioral model)

8. Goals of a Good Design The design must implement all of the explicit requirements contained in the analysis model – It must also accommodate all of the implicit requirements desired by the stakeholders The design must be a readable and understandable guide for those who generate code, and for those who test and support the software The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective

9. Design Quality Guidelines 1)A design should exhibit an architecture that a)Has been created using recognizable architectural styles or patterns b)Is composed of components that exhibit good design characteristics c)Can be implemented in an evolutionary fashion, thereby facilitating implementation and testing 2)A design should be modular; that is, the software should be logically partitioned into elements or subsystems 3)A design should contain distinct representations of data, architecture, interfaces, and components 4)A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns

10. Quality Guidelines (continued) 5)A design should lead to components that exhibit independent functional characteristics 6)A design should lead to interfaces that reduce the complexity of connections between components and with the external environment 7)A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis 8)A design should be represented using a notation that effectively communicates its meaning

11. Quality attributes Functionality is assessed by evaluating the feature set and capabilities of the program, the generality of the functions that are delivered, and the security of the overall system. Usability is assessed by considering human factors, overall aesthetics, consistency, and documentation. Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of output results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the predictability of the program. Performance is measured by considering processing speed, response time, resource consumption, throughput, and efficiency. Supportability combines the ability to extend the program (extensibility), adaptability, serviceability—these three attributes represent a more common term, maintainability—and in addition, testability, compatibility, configurability, the ease with which a system can be installed, and the ease with which problems can be localized.

12. Software design evolution Procedural aspects- structured design – translation of data flow or data structure – object oriented approach to design derivation- aspect oriented methods- model driven deployment- test driven deployment for achieving more effective modularity and architectural structure in the designs that are created methods have a number of common characteristics:  a mechanism for the translation of the requirements model into a design representation  a notation for representing functional components and their interfaces  heuristics for refinement and partitioning  guidelines for quality assessment.

13. Design Concepts Abstraction – Procedural abstraction – a sequence of instructions that have a specific and limited function-eg. open – Data abstraction – a named collection of data that describes a data object eg. Door(type, swing direction, opening mechanism, height, dimensions) Architecture – The overall structure of the software and the ways in which the structure provides conceptual integrity for a system – Consists of components, connectors, and the relationship between them Structural models Framework models Dynamic models Process models Functional models

14. Patterns – A design structure that solves a particular design problem within a specific context – It provides a description that enables a designer to determine whether the pattern is applicable, whether the pattern can be reused, and whether the pattern can serve as a guide for developing similar patterns Whether the pattern is applicable to current work Whether the pattern can be reused Whether the pattern can serve as a guide for developing a similar, but functionally or structurally different pattern

15. Modularity – Separately named and addressable components (i.e., modules) that are integrated to satisfy requirements (divide and conquer principle) – Makes software intellectually manageable so as to grasp the control paths, span of reference, number of variables, and overall complexity Information hiding – The designing of modules so that the algorithms and local data contained within them are inaccessible to other modules – This enforces access constraints to both procedural (i.e., implementation) detail and local data structures Functional independence – Modules that have a "single-minded" function and an aversion to excessive interaction with other modules – High cohesion – a module performs only a single task – Low coupling – a module has the lowest amount of connection needed with other modules

16. Stepwise refinement- top down design – Development of a program by successively refining levels of procedure detail- elaboration – Complements abstraction and refinement, which enables a designer to specify procedure and data and yet suppress low-level details Refactoring – A reorganization technique that simplifies the design (or internal code structure) of a component without changing its function or external behaviour – Removes redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures, or any other design failures Design classes – Refines the analysis classes by providing design detail that will enable the classes to be implemented – Creates a new set of design classes that implement a software infrastructure to support the business solution

17. Design classes  User interface classes- abstractions necessary for HCI  Business domain classes- refinements  Process classes- low level business abstractions  Persistent classes- represent data stores  System classes- software management and control functions interacting with outside world

18. Four characteristics of classes Complete and sufficient- encapsulation Primitiveness- accomplishing one service completely High cohesion- small, foccussed set of responsibility Low coupling

19. Design class

20. Design Model The process dimension indicates the evolution of the design model as design tasks are executed as part of the software process. The abstraction dimension represents the level of detail as each element of the analysis model is transformed into a design equivalent and then refined iteratively. Dashed line indicates the boundary between the analysis and design models. In some cases, a clear distinction between the analysis and design models is possible. In other cases, the analysis model slowly blends into the design and a clear distinction is less obvious.

21. Dimensions

22. Data Design elements Like other software engineering activities, data design (sometimes referred to as data architecting) creates a model of data and/or information that is represented at a high level of abstraction (the customer/user’s view of data). This data model is then refined into progressively more implementation-specific representations that can be processed by the computer-based system. In many software applications, the architecture of the data will have a profound influence on the architecture of the software that must process it. The structure of data has always been an important part of software design.

23. At the program component level, the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications. At the application level, the translation of a data model (derived as part of requirements engineering) into a database is pivotal to achieving the business objectives of a system. At the business level, the collection of information stored in disparate databases and reorganized into a “data warehouse” enables data mining or knowledge discovery that can have an impact on the success of the business itself.

24. Architectural Design elements The architectural design for software is the equivalent to the floor plan of a house Architectural design elements give us an overall view of the software. The architectural model is derived from three sources: (1)Information about the application domain for the software to be built; (2)specific requirements model elements such as data flow diagrams or analysis classes, their relationships and collaborations for the problem at hand (3)the availability of architectural styles and patterns

25. Interface Design elements The interface design for software is analogous to a set of detailed drawings and specifications There are three important elements of interface design: (1)the user interface (UI); (2)external interfaces to other systems, devices, networks, or other producers or consumers of information (3)internal interfaces between various design components. These interface design elements allow the software to communicate externally and enable internal communication and collaboration among the components that populate the software architecture. UI design (increasingly called usability design) is a major software engineering action

26. Interface diagram realization

27. Usability design incorporates aesthetic elements (e.g., layout, color, graphics, interaction mechanisms), ergonomic elements (e.g., information layout and placement, UI navigation), and technical elements (e.g., UI patterns, reusable components). The UI is a unique subsystem within the overall application architecture. The design of external interfaces requires definitive information about the entity to which information is sent or received. The design of internal interfaces is closely aligned with component-level design.

28. The component-level design for software fully describes the internal detail of each software component. The component-level design defines data structures for all local data objects and algorithmic detail for all processing that occurs within a component and an interface that allows access to all component operations (behaviors). The design details of a component can be modeled at many different levels of abstraction. A UML activity diagram can be used to represent processing logic. Detailed procedural flow for a component can be represented using either pseudocode (a programming language-like representation )or some other diagrammatic form (e.g., flowchart or box diagram). Component Level Elements

29. Component Diagram

30. Deployment-level design elements indicate how software functionality and subsystems will be allocated within the physical computing environment that will support the software. The deployment diagram shows the computing environment but does not explicitly indicate configuration details. For example, the “personal computer” is not further identified. It could be a Mac or a Windows-based PC, a Sun workstation, or a Linux-box. These details are provided when the deployment diagram is revisited in instance form during the latter stages of design or as construction begins. Each instance of the deployment (a specific, named hardware configuration) is identified. Deployment Level Element

31. Deployment diagram

32. Architecture and Design The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. Architecture is not an operational software- analysis the effectiveness of the design; design changes; reduces risks during construction. A design is an instance of an architecture similar to an object being an instance of a class.

33. Importance of Architecture Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system. The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity. Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together”

34. Architectural Descriptions An architectural description (AD) as “a collection of products to document an architecture.” Collection of views forms the description. Each view is “a representation of a whole system from the perspective of a related set of [stakeholder] concerns.” A view is created according to rules and conventions defined in a viewpoint—“a specification of the conventions for constructing and using a view”

35. Architectural style Data Centered architecture

36. Data Flow Architectures (Pipe and filter pattern)

37. Call and return architecture 1. Main program/ sub architectures 2. Remote Procedure call architecture

38. Object Oriented Architecture Encapsulate data and operations to manipulate the data. Communication via message passing.

39. Layered Architecture

40. Architectural Design An archetype is a core abstraction that is critical to the design of an architecture for the target system. But the archetypes themselves do not provide enough implementation detail. Defining and refining software components implementing each archetype.

41. Defining Archetypes

42. Architectural Design Representing the System in Context Uses an architectural context diagram(ACD) to model the manner in which software interacts with entities external to its boundaries.

44. Refining the Architecture into Components

45. Describing Instance in the system

46. Architectural Design Steps 1.Review the fundamental system model 2.Review and refine data flow diagrams for the software. 3.Determine whether the DFD has transform or transaction flow characteristics 4.Isolate the transform center by specifying incoming and outgoing flow boundaries 5.Perform “first level factoring” 6.Perform “second level factoring” 7.Refine the first iteration architecture using design heuristics for improved software quality.

47. Architectural Mapping using data flow

49. Refining the architectural design

50. User Interface Design The Golden Rules: 1.Place the user in control. 2. Reduce the user’s memory load. 3. Make the interface consistent. These golden rules actually form the basis for a set of user interface design principles that guide this important aspect of software design.

51. 1. Place the User in 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.

52. 2. 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.

53. 3.Make the Interface Consistent Allow the user to put the current task into a meaningful context. Maintain consistency across a family of applications. If past interactive models have created user expectations, do not make changes unless there is a compelling reason to do so.

54. User Interface Analysis and Design 1.Interface Analysis and Design Models To build an effective user interface, “all design should begin with an understanding of the intended users, including profiles of their age, gender, physical abilities, education, cultural or ethnic background, motivation, goals and personality” users can be categorized as: – Novices – Knowledgeable, intermittent users. – Knowledgeable, frequent users.

55. 2. The Process

56. Interface Analysis 1.User analysis User Interviews Sales input Marketing input Support input

57. 2.Task Analysis and Modeling The goal of task analysis is to answer the following questions: What work will the user perform in specific circumstances? What tasks and subtasks will be performed as the user does the work? What specific problem domain objects will the user manipulate as work is performed? What is the sequence of work tasks—the workflow?

58. 3.Analysis of Display Content Are different types of data assigned to consistent geographic locations on the screen (e.g., photos always appear in the upper right-hand corner)? Can the user customize the screen location for content? Is proper on-screen identification assigned to all content? If a large report is to be presented, how should it be partitioned for ease of understanding? Will mechanisms be available for moving directly to summary information for large collections of data? Will graphical output be scaled to fit within the bounds of the display device that is used? How will color be used to enhance understanding? How will error messages and warnings be presented to the user? The answers to these questions will help you to establish requirements for content presentation.

59. Interface Design Steps 1. Using information developed during interface analysis define interface objects and actions (operations). 2. Define events (user actions) that will cause the state of the user interface to change. Model this behavior. 3. Depict each interface state as it will actually look to the end user. 4. Indicate how the user interprets the state of the system from information provided through the interface.

60. Applying Interface Design Steps the following homeowner tasks, objects, and data items are identified: accesses the SafeHome system enters an ID and password to allow remote access checks system status displays floor plan and sensor locations displays zones on floor plan changes zones on floor plan displays video camera locations on floor plan selects video camera for viewing views video images (four frames per second) pans or zooms the video camera

61. User Interface Design Patterns

62. Design Issues Response time Help facilities Error handling Menu and command labeling Application accessibility Internationalization

63. WebApp Interface Design Mapping user objectives into interface actions

64. Design Evaluation

65. Implementation Issues Executable version of the software from the initial requirements of the systems High –or - low level programming languages or tailoring and adapting generic, off-the-shelf systems to meet the specific requirements of organization Aspects  Reuse  Configuration management – keep track of versions  Host-target development- develop ( in host) & execute ( in target)

66. Reuse Initially functions and objects in programming language libraries were reused Now software reuse is possible at different levels 1.Abstraction level- design & architectural patterns 2.Object level- objects from appropriate libraries (objects and methods offer needed functionality) eg. JavaMail library 3.Component level- components are collections of objects and object classes that operate together to provide related functions and services eg. User interface using a framework

67. 4.System level- reuse entire applications with some kind of configuration eg. COTS Costs associated with reuse Cost of time spent in looking for software to reuse and assessing whether or not it meets your needs Cost of buying the reusable software Costs of adapting and configuring the reusable software components or systems Cost of integrating reusable software components from different sources with the new code developed

68. Configuration management General process of managing a changing software system Aim is to support the system integration process for all developers to access the project code and documents in a controlled way, to find the changes been made, compile and link components in a system Fundamental configuration management activities Version management – development by several programmers System configuration- what versions of components to create each version Problem tracking- report bugs and other problems

69. Tools Version management- Subversion (multi site, multi team devp) System integration- GNU build system Bug tracking- Bugzilla Host target development (based on Host-target model) Development and execution platforms (platforms can be hardware, OS, dbms-interactive platforms) Development and execution platforms same- Simulators (Embedded Systems)- Simulators are costly so only for popular hardware architectures

70. Middleware also possible Tools 1.Integrated compiler and syntax- directed editing systems 2.Language debugging system 3.Graphical editing tools eg. UML models 4.Testing tools eg. Junit 5.Project support tools 6.Specialized tools eg. Static analyzers 7.IDE (Integrated Development Environment)- set of software tools that supports different aspects with common framework and user interface eg. Eclipse

71. Issues Hardware and software components Availability requirements of the systems- platform failure Component communication- same /physically close platform implementation to reduce communication latency, delay between sending and receiving message Document hardware and software deployment using UML deployment diagrams across hardware platforms Embedded systems – above components + physical size, power capabilities, real time responses in sensor events, real time operating systems