Software Design Lecture 4 PDF

Software Design "You can use an eraser on the drafting table or a sledgehammer on the construction site.“ --Frank Lloyd Wright  What is Software Design? Design bridges that gap between knowing what is needed (software requirements...

Software Design "You can use an eraser on the drafting table or a sledgehammer on the construction site.“ --Frank Lloyd Wright  What is Software Design? Design bridges that gap between knowing what is needed (software requirements specification) to entering the code that makes it work (the construction phase). Design is both a verb and a noun. What is Software Design? [cont] During the design phase, software engineers apply their knowledge of the problem domain and implementation technologies in order to translate system specifications into plans for the technical implementation of the software. The resulting design expresses the overall structure and organization of the planned implementation. It captures the essence of the solution independent of any implementation language.  Why Design is Hard Design is difficult because design is an abstraction of the solution which has yet to be created Design Occurs at Different Levels Standard Levels of Design  Software Design Levels Software design yields three levels of results: 1. Architectural Design - The architectural design is the highest abstract version of the system. It identifies the software as a system with many components interacting with each other. At this level, the designers get the idea of proposed solution domain. 2. High-level Design- The high-level design breaks the ‘single entity-multiple component’ concept of architectural design into less-abstracted view of sub- systems and modules and depicts their interaction with each other. High-level design focuses on how the system along with all of its components can be implemented in forms of modules. It recognizes modular structure of each sub- system and their relation and interaction among each other. 3. Detailed Design- Detailed design deals with the implementation part of what is seen as a system and its sub-systems in the previous two designs. It is more detailed towards modules and their implementations. It defines logical structure of each module and their interfaces to communicate with other modules. 6  Stages of Design Problem understanding – Look at the problem from different angles to discover the design requirements. Identify one or more solutions – Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources. Describe solution abstractions – Use graphical, formal or other descriptive notations to describe the components of the design. Repeat process for each identified abstraction until the design is expressed in primitive terms.  The Design Process Any design may be modeled as a directed graph made up of entities with attributes which participate in relationships. The system should be described at several different levels of abstraction. Design takes place in overlapping stages. It is artificial to separate it into distinct phases but some separation is usually necessary.  Phases in the Design Process Requirements specification Design acti vities Architectural Abstract Interface Component Data Algorithm design specificatio design design structure design n design Soft ware Data System Interface Component Algorithm specification structure architecture specification specification specification specification Design pr oducts  Design Phases Architectural design: Identify sub-systems. Abstract specification: Specify sub-systems. Interface design: Describe sub-system interfaces. Component design: Decompose sub-systems into components. Data structure design: Design data structures to hold problem data. Algorithm design: Design algorithms for problem functions.  A Generic Design Process 1. Understand the problem (software requirements). 2. Construct a “black-box” model of solution (system specification). System specifications are typically represented with use cases (especially when doing OOD). 3. Look for existing solutions (e.g. architecture and design patterns) that cover some or all of the software design problems identified. 4. Design not complete? Consider using one or more design techniques to discover missing design elements – Noun-verb analysis, CRC Cards, step-wise refinement, etc. – Take final analysis model and pronounce a first-draft design (solution) model 5. Consider building prototypes 6. Document and review design 7. Iterate over solution (Refactor) (Evolve the design until it meets functional requirements and maximizes non-functional requirements) Design – Representational Forms Class diagrams for static structure Sequence diagrams for dynamic behavior Textual and visual form of use cases are used to create and validate analysis and design representational forms Other UML models are also useful for understanding the problem and conceptualizing a solution (state machine diagram, activity diagram, etc.)  Design Representational Forms Offers particular abstractions of the system from a certain perspective (viewpoint) Types of representational forms – Visual models – Text – Pseudocode Design representations: Functional, static structural, dynamic behavioral, data modeling (database schema) Core Design Principles  Modularity The goal of design is to partition the system into modules and assign responsibility among the components in a way that: – High cohesion within modules, and – Loose coupling between modules Modularity reduces the total complexity a programmer has to deal with at any one time assuming: 1. Functions are assigned to modules in away that groups similar functions together (Separation of Concerns), and 2. There are small, simple, well-defined interfaces between modules (information hiding) The principles of cohesion and coupling are probably the most important design principles for evaluating the effectiveness of a design.  Coupling Coupling is the measure of dependency between modules. A dependency exists between two modules if a change in one could require a change in the other. The degree of coupling between modules is determined by: – The number of interfaces between modules (quantity), and – Complexity of each interface (determined by the type of communication) (quality)  Types of Coupling Content coupling (also known as Pathological coupling) Common coupling Control coupling Stamp coupling Data coupling  Content Coupling One module directly references the contents of another 1. One module modifies the local data or instructions of another 2. One module refers to local data in another 3. One branches to a local label of another  Common Coupling Two or more modules connected via global data. 1. One module writes/updates global data that another module reads  Control Coupling One module determines the control flow path of another.  Stamp Coupling Passing a composite data structure to a module that uses only part of it. Example: passing a record with three fields to a module that only needs the first two fields.  Data Coupling Modules that share data through parameters.  Cohesion Cohesion is a measure of how strongly related the functions or responsibilities of a module are. A module has high cohesion if all of its elements are working towards the same goal.  Cohesion and Coupling The best designs have high cohesion (also called strong cohesion) within a module and low coupling (also called weak coupling) between modules.  Benefits of high cohesion and low coupling 1. Modules are easier to read and understand. 2. Modules are easier to modify. 3. There is an increased potential for reuse 4. Modules are easier to develop and test.  Coupling and Cohesion Tend to be Inversely Correlated When Coupling is high, cohesion tends to be low and vise versa. Relationship between Coupling and Cohesion  Abstraction Abstraction is a concept used to manage complexity An abstraction is a generalization of something too complex to be dealt with in its entirety Abstraction is for humans not computers Abstraction is a technique we use to compensate for the relatively puny capacity of our brains (when compared to the enormous complexity in the world around us) Successful designers develop abstractions and hierarchies of abstractions for complex entities and move up and down this hierarchy with splendid ease  Form Consistent Abstractions “Abstraction is the ability to engage with a concept while safely ignoring some of its details.” Base classes and interfaces are abstractions. i.e UIComponent (any GUI toolkit), Mammal (classic superclass when discussing OO design) The interface defined by a class is an abstraction of what the class represents A procedure defines an abstraction of some operation. “The principle benefit of abstraction is that it allow you to ignore irrelevant details.”  Information Hiding Information hiding is a design principle The information hidden can be data, data formats, behavior, and more generally, design decisions When information is hidden there is an implied separation between interface and implementation. The information is hidden behind the interface Parnas encourages programmers to hide “difficult design decisions or design decisions which are likely to change” The clients of a module only need to be aware of its interface. Implementation details should be hidden  Information Hiding [Cont] Want to hide design and implementation decisions—especially those likely/subject to change. Information hiding implies encapsulation and abstraction. You are hiding details which creates an abstraction. When skillfully applied, information hiding has the effect of hiding complexity.  Why Practice Information Hiding? Hiding complexity – limiting the amount of information you have to deal with at any one time Reducing dependencies on design and implementation decisions to minimize the impact of changes. (Avoid the ripple effect of changes.) “Large programs that use information hiding were found …to be easier to modify—by a factor of 4—than programs that don’t.[Korson and Vaishnavi 1986]  Encapsulation Encapsulation is an implementation mechanism for enforcing information hiding and abstractions. There is no clear widely accepted definition of encapsulation. It can mean: – A grouping together of related things (records, arrays) – A protected enclosure (object with private data and/or methods)  Separation of Concerns The functions, or more generally concerns, of a program should be separate and distinct such that they may be dealt with on an individual basis. Separation of concerns helps guide module formation. Functions should be distributed among modules in a way that minimizes interdependencies with other modules. Example: many web applications are structured around the 4-tier web architecture: 1. Presentation or UI 2. Business Logic 3. Data Access 4. Database (typically relational) Each layer encapsulates a related set of related functions.  Design Qualities Fitness for purpose. Satisfies product requirements Reliability Robustness Efficiency Usability Maintainability Evolvability Reusability  SOFTWARE DESIGN STRATEGIES  Object-oriented design strategy  Design strategy in which a system or component is expressed in terms of objects and connections between those objects.  Focuses on object decomposition.  Objects have state  Objects have well-defined behavior  Objects have unique identity  Supports inheritance and polymorphism  Structured (or Functional) design strategy  Design strategy in which a system or component is decomposed into single- purpose, independent modules, using an iterative top-down approach.  Focuses on  Functions that the system needs to provide,  the decomposition of these functions, and 36  The creation of modules that incorporate these functions.  Largely inappropriate for use with object-oriented programming languages.  The Benefits of Good Design Good design reduces software complexity which makes the software easier to understand and modify. This facilitates rapid development during a project and provides the foundation for future maintenance and continued system evolution. It enables reuse. Good design makes it easier to reuse code. It improves software quality. Good design exposes defects and makes it easier to test the software. Produce Secure software: Complexity is the root cause of other problems such as security. A program that is difficult to understand is more likely to be vulnerable to exploits than one that is simpler.