Software Design And Architecture

Software engineering: To design, to implement, to test and maintain software. Software engineering tells the methodology to produce software. Soft engineering is a balancing act. Everything will be optimized quality satisfaction of customer. Software engineering processes: i. System engineering. ii. Analysis, design, coding etc. Design is focused for quality. In analysis first we collect requirements then see wither there is Missing requirements Extras requirements Specific requirements Remove wrong requirements Correct the wrong things Design Guidelines: Design should exhibit an architectural structure. A design should be modular; That is, the software should be logically partitioned into elements or subsystems. A design should contain distinct representations of data, architecture, interfaces, and components. A design should lead to structure that are appropriate for the objects to be implemented. A design should lead to component that exhibit independent functional characteristics. A design should lead to interface that reduce the complexity of connections between modules and external environment. A design should be derived using a repeatable method. The design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer. The design must be a readable and understandable guide for those who generate code and for those who test and subsequently support the software. The design should provide a complete picture of the software, addressing the data, functional and behavioral domains from an implementation perspective. A design should be represented using a notation that effectively communicates its meaning. A design should exhibit an architecture that - Has been created using recognizable architectural styles or patterns. - Is composed of components that exhibit good design characteristics and. - Can be implemented in an evolutionary fashion. Design principle: The design process should not suffer from tunnel vision. Design should not reinvent the wheel. The design should exhibit uniformity and integration. - Same modules within each component understandable to each. Design should be traceable to the analysis model. - DFD (process within s/w). - ERD (static just like statement). - STD (show structure, different states, observable issues). The design should be structured to accommodate change. Design should degrade (humiliate) gracefully to be handling easily, not hang when giving undesirable words must give message that is not correct. Design should minimize the distance between problem and solution. The design should be reviewed to minimize conceptual (semantic) errors. Design should be accessed for quality. Design is not coding, Coding is not design. The design should be traceable to the analysis model. The design should be structured to accommodate change. Design Concepts: (16/9/2013) 1. Abstraction: Considering a problem at low level of generalization. Tacking our point of interest. Concentrate on the essential features and ignore details that are not relevant. Considering only certain perspectives.

1 ijazulhaq716@gmail.com

Software Design And Architecture

i. Data abstraction: A named collection of data that describes a data object. ii. Procedural abstraction: A named sequence of instructions that has a specific & limited function. iii. Control abstraction: Implies a program control mechanisms without specify internal details. A view of an object that focuses on the information relevant to a particular purpose and ignores the remainder of the information. Design methods and tools should support abstraction by providing techniques for encapsulating functions and data in ways best suited to the view required. It should be possible to view a hierarchical design at various levels of detail. The level of abstraction of a component should be related to its place within the structure of a system. For example a component that deals with files should delegate record handling operations to lower-level modules. 2. Refinement: It is elaboration (explanation) of detail for all abstractions. Opposite of abstraction. The process of stepwise elaboration. The reverse process of abstraction. It is the process of generalization. 3. Modularity: Dividing a problem into smaller components. To divide a problem so software construction, maintenance, testing, design and debugging etc become easy. Software becomes readable and understandable. Modularity is the single attribute of software that allows a program to be intellectually manageable. Monolithic software (A large program composed of a single module) cannot be easily grasped by a software engineer. The number of control paths, span of reference, number of variables, and overall complexity would make understandability close to impossible. In almost all instances, you should break the design into many modules, hoping to make understanding easier and as a consequence, reduce the cost required to build the software. We have to keep the number of modules in software optimal, because if we have less number of modules the structure of software will complex and if we have large number of modules then the modules integration will be difficult and costly. Modularity is the degree to which a system or computer program is composed of discrete components such that a change in one component has minimal impact on other components. Component coupling is low in a modular design. 4. Information Hiding: (17/09/2013) The process of encapsulating/hiding data within the module, so that the outside world cant access it. Changing the software in such a way that the outer function is not affected yet the internal structure gets improved. Information hiding is the ability to prevent certain aspects of a class or software component from being accessible to its clients, using either programming language features (like private variables) or an explicit exporting policy. Information Hiding is the practice of hiding the details of a module with the goal of controlling access to the details from the rest of the system. Information hiding helps manage the complexity of a system since a programmer can concentrate on one module at a time. As the different modules of program are interrelated and work together to solve the problem, Modules provide services to each other through a carefully defined interface. The technique of encapsulating software design decisions in components so that the interfaces to the component reveal as little as possible about its inner working'. Components that hide information about their inner workings are 'black boxes'. Information hiding enables developers to view the system at different layers of abstraction. Therefore it should not be necessary to understand any low-level processing to understand the high level processing. 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. 5. Coupling: It is the interdependence of modules on one another. Function is also called module, if two functions work together, we say that modules are coupled. In coupling there may be chance of clashes, but we cannot remove coupling completely because sometimes a function cannot do his work alone. We will try to reduce coupling but we cant remove it completely. Coupling may be reduced by eliminating unnecessary relationships, and reducing relationships. Coupling is simply passing parameters or receiving parameters. Coupling increase complexity. In two coupled modules when we change one we have to also change the other one.

2 ijazulhaq716@gmail.com

Software Design And Architecture

The degree to which a module is connected to other modules in the system. Some coupling is essential, but what we want is to eliminate unnecessary coupling. This makes modification/maintenance of the system much easier. If a class A depends on a class B, and we want to build a system that reuses class A, then we must also include class B in the system, whether or not it would otherwise be needed. If a class A depends on a class B, and class B is modified, class A may need to change as well. While dependencies are unavoidable (and indeed often necessary), what we want to do is to minimize the likelihood of cascading modification occurring, which depends on the strength of the coupling between two classes. High coupling makes modifying parts of the system difficult, e.g. modifying a component affects all the components to which the component is connected/ coupled. A 'couple' is an item of information passed between two components. The 'coupling' between two components can be measured by the number of couples passed. The number of couples flowing into and out of a component should be minimized. The term 'coupling' is also frequently used to describe the relative independence of a component. 'Tightly' coupled components have a high level of interdependence and 'loosely' coupled components have a low level of interdependence. Dependencies between components should be minimized to maximize reusability and maintainability. Reducing coupling also simplifies interfaces. The information passed between components should be the minimum necessary to do the job.

Types of coupling: i. Data Coupling: Modules communicate by parameters. One to one correspondence of items exists. Two components are data coupled if there are homogeneous data items. Data coupling is passing only the data needed. Only simple data is passed between modules. ii. Stamp Coupling: Passing composite data between modules is called stamp coupling. Occurs when complete data structures are passed from one module to another. Component passes a data structure to another component that does not have access to the entire structure. Stamp coupling is passing more data than is needed. Stamp coupling should be avoided. Components should only be given the data that is relevant to their task. An example of stamp coupling is to pass a data structure to a component that only requires the ages of the people in the census to calculate the average age. The precise format of the data structures is a common property of those modules. iii. Control Coupling: A module controls the logic of another module. I.e. in if statement to check the condition in one function and decision is taken in other function. Control coupling arises when a method does different things depending on the value of a flag parameter. Control coupling is communication by flags. It is bad practice to use control coupling for the primary control flow; this should be implied by the component hierarchy. It is acceptable to use control coupling for secondary control flows such as in error handling. Module directs the execution of another module by passing the necessary control information. Accomplished by means of flags that set by one module and reacted upon by the dependent module. iv. Hybrid Coupling: A set of data is used as control. v. Common Coupling: Two modules have shared data. This coupling is done by the use of global variables. Occurs when a number of modules reference a global data area. Usually a poor design choice because - Lack of clear responsibility for the data. - Reduces readability. - Difficult to determine all the components that affect a data element (reduces maintainability). - Difficult to reuse components. - Reduces ability to control data accesses. Common coupling is communication by means of global data, and causes data to be less secure because faults in components that have access to the data area may corrupt it. Common coupling should normally be avoided, although it is sometimes necessary to provide access to data by components that do not have a direct call connection (e.g. if A calls B, B calls C, and A has to pass data to C).

3 ijazulhaq716@gmail.com

Software Design And Architecture

vi. Content Coupling: A module refers to the inside of another module. I.e. goto() statement. Content coupling occurs when a module surreptitiously (secretly) depends on the inner workings of another module. One component references contents of another. Component directly modifies anothers data. Content coupling is communication by changing the instructions and internal data in another component. It prevents information hiding. Only older languages and assembler allow this type of coupling. Module directly affects the working of another module. Occurs when a module changes another modules data or when control is passed from one module to the middle of another (as in a jump). Advantages of functional independence: (18/9/2013) i. Error isolation. ii. Reuse. iii. Understandability. iv. Change management is easy. Note: In dependency/coupling the error will propagate. Cohesion: A module is said to be cohesive if it perform a single task. Each of the statement is related to each other modules performing single minded function are called cohesive modules. The result of cohesiveness is functional independence. A module is said to be functional independent if it has high independence/cohesion and low coupling. I.e. if a module is enough to perform his function is said to be functional independent. When an entity has low cohesion, it may be possible to re factor the design to produce higher cohesion by splitting the low cohesion entity into two or more entities with higher cohesion. For example some entities may be responsible for two different kinds of tasks; it can be divided into two separate two entities each of which is responsible for one of the kinds of tasks. A cohesive module performs a single task, requiring little interaction with other components in other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing. The parts of a component should all relate to a single purpose. Cohesion measures the degree to which activities within a component are related to one another. The cohesion of each component should be maximized. High cohesion leads to robust (strong/vigorous), adaptable, maintainable software. Type of Cohesion: i. Coincidental Cohesion: Modules that performs unrelated activities. Actually related to the context but within the context they are not relative. It should be low. For example, issue book, create members, and request librarian leave. The entity is responsible for a set of tasks which have no good reason for being together. Coincidentally cohesive components contain completely unrelated activities. Coincidentally cohesive components are often invented at the end of the design process to contain miscellaneous activities that do not efficiently fit with any others. Coincidental cohesion reduces understandability and maintainability, and should be avoided. No relationship between components. ii. Functional Cohesion: These are related activities. It is a very funny focus on performing single task. The entity performs a single, well-defined task, without side effects. For example, Issue book, Return book, Query book, Browse. Every essential element to a single computation is contained in the component. Ideal situation. Optimal type of cohesion. Performs single, well-defined action. Functionally cohesive components contain elements that all contribute to the execution of one and only one problem-related task. Functionally cohesive components should be easy to reuse. All the components at the bottom of a structure should be functionally cohesive.

4 ijazulhaq716@gmail.com

Software Design And Architecture

iii. Logical Cohesion: All the elements in the module perform similar operations, For example, Error handling, Data input, Data output. The entity is responsible for a set of related tasks, one of which is selected by the caller in each case. Elements of component are related logically and not functionally. Perform a set of logically similar functions. Logically cohesive components perform a range of similar activities. Much of the processing is shared, but special effects are controlled by means of flags. Logical cohesion can make the design less understandable. Logical cohesion should be avoided, but this may require significant restructuring. iv. Temporal Cohesion: All the activities performed in same time span. Irrelevant activities. The entity is responsible for a set of tasks which must be performed at the same general time. Elements of a component are related by timing (i.e. Initialize, Terminate). Difficult to change because you may have to look at numerous components when a change in a data structure is made. Increases chances of regression fault. Component unlikely to be reusable. Performs a set of functions whose only relationship is that they have to be carried out at the same time. Temporally cohesive components contain activities that all take place simultaneously. Bundling unrelated activities together on a temporal basis is bad practice because it reduces modularity. An initialization component may have to be related to other components by a global data area, and this increases coupling and reduces the possibilities for reuse. Temporal cohesion should be avoided. v. Procedural Cohesion: Activities are performed one after the other but are irrelevant. Activities are not depends on one another. Elements of a component are related only to ensure a particular order of execution. Procedurally cohesive components contain chains of activities, with control passing from one activity to the next. Individual activities are only related to the overall goal rather than to one another. Procedurally cohesive components are acceptable at the highest levels of the structure. vi. Communicational Cohesion: Activities involved use the same data structure. Activities may unrelated but use/refers to same data structure. For example Update the record of a student, Delete the record, Insert the record etc. Communicational cohesive components contain activities that share the same input data. Communicational cohesive components should be split into functionally cohesive components. vii. Sequential Cohesion: Every phase provide input for other phase. It is similar to procedural but the activities are related to each other. Activities are depends on each other. Occurs naturally in functional programming languages. Sequentially cohesive components contain chains of activities, with the output of an activity being the input to the next. Sequentially cohesive components should be split into functionally cohesive components. Approaches to Software Design: (24/9/2013) i. Function oriented design. It is common and mature approach. Software is divided into small components called function. Top-down decomposition. Centralized system approach. Divide the software into function and divide the function into small functions on top-down approach. Discover the main function and that function may further be divided into primitive function. For example create new library member. Assign membership, Create member record and Print bill. ii. Object oriented design. Software is divided into small components called objects. System state is decentralized. It is new method/technology. The state of the system depends on the data type. We define the objects first. Data abstraction, Data structure, and Data types; these three are important keywords used in object oriented design. State: Any observable mode is called state, the value of data items tells about the state.

5 ijazulhaq716@gmail.com

Software Design And Architecture

Abstract Data Types:

Abstract Data Type (ADT) is a mathematical model for a certain class of data structures that have similar behavior; or for certain data types of one or more programming languages that have similar semantics. An ADT is defined indirectly, only by the operations that may be performed on it and by mathematical constraints on the effects of those operations.

ADT Offers Following Advantages: i. Encapsulation/Data hiding. ii. High cohesion and low coupling. iii. E2 and understandable design solution. iv. Modeling. Design Patterns: (3/10/2013) These are commonly accepted solutions which recur (repeat) in designing different applications. Design pattern is actually a solution which reduces our efforts. Design pattern reduces the number of design iterations. Pattern is a solution to a problem in a context. Alexander says Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing the same thing twice. Help improve the quality of the software in terms of the software being reusable, maintainable, extensible, etc. Reduce the development time. Patterns are more generic in nature and can be used in almost any kind of application. The basic theme is if few patterns are made they can be used in other design pattern also. - No needs to worry just call them. - Suppose we construct such classes in object oriented that can be used in future. - The reuse is increased and a lot of problems are solved, but unfortunately some problems generate, i.e. complexity increased. A pattern is basically a documented solution which consists of four things. i. The problem. ii. The solution. iii. The context in which the problem exist. iv. The context in which the solution will be implemented Capture expertise and make it accessible to non-experts in a standard form. Facilitate communication among developers by providing a common language. Make it easier to reuse successful designs and avoid alternatives that reduce reusability. Facilitate design modifications. Improve design documentation and understandability. Expert: i. The problem: When a certain activity is needed to be performed, which class should be made responsible for this activity? ii. Solution: Assign responsibility to the information expert. - Suppose we have three classes.
Sale Transaction Sale Item Sale Specification

1
-

We have an activity to calculate total transaction price. To which class this activity will be assigned?. So we look that only class 1 can perform this activity, because only with this class all the information is available, the other two classes (2, 3) has not enough information. - We assign an activity to an expert because may be it can solve the problem well. - Design pattern is also a communication tool and the others can know it. - Patterns and algorithm are similar but patterns focus on understandability and maintainability while the algorithm focuses on complexity (time and space). Design process translates the analysis model into design model. Design Model: (4/10/2014) Design model consists of four components. i. Data design: It transforms data model into classes and other data structures. ERD (Entity Relationship Diagram) is a representation of data model. DFD (Data Flow Diagram) is a representation of functional model; it shoes the flow of data.

6 ijazulhaq716@gmail.com

Software Design And Architecture

ii. iii. STD (State Transition Diagram) is a representation of behavioral model. Flow chart shoes execution flow. Data/classes (class diagram, object diagram) and data structure are designed using the information provided by the analysis model/data model. Data design is translated into databases. Architectural Design: It describes the overall structure of the system from data perspective. It shoes the relationship among different structural elements of software. Where data is created. Where data is stored. Where data goes for processing. From where the input comes. From where output is generated. Paths are defined in architectural design. Which are the paths? We can take help in architectural design from DFD and as a result the diagram made is called collaboration model. Procedural or Component Design. Transforms structural elements of the software architecture into a procedural description of software components. - Textual Algorithm. - Diagram Flowchart. - Tabular Decision Table. - Architectural Decision Tree. Interface Design: How the internal components are interact with each other. It tells how software components, hardware components and users (external system) interacts with each others. Use cases defines user scenario, which is used in analysis phase. Use case diagram is used in analysis for user interface.

iv.

Software Architecture: Software architecture defines the structure or structures of the system, their elements, their externally visible properties and their relationships. Architecture is the abstraction (concept) of a system. External visible things are - Provide services. - Required services. - Fault tolerance ability. - Resource utilization. - Performance characteristics. Software architecture is the overall structure of the software and the ways in which that software provides conceptual integrity for a system. Architecture is the set of principal design decisions governing a system. Architecture is very important because it shows the basic layout of the system. The better will that to first design the architecture. Architecture involves the how and the why, not just the what. Architecture focuses on significant design decisions, decisions that are both structurally and behaviorally important. A system may have multiple views. Architectural View: The representation of the system structural elements (focusing of a single type) is called view. - Different views represent different aspects of a system. - A single view is about a single aspect of the system. - A view also tells about the relationship. A communication tool. - Negotiating or discussing requirements with the user, - Informing the customer about the progress. - Implementing management decisions and allocations. Having architecture make the changes easy. The changes may be categorized into three types. i. Local changes. ii. Non-local changes.

7 ijazulhaq716@gmail.com

Software Design And Architecture

iii. Architectural level changes. A good architecture is that which is flexible so that to bring many changes easily. Architecture is defined first and then converted to design. Architecture is conceptual and design is logical.

Architecture Drivers: (24/10/2013) These are basic requirements which drive architecture, means used in deciding an architecture style. These requirements may be - Functional. - Non-functional. - Related to quality. Architecture Styles or Patterns: These are the organizational recurring patterns or abstracted and reusable models. An important and recurring system construct. They can describe relatively complex protocols of interactions between objects as a single abstraction. Pattern defines a process for solving a problem by following a path of design and implementation choices. A set of design rules that identify the kinds of components and connectors that may be used to compose a system or Subsystem, together with local or global constraints on the way the composition is done. Architectural style determines a set of components together with a set of constraints on how they can be combined. Architectural Styles are of two types. i. Domain Dependent (Reference Model): It can be used in a specific domain. ii. Domain Independent (Global Model) We have four architectural styles i. Structural Style. ii. Distributed Style. iii. Interactive Style. iv. Adaptable Style. i. Structural Style: It divides a system into subsystems and every subsystem works independently. The output of one subsystem is input for the other subsystem. Each system does his task independent and then passes to the next. The main function is performed sequentially. The techniques used in structural style architecture are, Pipe and Filters, Blackboards and Layered Architecture. Pipe and Filters: In this style the nature of the components is same. Consists of individual components, each component has a set of inputs and a set of outputs. There is sequential data flow and transaction. Allow the designer to understand the overall input/output behavior of a system. The example of pipe and filter style is Compiler. Compiler:
High Level Language Semantic Analysis

Lexical Analysis

Syntax Analysis

Machine Language

Code Generation

Optimization

IR

Each component is connected with another to receive information. This architecture style is called Pipe and Filter architecture. Simple, intuitive and efficient composition of components. High potential for reuse. Easy to evolve and enhance. Potential for limited amount of concurrency. Blackboards: A blackboard system is a task independent architecture for integrating multiple problem solving modules. A blackboard system a common global database. There are two components in blackboard, i. Blackboard ii. Processers i. Blackboard is simply a data structure. ii. Processor is individual component, also called problem solving module.

8 ijazulhaq716@gmail.com

Software Design And Architecture

Blackboard is a dedicated component and functionality is performed by processers. Blackboard is one centurial data structure which helps and supports all the processers. All the processers connected with blackboard. It is two way interactions, when processers do his work; it stores its results in blackboard. Blackboard contains all the information about all the processers. Advantages: - Global change is easy than local change, so modification is easy in this case. - Maintainability is easy. - Fault tolerance is easy. - Suitable for network based applications. - Multiple problem solvers. Disadvantage: - The components are connected, so testing is not easy. - Blackboard becomes bottleneck with many clients. - More complex problem solving framework. Layered Architecture: The system is divided into different layers, based on the functionality. Each layer provides a service only to the immediate layer above (at the next higher level of abstraction) and uses the serv ice only of the immediate layer below (at the next lower level of abstraction). There are mainly three layers in a general Layered Architecture. i. Application Layer. ii. Business Layer. iii. Data base/OS layer. Actual functionalities are put in middleware layer (Business Layer). Interfaces, interaction, software, and hardware etc functionalities are kept in business layer. Advantages: - Modularization is on the basis of functionality, it is the main advantage of layered technology. - High cohesion and low coupling. - It is simple structure. - Effective separation of concerns. - Well-defined levels of abstraction. Disadvantages: - Layers are interdependent or there is dependency between layers. - Extra coast is to establish interface between two convictive layers. - Performance degrades with too many layers. - Can be difficult to assign functionality cleanly to the right layer. ii. Distributed Style: This architecture style is used in distributed systems. Basically used for computation speed up. Each component does his work in distributed and at the end we integrate their result. There is basically two configurations i. Master Slave ii. Client Server i. Master Slave: The processing task is distributed among different slaves, and the master is there to integrate the tasks and get the final result. ii. Client Server: There is a single server and multiple clients. iii. Interactive Style: There is more need of interaction with user. iv. Adaptable Style: Used where there is adaptation. Where there is need of change. It has the ability to accept/accommodate changes in architecture. - Flexibility is increased if we reduce dependency. So the components keep independent. - This method is used if new versions of the system occurring.

9 ijazulhaq716@gmail.com