Design Concepts and Principles

Design Concepts and Principles

Analysis to Design Data Object Description Entity- Relationship Diagram Data Flow Diagram Process Specification (PSPEC) Component level design (or) procedural design Data Dictionary interface design State-Transition Diagram Control Specification (CSPEC) architectural design data design THE ANALYSIS MODEL THE DESIGN MODEL

Software Design If requirement analysis are about what the system must do then design is all about how the system will do it. - Eg. Blue print of a house.

Characteristics of a Good Design The design must implement all of the explicit requirements in the analysis model and implicit requirements desired by the customer. The design must be readable, understandable for those who generate, 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.

Analysis to Design

Software Design Data Design Transforms the analysis model into the data structures that will be required to implement the software. Architectural Design Defines the relationship between major structural elements, the architectural styles and design patterns that can be used to achieve the requirements defined for the system. Interface Design Describes how the sw communicates with systems that interoperate with it, and with humans who use it. Component Level Design Transforms structural elements of the sw architecture into a procedural description of sw components.

Design Principles The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should exhibit uniformity and integration. The design should be structured to accommodate change. The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Design is not coding, coding is not design. The design should be reviewed to minimize conceptual (semantic) errors.

Design Concepts abstraction data, procedure, control architecture the overall structure of the software modularity compartmentalization of data and function Functional independence single-minded function and low coupling Information hiding controlled interfaces refinement elaboration of detail for all abstractions Refactoring a reorganization technique that simplifies the design

Abstraction - At the highest level of abstraction, a solution is stated in terms that are familiar in problem environment. - At the lowest level of abstraction, the solution is stated in a manner that can be directly implemented. - Types: Data abstraction, Procedural abstraction, Control abstraction

abstraction architecture modularity functional independence hiding refinement refactoring Data Abstraction door manufacturer model number type swing direction inserts lights type number weight opening mechanism implemented as a data structure

Procedural Abstraction open details of enter algorithm implemented with a "knowledge" of the object that is associated with

Control Abstraction - A Program Control Mechanism without specifying internal details. - Eg. Synchronization semaphore in OS

abstraction architecture modularity functional independence hiding refinement refactoring Software Architecture The structure or organization of program components (modules), the manner in which these components interact, and the structure of data that are used by the components.

Architecture M a b c d e n

abstraction architecture modularity functional independence hiding refinement refactoring Modularity C(X) the perceived complexity of a problem X. E(X) the effort (in time) required to solve a problem X. For two problems, P1 and P2, If C(P1) > C(P2) then E(P1) >E(P2) The following conditions are also true in human problem solving: (i) (ii) C(P1+P2) > C(P1)+C(P2) E(P1+P2) > E(P1)+E(P2)

Modularity: Trade-offs What is the "right" number of modules for a specific software design? cost of software module development cost module integration cost optimal number of modules number of modules

Modularity & Software Cost

abstraction architecture modularity functional independence hiding refinement refactoring Functional Independence COHESION - the degree to which a module performs one and only one function. COUPLING - the degree to which a module is "connected" to other modules in the system.

Types of Cohesion Coincidental Cohesion: It occurs when the elements within a given module have no apparent relationship to each other. Logical Cohesion: A Module has Logical Cohesion only if there is some Logical relationship between the elements of the module. Temporal Cohesion: The elements are also related in time and are executed at the same time. Procedural Cohesion: This level Cohesion contains the elements which belongs to a common procedural unit. Sequential Cohesion: These Cohesion occurs only when the output of one element is the input for the next element. Functional Cohesion: The elements of the module are related to performing a single function. 19

Types of Coupling Two modules are tightly coupled when they depend a great deal on each other Loosely coupled modules have some dependence, but their interconnections are weak Uncoupled modules have no interconnections at all; they are completely unrelated 20

Types of Coupling Content coupling Common coupling Control coupling Stamp coupling Data coupling 21

Content Coupling 22

Common Coupling 23

Control Coupling 24

Stamp Coupling and Data Coupling 25

Types of coupling 26

abstraction architecture modularity functional independence hiding refinement refactoring clients Information Hiding module controlled interface "secret" algorithm data structure details of external interface resource allocation policy a specific design decision

Why Information Hiding? Reduces the likelihood of side effects Limits the global impact of local design decisions Emphasizes communication through controlled interfaces Discourages the use of global data Leads to encapsulation an attribute of high quality design Results in higher quality software

abstraction architecture modularity functional independence hiding refinement refactoring open Stepwise Refinement walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat

abstraction architecture modularity Functional independence hiding refinement refactoring Refactoring What is refactoring? Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

Refactoring When software is refactored, the existing design is examined for redundancy unused design elements inefficient or unnecessary algorithms poorly constructed or inappropriate data structures or any other design failure that can be corrected to yield a better design.

WHAT MAKES A SOFTWARE DESIGN GOOD? The design must meet the specification - this is usually captured in the requirements package. The design should be hierarchical, that is, we must be able to understand the design at different levels of abstraction. The design should be modular. Note a module is an independent part that is used to construct more complex objects. In software systems such a part can be an object, a class, a network of classes, a package or even a complete program. The design should contain both data and control abstractions The design should lead to highly cohesive modules. The design should lead to loosely-coupled modules

GUIDELINES FOR A GOOD DESIGN Functional Independence is a measure of how well separated modules of a system are. If the modules are well separated then making changes to one module does not effect the other modules. Functional independence is ensured by high cohesion and low coupling. Coupling (dependence) is the degree to which a module relies on other modules. Low coupling usually implies a small interface through which a module interacts with other modules. Cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are.

GUIDELINES FOR A GOOD DESIGN Reuse existing components where possible Structure design to reflect problem structure (where possible) Designs should appear to have been written by one person in one sitting Designs should be built to accommodate change Designs should be robust in the face of bad data or other conditions Designs should not descend to the level of code The quality of the design should be assessed throughout the design process Everything should be made as simple as possible, but not simpler - Albert Einstein

Design Model Like a Pyramid Component Level Design interface design architectural design data design

Architectural Design 36

Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: (1) analyze the effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and (3) reduce the risks associated with the construction of the software. 37

Why is Architecture Important? 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. 38

At the architectural level Data Design Design of one or more databases to support the application architecture Data Mining - Navigate through existing databases in an attempt to extract appropriate business-level information Data warehouse a large, independent database that has access to the data that are stored in databases that serve the set of applications required by a business 39

Data Design At the component level refine data objects and develop a set of data abstractions implement data object attributes as one or more data structures review data structures to ensure that appropriate relationships have been established simplify data structures as required 40

Data Design Component Level 1. The systematic analysis principles applied to function and behavior should also be applied to data. 2. All data structures and the operations to be performed on each should be identified. 3. A data dictionary should be established and used to define both data and program design. 4. Low level data design decisions should be deferred until late in the design process. 5. The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure Concept of information hiding 6. A library of useful data structures and the operations that may be applied to them should be developed. 7. A software design and programming language should support the specification and realization of abstract data types. 41

Architectural Styles Each style has a set of components (e.g., a database, computational modules) that perform a function required by a system, a set of connectors that enable communication, coordination and cooperation among components, constraints that define how components can be integrated to form the system, and semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts. 42

Types of Architectural Styles Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures

Data-Centered Architecture 44

Data Flow Architecture 45

Call and Return Architecture 46

Layered Architecture 47

Architectural Patterns Concurrency applications must handle multiple tasks in a manner that simulates parallelism Operating system process management pattern Task scheduler pattern Persistence Persistent data are stored in a database and may be read or modified by other processes at a later time. Data Base Management System pattern Application level persistence pattern Distribution the manner in which systems or components within systems communicate with one another in a distributed environment Broker pattern 48

Architectural Design The software must be placed into context the design should define the external entities (other systems, devices, people) that the software interacts with and the nature of the interaction A set of architectural archetypes should be identified An archetype is an abstraction (similar to a class) that represents one element of system behavior The designer specifies the structure of the system by defining and refining software components that implement each archetype 49

Architectural Context Safehome Product Internet-based system control panel homeowner uses target system: Security Function uses surveillance function peers uses sensors sensors 50

Archetypes Cont roller communicat es wit h Node Det ect or Indicat or Figure 10.7 UML relationships for SafeHome security function archetypes (adapted from [BOS00]) 51

Component Structure SafeHome Execut ive Funct ion select ion Ext ernal Communicat ion Management Securit y Surveillance Home management GUI Int ernet Int erface Cont rol panel processing det ect or management alarm processing 52

Refined Component Structure SafeHome Executive External Communicat ion Management Security GUI Internet Interface Cont rol panel processing det ect or m anagem ent alarm processing Key pad processing scheduler phone com m unicat ion CP display funct ions alarm sensor sensor sensor sensor sensor sensor 53

Analyzing Architectural Design 1. Collect scenarios. 2. Elicit requirements, constraints, and environment description. 3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements: Module view Process view Data flow view 4. Evaluate quality attributes by considered each attribute in isolation. 5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5. 54

An Architectural Design Method customer requirements "four bedrooms, three baths, lots of glass..." architectural design 55

Deriving Program Architecture Program Architecture 56

Partitioning the Architecture horizontal and vertical partitioning are required 57

Horizontal Partitioning function 1 function 3 function 2 58

Vertical Partitioning: Factoring decision-makers workers 59

Benefits of Partitioned Architecture results in software that is easier to test leads to software that is easier to maintain results in propagation of fewer side effects results in software that is easier to extend 60

Mapping requirements into a software architecture Steps: DFD to Program structure 1. The type of information flow is established. 2. Flow boundaries are indicated. 3. The DFD is mapped into program structure. 4. Control hierarchy is defined. 5. Resultant structure is refined using design measures and heuristics. 6. The architectural description is refined and elaborated. or 61

Types of information flow Transform flow Transaction flow 62

Transform Mapping a b d e f g h c data flow model i j x1 "Transform" mapping x2 x3 x4 b c d e f g i a h j 63

Transform Mapping Design Steps: Step1: Review the fundamental model. Level 0 DFD

Transform Mapping Step2: Review and refine data flow diagrams for the software Level 1 DFD

Level 2 DFD for safehome

Step3: Determine whether the DFD has transform or transaction flow characteristics. Step4: Isolate the transform center by specifying incoming and outgoing flow boundaries. Level 3 DFD

Step5: Perform First level factoring. First level factoring for monitor sensors

Step6: Perform second level factoring.

Step7: Refine the first iteration architecture using design heuristics for improved software quality.

Refined Program structure

First Level Factoring main program controller input controller processing controller output controller 72

Second Level Mapping D B C A A C control main B mapping from the flow boundary outward D 73

Transaction Flow incoming flow T action path 74

Transaction Mapping Data flow model f a e b t l m d g h j i k mapping b x1 t program structure n a x2 x3 x4 d e f g h x3.1 l m n i j k 75