Software Engineering Software Design

Software Design “Design” is a meaningful engineering representation of something that is to be built. It can be traced to a customer’s requirements and at the same time assessed for quality against a set of predefined criteria for “good design”. To transform requirements into a working system, the designers must satisfy both the customers and the system builders of the development team. Hence the designers produce a “conceptual design” for the customers and a “technical design” for the system builders. A good conceptual design is written in the customer’s language, contains no technical jargons, describes the functions of the system but independent of implementation and is linked to the requirements document. Software technical design focuses on four major areas of concern: data, architecture, interfaces and components.

The Design Model The software design hierarchy is shown below: Component level design Interface design Architectural design Data design

Data Modeling Data object: It is a representation of almost any composite information (something that has a number of different properties or attributes) that must be understood by software. Data objects could be an entity, an occurrence, an event, a role, an organizational unit, a place or a structure. Attributes: A set of characteristics or properties that describe the data object. For example, ID number is an attribute for a student. They can be used to name an instance of the data object, describe the instance, or make reference to another instance in another table. Identifiers: One or more attributes must be defined as an identifier - that is, the identifier becomes the “key” when we want to find an instance of the data object.

Data Modeling contd.. Relationships: Data objects are connected to each other in different ways. It is important to note that object/relationship pairs are bi-directional - they can be read in either direction. Cardinality: The data model must be capable of representing the number of occurrences of objects in a given relationship. The number of occurrences of one object that can be related to the number of occurrences of another object (the maximum number of objects that can participate) is termed Cardinality. Modality: The modality of a relationship is 0 if there is no explicit need for the relationship to occur or the relationship is optional. The modality is 1 if an occurrence of the relationship is mandatory.

Entity Relationship Diagrams The object-relationship pair is the corner stone of the data model. These pairs can be represented graphically using the ERD. Data objects are represented by a labeled rectangle. Relationships are indicated with a labeled line connecting objects. In some variations, the connecting line contains a diamond that is labeled with the relationship. Connections between data objects and relationships are established using a variety of special symbols that indicate cardinality and modality.

ERD - An Illustration Dealership Manufacturer Car Shipper Licenses Stocks Dealership Manufacturer Car Builds Transports Contracts Shipper

Data Flow Diagrams Information is transformed as it flows through a computer based system. The system accepts the input in various forms; applies hardware, software and human elements to transform it; and produces output in various forms. A data flow diagram is a graphical representation of the information flow and the transforms that are applied as data move from input to output. The data flow diagram may be used to represent a system or software at any level of abstraction. Therefore the DFD provides a mechanism for functional modeling as well as information flow modeling.

DFD - An Illustration Input Data Intermediate Data Output Data Data store Input Data Intermediate Data Output Data External Entity External Entity Transform #1 Transform #3 Transform #4 Transform #2 External Entity External Entity

State Transition Diagrams The State Transition diagram represents the behavior of a system by depicting its states and the events that cause the system to change state. A state is any observable mode of behavior. Thus, an STD indicates how the system moves from one state to another. Example: States for a monitoring and control system could be monitoring state, alarm state, pressure release state and so on.

The Data Design The Data design transforms the information domain model created during analysis into the data structures that will be required to implement the software. Data modeling - The data model consists of three interrelated pieces of information: the data object, the attributes that describe the data object, and the relationships that connect the data objects to one another. The data objects and relationships defined in the ERD and the detailed data content depicted in the data dictionary provide the basis for the data design activity. Part of the data design may occur in conjunction with the design of software architecture.

Architectural Design The architectural design defines the relationship between the major structural elements of the software, the “design patterns” that can be used to achieve the requirements that have been defined for the system. It also represents the constraints that affect the way in which architectural design patterns can be applied. It is the “framework” of the system that can be derived from the system specification, the analysis model and the interaction of subsystems within the analysis model.It is very important because: It is an enabler for communication between all stakeholders It highlights early design decisions that will have a profound impact on all the software engineering work that follows. It “constitutes a relatively small part, intellectually graspable model of how the system is structured and how its components work together”.

Architectural styles Data-centered Architectures: A data store (ex: a file or database) resides at the center of this architecture and is accessed frequently by other components that update, add, delete, or otherwise modify data within a store. They promote integratability. Client software Client software Client software Client software Data store Client software Client software Client software Client software Client software

Architectural Styles contd.. Data-flow architectures: This is applied when the input data are to be transformed through a series of computational or manipulative components into output data. A pipe and filter pattern has a set of components called filters, connected by pipes that transmit data from one component to the next. Pipes If the data flow degenerates into a single line of transforms, it is termed batch sequential. Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter Filter

Architectural Styles contd.. Call and Return architectures: This enables the designer/architect to achieve a program structure that is relatively easy to modify and scale. Main Program/subprogram architectures: Decomposes function into a control hierarchy where the “main” program invokes a number of program components, which may invoke still other components. Remote procedure calls: The components of the main program/ subprogram are distributed across multiple computers on the network. M a b c d e f i j k l g h m

Architectural Styles contd.. Object-oriented architectures: The components of the system encapsulate data and the operations that must be applied to manipulate the data. Communication and coordination between components is accomplished via message passing. Class: Furniture Cost Dimensions Weight Location Color Buy Sell Weigh Move The object inherits all attributes and operations of the class Object: Chair Cost Dimensions Weight Location Color Buy Sell Weigh Move

Architectural Styles contd.. Layered architectures: A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set. At the outer layer, components service user interface operations. At the inner layer, components perform operating system interfacing. Intermediate layers provide utility services and application software functions. User Interface Application Utility Core Core

User Interface Design User interface design creates an effective communication between a human and a computer. Following a set of design principles, design identifies interface objects and actions, and then creates a screen layout that forms the basis for a user interface prototype. In order to build an effective user interface, “all design should begin with the understanding of the intended users, including profiles of their age, sex, physical abilities, education, cultural or ethnic background, motivation, goals and personality”. Users belong to 3 broad categories namely - Novices (no syntactic knowledge and little semantic knowledge), knowledgeable intermittent users (reasonable semantic knowledge, but relatively low syntactic knowledge), knowledgeable frequent users (good semantic and syntactic users - “power-user syndromes”)

Golden Rules of UI Design Place the user in control Define interaction modes in a way that does not force the 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 the technical internals from the casual user. Design for interaction with objects that appear on the screen. 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 real world metaphor Disclose information in a progressive fashion.

Golden Rules of UI Design Make the interface consistent: This means that All visual information is organized according to a design standard that is maintained throughout all screen displays. Input mechanisms are constrained to a limited set that are used consistently throughout the application Mechanisms for navigating from task to task are consistently defined and implemented. Allow the user to put the current task into a meaningful content 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.

The UI Design Process The UI design process consists of 4 major framework activities namely: User, task, and environment analysis and modeling - Task analysis for UI design uses either an elaborative or an object-oriented approach but applies this approach to human activities. Interface design - Once task analysis is completed, all tasks (or objects and actions) required by the end user have been identified in detail and the design commences. Defining Interface objects and actions, addressing Design issues are important steps in UI design Interface construction - Once a design model is created, it is implemented as a prototype, examined by users and modified based on their comments Interface validation - Could range from an informal “test drive” to a formal study that uses statistical methods for evaluation.

Component level design This is also called procedural design and occurs after data, architectural, and interface designs have been established. The 3 layers of design must be translated into operational software. To accomplish this, the design must be represented at a level of abstraction that is close to code. Component-level design establishes the algorithmic detail required to manipulate data structures, effect communication between software components via their interfaces, and implement the processing algorithms allocated to each component. Graphical, tabular, or text-based notation is used to represent the design.

Representing component design Graphical Design Notation Graphical tools such as flowchart or box diagram provide useful pictorial patterns that readily depict procedural detail. However if graphical tools are misused, the wrong picture may lead to wrong software. Tabular Design Notation Decision tables provide a notation that translates actions and conditions into a tabular form. The table is difficult to misinterpret and can even be used as a machine readable input to a table driven algorithm. Program Design Language Also called pseudocode, it is a “pidgin language in that it uses the vocabulary of one language (say English) and the overall syntax of another (ex: structured programming language)”.

Design Principles The design process should not suffer from “tunnel vision”. The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world. 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 and coding is not design. The design should be assessed for quality as it is being created, not after the fact. The design should be reviewed to minimize conceptual (semantic) errors.

Design Concepts Abstraction: Permits one to concentrate on a problem at some level of generalization without regard to irrelevant low level details; use of abstraction also permits one to work with concepts and terms that are familiar in the problem environment without having to transform them to an unfamiliar structure. Refinement: One or several instructions of the given program are decomposed into more detailed instruction. This successive decomposition or refinement or specifications terminates when all instructions are expressed in terms of any underlying computer or programming language.

Design Concepts Modularity: It is the single attribute of software that allows a program to be intellectually manageable. Software is divided into separately named and addressable components, often called modules, that are integrated to satisfy problem requirements. Software Architecture: Alludes to the overall structure of the software and the ways in which the structure provides conceptual integrity for the system. Control hierarchy: Also called program structure, it represents the organization of program components (modules) and implies the hierarchy of control.

Design Concepts Structural partitioning: If the architectural style of the system is hierarchical the program structure can be partitioned either horizontally or vertically. Data structure: It is the representation of the logical relationship among individual elements of data. Because the structure of information will invariable affect the final procedural design, it is as important as program structure to the software architecture. Software procedure: Focuses on the processing details of each module individually. Information hiding: Modules should be specified and designed so that information (procedure and data) contained within a module in inaccessible to other modules that have no need for such information.

Effective Modular Design Functional Independence: It is an outgrowth of modularity and the concepts of abstraction and information hiding. It means to design software in such a way that each module addresses a specific sub function of requirements and has a simple interface when viewed from other parts of the program structure. Cohesion: A cohesive module performs a single task within a software procedure, requiring little interaction with procedures being performed in other parts of the program. A cohesive model should ideally do just one thing. Coupling: It is a measure of interconnection among modules in a software structure. It depends of the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.

The Design Document The overall scope of the design effort is described. Much of the information presented here is derived from the System Specification and the Analysis model (SRS). Next, the data design is specified followed by the architectural design, interface design and components design. The Design specification contains a requirements cross specification. The first stage in the test documentation is also contained. Design constraints such as physical memory limitations or the necessity for a specialized external interface may be specified. Special considerations - high-speed processing or other factors may be specified. The final section contains supplementary data (algorithmic descriptions, tabular data etc.). It is also suggested to provide an appendix consisting of preliminary operations/manuals.

In a nutshell... What is software design and it’s importance The Design Model and it’s layers Data Modeling-ERD, State-transition diagrams, Data flow Data design in detail Architectural design in detail Interface design details Component level design Design principles and concepts Effective design techniques The Design document End of Session 4