Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility, adaptability, serviceability)

Design Concepts Abstraction At the highest level of abstraction, a solution is stated in broad terms using the language of the problem domain At the lower level of abstraction, a more detailed description of the solution is provided Procedural abstraction refers to a sequence of instructions that have a specific and limited function Data abstraction is a named collection of data that describes a data object. The data abstraction for any data object would encompass a set of attributes that describes the object Eg. Open the Door – process, door is an data object

Architecture Architecture is the structure or organization of program components (modules), the manner in which these component interact, and the structure of the data that are used by the components A set of properties that should be described as part of an architectural design : Structural properties : This aspect of the architectural design representation defines the components of a system and the manner in which those components are packaged and interact with one another Extra-functional properties : The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security and other system characteristics. Families of related system : The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems

The architectural design should be represented using one or more number of different models. Structural model:- represents architecture as an organized collection of components Framework:- identifies repeatable architectural design frameworks that are encountered in similar types of applications Dynamic:- indicates how structure / system may change as function of external events Process:- focuses on the design of the business or technical process that the system must accommodate Functional model:- can be used to represent the functional hierarchy of system ADL (Architectural Description Language) is developed to represent these models

Pattern A design pattern can describes a design structure that solves a particular design problem within a specific situation and accompanied by “forces” that may have impact on the manner in which the pattern is applied and used

Separation Of Concerns Separation of concerns suggests that any complex problem can be more easily handled if it is subdivided into pieces that each can be solved and/or optimized independently By separating the concerns into smaller, a problem takes less effort and time to solve This leads to a divide-and-conquer strategy

No of modules increases - cost of effort decreases Modularity Software is divided into separately named and addressable components , called modules ,that are integrated to satisfy problem requirements Monolithic software, large program composed of a single module, can not be easily grasped by software engineer No of modules increases - cost of effort decreases No of modules increases – cost associated with integrating modules also grows figure

Information Hiding Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary to achieve software function Benefits modification

Functional Independence Development of modules with “single-minded” function each module addresses a specific subset of requirements and has a simple interface when viewed from other parts of program structure easier to develop and easier to maintain Independence is assessed using two qualitative criteria : cohesion and coupling

Low coupling facilitates high cohesion Modules should carry out a single processing function Highly related elements should be in the same module Coupling Indication of relative interdependence among modules One module should have little dependence on any other module Loose coupling minimizes the interdependence between modules Low coupling facilitates high cohesion

Refinement top-down strategy A program is developed by successively refining levels of procedural detail We begin with a statement of the function that is defined at high level of abstraction That is , the statement describes functions or information conceptually but provides no information about internal workings of the function or the internal structure of the data We then elaborate on the original statement, providing more and more details as each successive refinement occurs

Aspects As requirements analysis occurs, a set of “concerns” is uncovered As design begins, requirements are refined into a modular design representation An aspect is a representation of crosscutting (i.e. requirement B can not be satisfied without taking A into account) concerns In an ideal context, an aspect is implemented as a separate module

Object-Oriented Design Concepts Refactoring It is the process of changing a s.w system in such a way that it does not alter the external behavior of the code yet improves its internal structure When the s/w 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 failure that can be corrected to yield a better design. Object-Oriented Design Concepts OO design concepts such as classes and objects, inheritance, messages and polymorphism among others.

Five types of design classes : As the design model evolves, we will define a set of design classes that refine the analysis classes by providing design details that will enable the classes to be implemented, and implement a software infrastructure that supports the business solution Five types of design classes : User Interface Classes define all abstractions that are necessary for human-computer interaction

Business Domain Classes identify the attributes and services (methods) that are required to implement some element of the business domain Process Classes implement lower-level business abstraction required to fully manage the business domain classes Persistent Classes represent data stores that will persist beyond the execution of the software System Classes implement software management and control functions that enable the system to operate and communicate within its computing environment and with outside world

Characteristics of well formed Design Classes Complete and sufficient: A design class should be the complete encapsulation of all attributes and methods that can be expected to exist for a class Primitiveness: Methods associated with a design class should be focused on accomplishing one service for the class. Once the service has been implemented with a method, a class should not provide another way to accomplish the same thing

Low Coupling : Collaboration should be kept to an acceptable minimum. High Cohesion : A cohesive design class has a small, focused set of responsibilities and single-mindedly applies attributes and methods to implement those responsibilities. Low Coupling : Collaboration should be kept to an acceptable minimum. Law of Demeter says that a method should only send messages to methods in neighboring classes. Means: design classes within a subsystem should have only limited knowledge of other classes.

The Design Model The design model can be viewed in two different dimensions The process dimension indicates the evolution of the design model as design tasks are executed as a part of the software process The abstraction dimension represents the level of details as each element of the analysis model is transformed into a design equivalent and then refined iteratively

Elements Of Design Model Data Design Elements Architectural Design Elements Interface Design elements Component-Level Design Elements Deployment-Level Design Elements

Dimensions of the Design Model High Analysis Model Abstraction Dimension Design Model Low Architecture Elements Interface Elements Component Level Elements Deployment Level of Elements

Data Design Elements Data design creates model of data / information that is represented at a high level of abstraction (customer / user’s view) This data model is then refined into more implementation specific representations that can be processed by the computer-based system 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 application

At application level, the translation of data model into a database is essential to achieving the business objectives of a system At the business level – data mining can be implemented

Architectural Design Elements It can be derived from three sources: (1) information about the application domain for the s/w to be built (2) specific requirement model element like DFDs / Analysis classes, their relationship, collaboration. (3)availabilty of architectural styles and pattern The architecture design elements is usually depicted as a set of interconnected subsystems Each subsystem may have its own architecture

Interface Design elements It tells how information flows into and out of the system and how it is communicated among components There are three important elements of interface design: User Interface External Interfaces to other systems, devices, networks or other producers / consumers of information Internal Interfaces between various design components

Component-Level Design Elements The component-level design fully describes the internal details of each s.w component Activity diagram can be used to represent processing logic Detailed procedural flow for a component can be represented using either pseudo code or some other diagrammatic form

Algorithm structure follows the rule established for structured programming. Data structures are usually modeled using pseudo code or programming language to be used for implementation

Deployment-Level Design Elements The deployment-level design elements describes how software functionality and subsystems will be allocated within the physical computing environment that will support the software During design, a UML deployment diagram is developed and then refined Figure (8.7) Each subsystem will be elaborated to indicate the components that it implements