Software Engineering Lecture 10 Software Design Architecture Interface
- Slides: 30
Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1
The Design Activities Architectural Design Interface Design Procedural Design Database Design 2
Architectural Design Concepts ◦ Abstraction ◦ Modularity ◦ Control Hierarchy 3
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. 4
Modularity § § § A module is defined as a sub-program that is invoked by another module. The statement are collectively referred to by a descriptive name called the module name. A module must return to its caller i. e. have a single entry and exit. The module should be relatively small in size. It should be easy to read, modify and use. A module should preferably have a single function. 5
Advantages of Modularity Allow large program to be written by several or different people. Encourage creation of commonly used routines to be placed in library and/or be used by other programs. Simplify overlay procedure of loading large program into main storage. Provide more check point to measure progress. Simplify design, making program easy to modify and reduce maintenance costs. Provide a framework for more complete testing, easier to test. Produces well-designed and more readable program. 6
Disadvantages of Modularity �Execution time, compilation/loading time and storage size requirements may be (though not always) increase. �Intermodule communication problems may be increased, due to the larger number of interfaces between parts of the software. �Demands more initial design time, since greater time would need to be spent in the architectural phase of design. 7
Modularity and Software Cost module development cost of software module integration cost optimal number of modules 8
Control Hierarchy �Control Hierarchy, represents the hierarchical organization of program components (modules) and implies a hierarchy of control. ◦ Fan-Out, which is a measure of the number of modules that are directly controlled by another module. ◦ Fan-in, which indicates how many modules directly control a given module. ◦ Depth: Number of levels of control. ◦ Width: Overall span of control. ◦ Superordinate: i. e. a module that controls another module. ◦ Subordinate: i. e. a module that is controlled by another module. 9
Control Hierarchy M A D E B F C G Depth = 2 Fan-In (A) = 1 Width = 5 Fan-Out (A) = 3 H 10
Effective Modular Design �Functional Independence ◦ Is achieved by developing modules with “single minded” function and an “aversion” to excessive interaction with other modules. �Independence is measured by two qualitative criteria: ◦ Cohesion: a measure of relative functional strength of a module ◦ Coupling: a measure of relative interdependence among modules 11
Cohesion Low Cohesion (undesirable) ◦ Coincidental Cohesion ◦ Logical Cohesion ◦ Temporal Cohesion Moderate ◦ Procedural Cohesion ◦ Communicational Cohesion High (desirable) ◦ One distinct task in a module (High Cohesion) 12
Coupling Low (desirable) ◦ Data Coupling ◦ Stamp Coupling Moderate ◦ Control Coupling High (undesirable) ◦ External Coupling ◦ Common Coupling ◦ Content Coupling 13
User Interface Design A good UI is not easy to create, since the UI development effort is inversely proportional to the ease of use finally obtained in the software 14
Three Golden Rules (Theo Mandel) Place the user in control Reduce the user’s memory load Make the interface consistent 15
Place the user in control Minimize unnecessary / undesired actions Provide flexible interaction Provide undo Allow customized interaction Hide technical internals from the casual user Design direct interaction with screen objects 16
Reduce the user’s memory load Reduce demand on Short-term Memory Establish meaningful defaults Define intuitive short-cuts Use real-world metaphor Disclose information in a progressive fashion 17
Make the interface consistent Allow the user to put the current task into a meaningful context Maintain consistency across a family of applications If past interactive models have created user expectations, do not making unnecessary changes 18
Interface Design Consideration (1) • Interface Consistency • An inconsistent interface is often the source of frustration to the user. • Predictability • Predictability is related to the user model and the consistency of the interface, but emphasizes the principle of least surprise. 19
Interface Design Consideration (2) • Error Handling • A good UI minimizes the chances of an error occurring, and provides a way to recover from any error that does occur. • Ease of Use • A UI should have on-line help and user guidance, which are accessible when user has trouble. 20
Interface Design Consideration (3) • Clarity • Errors can be minimized if the UI communication between the UI and the user is as clear as possible. • Feedback • Feedback to the user is important in reducing frustration and provides reassurance that the user task is actually being carried out. 21
User classification Novices No syntactic knowledge, little semantic knowledge of the computer usage in general Knowledgeable, intermittent users Reasonable semantic knowledge of the application, but low recall of syntactic knowledge Knowledgeable, frequent users Good semantic and syntactic 22
Prototyping is one of the best known method used to design the software interface. The prototype is evaluated by the user, who provides the designer with direct comments about the efficacy of the interface. If formal evaluation techniques are used (e. g. questionnaires, rating sheets), the designer may extract information from these data. Design modification are made based on user input and the next level of prototype is created. The evaluation cycle continues until no further modification to the interface design are necessary. 23
Procedural Design Graphical Design Notation: Flow-chart Tabular Design Notation: Decision Table Program Design Language (PDL) At the component level, the software engineer must represent data structures, interfaces, and algorithms in sufficient detail to guide the generation of programming language source-code. 24
Flow-Chart Boxes to indicate processing steps. � Diamond to indicate logical conditions. � Arrows to indicate flow of control. � Two boxes connected by a line of control will indicate a Sequence. � 25
Flow-Chart Example 26
Decision Table Provides a notation that translates actions and conditions (described in a processing narrative) into a tabular form. § The upper left-hand section contains a list of all conditions. § The lower left-hand section lists all actions that are possible based on the conditions. § The right-hand sections form a matrix that indicates condition combinations and the corresponding actions that will occur for a specific combination 27
Decision Table Example 28
Program Design Language (PDL) is also called structured English, or Pseudocode. § PDL have the following characteristics: § § A fixed syntax of keywords that provide for all structured constructs, data declaration, and modularity characteristics § A free syntax of natural language that describes processing features § Data declaration facilities that should include both simple (scalar, array) and complex (linked list or tree) data structures. § Subprogram definition and calling techniques that support 29 various methods of interface description
References Pressman, Chapter 13 -16 30
- User interface design steps in software engineering
- Design interface software
- User interface design principles in software engineering
- User interface design steps in software engineering
- User interface design in software engineering
- Webapp design pyramid contains
- User interface design process in software engineering
- Requirement analysis in software engineering notes
- Types of testing in software engineering
- User interface prototyping in software engineering
- Real time software design in software engineering
- Design principles in software engineering
- 01:640:244 lecture notes - lecture 15: plat, idah, farad
- User interface design in system analysis and design
- Input and output design in system analysis and design
- What is interface in java
- User led through interaction via series of questions
- Office interface vs industrial interface
- Interface------------ an interface *
- What is architecture business cycle
- Data centered architecture
- Repository architecture style
- Call and return architecture
- System architecture example
- Forward engineering in software engineering
- Architecture lecture notes
- Isa vs microarchitecture
- Financial engineering notes
- Foundation engineering lecture notes
- Professional ethics in engineering notes
- Enterprise architect interface diagram