Computer Science application and Engineering

Computing

1. 0
Title Animation is here, Please do not delete

2. `
Design Patterns
Ms. Jayasree Narayan & Ms.
Lekshmy VM
Department of Computer Science
Amrita Vishwa Vidyapeetham

3. 2
L




Design Patterns
•A design pattern is a general reusable solution to a commonly
occurring problem in software design.
•It is a description for how to solve a problem that can be used in
many different situations.
•Object-oriented design patterns typically show relationships and
interactions between classes or objects.
Place your
Webcam Video here
Size 38%

4. 3
Why do we need design
Patterns
To solve problems that occurred in some situations like,
•Creating a class
•Instantiating an object
•Interaction between objects
•Writing reusable codes.
Place your
Webcam Video here
Size 38%

5. 4
L




Design Patterns-characteristics
Following are the characteristics of design patterns:
Simple
Reusable
Smart
Generic
Well-proven
Object-Oriented

Place your
Webcam Video here
Size 38%

6. 5
Defining a Design Pattern
A Design Pattern has 5 basic parts:
1. Name
2. Problem
3. Solution
4. Consequences and trade-of of application
5. Implementation: An architecture using a design class diagram
Place your
Webcam Video here
Size 38%

7. 6
Pattern Name
The pattern name is a handle, we can use it to describe a design
problem, its solutions, and consequences in a word or two.

Naming a pattern immediately increases the design vocabulary. It
lets us design at a higher level of abstraction.
Having a vocabulary for patterns lets us talk about them.
It makes it easier to think about designs and to communicate them
and their trade-offs to others.

Place your
Webcam Video here
Size 38%

8. 7
The Problem
The problem describes when to apply the pattern.

•It explains the problem and its context.
•It might describe specific design problems such as how to
represent algorithms as objects.
•It might describe class or object structures that are symptomatic of
an inflexible design.
•Sometimes the problem will include a list of conditions that must
be met before it makes sense to apply the pattern.

Place your
Webcam Video here
Size 38%

9. 8
The Solution
•The solution describes the elements that make up the design, their
relationships, responsibilities, and collaborations.
•The solution doesn't describe a particular concrete design or
implementation, because a pattern is like a template that can be
applied in many different situations.
•Instead, the pattern provides an abstract description of a design
problem and how a general arrangement of elements (classes and
objects in our case) solves it.

Place your
Webcam Video here
Size 38%

10. 9
The Consequences
The consequences are the results and trade-offs of applying the
pattern.
•The consequences for software often concern space and time
trade-offs.
•They may address language and implementation issues as well.
•Since reuse is often a factor in object-oriented design, the
consequences of a pattern include its impact on a system's
flexibility, extensibility, or portability.
•Listing these consequences explicitly helps you understand and
evaluate them

Place your
Webcam Video here
Size 38%

11. 10
Why Use Patterns with Java?
•They have been proven. Patterns reflect the experience, knowledge
and insights of developers who have successfully used these
patterns in their own work.
•They are reusable. Patterns provide a ready-made solution that can
be adapted to different problems, as necessary.
•They are expressive. Patterns provide a common vocabulary of
solutions that can express large solutions succinctly.
•J2EE provides built in patterns.

Place your
Webcam Video here
Size 38%

12. 11
Design patterns in Smalltalk MVC
The Model/View/Controller triad of classes is used to build user
interfaces in Smalltalk-80.
MVC consists of three kinds of objects.

M->>MODEL is the Application object.
V->>View is the screen presentation.
C->>Controller is the way the user interface reacts to user input.

MVC decouples to increase flexibility and reuse.
Place your
Webcam Video here
Size 38%

13. 12
MVC Architectural Design Pattern
COMPSCI 230: Swing MVC 12
•A controller can send commands to the model to
update the model's state (e.g., editing a document).
•It can also send commands to its associated view to change the
view's presentation of the model (e.g., by scrolling through a
document).
•A model notifies its associated views and controllers
when there has been a change in its state.
•This notification allows the views to produce updated output,
and the controllers to change the available set of commands.
•In some cases an MVC implementation may instead be
'passive' and other components must poll the model for
updates rather than being notified.
•A view requests information from the model that it uses
to generate an output representation to the user.
[http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller]

14. 13
Design patterns in Smalltalk MVC
•MVC decouples views and models by establishing a subscribe/notify
protocol between them.
•A view must ensure that its appearance must reflects the state of the
model.
•Whenever the model„s data changes, the model notifies views that
depends on it.
•You can also create new views for a model without Rewriting it.
Place your
Webcam Video here
Size 38%

15. 14
Describing Design patterns
•Graphical notations ,while important and useful, aren„t sufficient.
•They capture the product of the design process as relationships
between classes and objects.
•By using a consistent format, we describe the design pattern .
Place your
Webcam Video here
Size 38%

16. 15
Expectation from User Interface Design
•User Interface should be designed to
match the skills, experience and
expectations of its Anticipated users
•Users judge a product by its interface
rather than its functionality
•A poorly designed interface can cause
a user to make catastrophic errors
•Poor user interface is the reason why so
many software products are never
used.
This Photo by Unknown Author is licensed under CC BY-NC-ND

17. 16
Importance of Interface
•Most important part of the system
“interface is the system for most users”
•Increasingly important
•GUIs is a big improvement over previous approaches.
•Platforms(e.g. Mac/Microsoft) have style guides
•50% of code devoted to interface.

18. 17
Benefits of good Design
•Small improvements can be worth big $$$
•Interface problems are treated as bugs
•Big improvements can establish new products
•Browser was a UI idea – before it, search using gopher etc was
tedious
•Google is a company which has a simple user interface

19. 18
Interface Design
Typical Design Errors

•lack of consistency
•too much memorization
•no guidance / help
•no context sensitivity
•poor response
•Arcane/unfriendly

This Photo by Unknown Author is licensed under CC BY-SA

20. 19
Golden Rules
•Place the user in control

•Reduce the user‟s memory load

•Make the interface consistent

21. 20
Place the User in Control
•Define interaction modes in a way that does not force a 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 technical internals from the casual user.
•Design for direct interaction with objects that appear on the
screen.

22. 21
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 a real
world metaphor.
•Disclose information in a progressive fashion.

23. 22
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 make changes unless there is a compelling reason to do
so.

24. 23
User interface design principles
Principle Description
User familiarity The interface should use terms and concepts which are
drawn from the experience of the people who will
make most use of the system.
Consistency The interface should be consistent in that, wherever
possible, comparable operations should be activated in
the same way.
Minimal surprise Users should never be surprised by the behavior of a system
Recoverability The interface should include mechanisms to allow users to
recover from errors.
User guidance The interface should provide meaningful feedback when errors
occur and provide context-sensitive user help facilities.
User diversity The interface should provide appropriate interaction facilities for
different types of system user.

25. 24
Interaction styles

Interaction style Main Advantage Main disadvantage Application examples
Direct manipulation Fast and Intuitive
interaction
Easy to learn
May be hard to
implement. Only
suitable where there is
a visual metaphor for
tasks and objects
Video games
CAD systems
Menu Selection Avoid user error
Little typing required
Slow for experience
users. Can become
complex when there are
many menu options
Most General purpose
systems
Form fill-in Simple data entry, Easy
to lean
Takes up a lot of screen
space
Stock control, Banking
systems etc
Command Language Powerful and flexible Hard to lean , poor error
management
Operating systems,
Library information
retrieval systems, data
analytics

26. 25
User Interface Elements
•Basic elements
•Edit box
•List box – combo Box
•Radio button
•Check box
•Button
•Advanced elements
•Date Picker
•File picker
•Tree control
•slider

27. 26
Design Issues
•Response time
•Help facilities
•Error handling
•Menu and command labeling
•Application accessibility
•Internationalization

28. 27
Design Evaluation Cycle
(Pressman, R.S. (2010) Software Engineering: A Practitioner’s Approach. 7th Edition, McGraw Hill, New York.)

29. 28
User Analysis
•Are users trained professionals, technician, clerical, or manufacturing workers?
•What level of formal education does the average user have?
•Are the users capable of learning from written materials or have they expressed a desire for
classroom training?
•Are users expert typists or keyboard phobic?
•What is the age range of the user community?
•Will the users be represented predominately by one gender?
•How are users compensated for the work they perform?
•Do users work normal office hours or do they work until the job is done?
•Is the software to be an integral part of the work users do or will it be used only occasionally?
•What is the primary spoken language among users?
•What are the consequences if a user makes a mistake using the system?
•Are users experts in the subject matter that is addressed by the system?
•Do users want to know about the technology the sits behind the interface?

30. 29
Mapping User Objectives objective #1
objective #2
objective #3
objective #4
objective #5
objective #n
List of user objectives
Home page text copy
graphic
graphic, logo, and company name
Navigation
menu
Menu bar
major functions
(Pressman, R.S. (2010) Software Engineering: A Practitioner’s Approach. 7th Edition, McGraw Hill, New York.)

31. 30
UX : User Experience
•UX is how a user feels when using an application
•Good user experience should make users happy
•UX looks at many things – Design, usability, Accessibility,
Marketing, performance, utility

32. 31
UX vs UI
•UX – It is the internal experience that a person has as they
interact with every aspect of a company‟s product and service

•UI – The visual design of an application
‾It is the series of screens, pages, and visual elements like buttons and
icons that you use to interact with a device.

33. 32
Types of Software Documentation
•Project Plan – manage workloads and tasks as changes occur. A
project plan is the foundation of the work you do to lead a project to
successful completion. External Document

•Software Requirements Documentation - created before the project
has started development in order to get every stakeholder on the
same page regarding the software‟s functionality. External Document.

•Architectural Documentation - documentation that concerns the
design. It contains very little code and is more focused on the
components of the system, their roles, and working. It also shows the
data flow throughout the system. Internal Document

•Technical Documentation - These contain the technical aspects of the
software like API, algorithms, etc. It is prepared mostly for software
developers. Internal Document

34. 33
Types of Software Documentation. Contd..
•Test Plan Document - Detailed document that describes the test
strategy, objectives, schedule, estimation, deliverables, and resources
required to perform testing for a software product. Test Plan helps us
determine the effort needed to validate the quality of the application
under test. The test plan serves as a blueprint to conduct software
testing activities as a defined process, which is minutely monitored
and controlled by the test manager. – Internal Document

•End-user Documentation- these are made for the end user. It contains
support resources for the end user.- External Document

35. 34
Project Plan Template
•Project Summary
•Project Scope
•Development Process
•Effort, Schedule and Team
•Assumptions Made
•Detailed Effort and Schedule
•Team Organization
•Hardware and Software resources needed
•Quality Plan
•SRS review, Design review, Testing review, System Testing review
•Risk Management Plan
•Project Tracking

36. 35
Software Requirements Specification Template
•Introduction
•Purpose
•Scope
•Overall Description
•Product Perspective
•Product Functions
•Use case diagram, user characteristics, Constraints, Assumptions and
dependencies
•Functional Requirements- Use case specification
•Non Functional requirements
•User Interface screens

37. 36
Architecture Model
•Overview
•Architecture Design
•Share different types of architectures
•Compare the Architectures
•Final architecture

38. 37
Design Document
•Overview
•Class diagram/Structure chart
•Detail Design specification
•OOP
•Main classes, attributes, methods, Algorithms for each method
•Structured Methodology
•Each module's specification and algorithms used is explained
•Requirements Tracing

39. 38
Test Plan
Test case ID Purpose Steps Expected Results

40. 39
Advantages of Documentation
•The presence of documentation helps in keeping the track of all aspects
of an application and also improves the quality of the software product.
•The main focus is based on the development, maintenance, and
knowledge transfer to other developers.
•Helps development teams during development.
•Helps end-users in using the product.
•Improves overall quality of software product
•It cuts down duplicative work.
•Makes easier to understand code.
•Helps in establishing internal coordination in work.

41. 40
Disadvantages of software documentation

•The documenting code is time-consuming.
•The software development process often takes place under time
pressure, due to which many times the documentation updates don‟t
match the updated code.
•The documentation has no influence on the performance of an
application.
•Documenting is not so fun, it‟s sometimes boring to a certain extent.

42. 41
Coding Phase
•Different modules specified in the design document are
coded in the Coding phase according to the module
specification.
•The main goal of the coding phase is to code from the design
document prepared after the design phase through a high-
level language and then to unit test this code.

43. 42
Coding Standards
•Good software development organizations want their
programmers to maintain to some well-defined and standard
style of coding called coding standards.
•They usually make their own coding standards and guidelines
depending on what suits their organization best and based on
the types of software they develop.
•It is very important for the programmers to maintain the
coding standards otherwise the code will be rejected during
code review.

44. 43
Purpose of Having Coding Standards
•A coding standard gives a uniform appearance to the codes
written by different engineers.
•It improves readability, and maintainability of the code and it
reduces complexity also.
•It helps in code reuse and helps to detect error easily.
•It promotes sound programming practices and increases
efficiency of the programmers.

45. 44
Some Coding Standards
1.Limited use of global:
These rules tell about which types of data that can be declared global and
the data that can‟t be.

2.Error return values and exception handling conventions:
All functions that encountering an error condition should either return a 0
or 1 for simplifying the debugging. On the other hand, Coding guidelines
give some general suggestions regarding the coding style that to be
followed for the betterment of understandability and readability of the
code.

46. 45
Coding Standards
3.Standard headers for different modules:
For better understanding and maintenance of the code, the header of
different modules should follow some standard format and information.
The header format must contain below things that is being used in various
companies:
•Name of the module
•Date of module creation
•Author of the module
•Modification history
•Synopsis of the module about what the module does
•Different functions supported in the module along with their input
output parameters
•Global variables accessed or modified by the module

47. 46
Coding Standards
4.Naming conventions for local variables, global variables,
constants and functions:
Some of the naming conventions are given below:
•Meaningful and understandable variables name helps anyone to
understand the reason of using it.
•Local variables should be named using camel case lettering starting
with small letter (e.g. localData) whereas Global variables names
should start with a capital letter (e.g. GlobalData). Constant names
should be formed using capital letters only (e.g. CONSDATA).
•It is better to avoid the use of digits in variable names.
•The names of the function should be written in camel case starting
with small letters.
•The name of the function must describe the reason of using the
function clearly and briefly.

48. 47
Coding Standards
•Indentation:
Proper indentation is very important to increase the readability
of the code. For making the code readable, programmers
should use White spaces properly. Some of the spacing
conventions are given below:
•There must be a space after giving a comma between two function
arguments.
•Each nested block should be properly indented and spaced.
•Proper Indentation should be there at the beginning and at the end
of each block in the program.
•All braces should start from a new line and the code following the
end of braces also start from a new line.

49. 48
Coding Guidelines
1.Avoid using a coding style that is too difficult to
understand:
Code should be easily understandable. The complex code
makes maintenance and debugging difficult and expensive.
2.Avoid using an identifier for multiple purposes:
Each variable should be given a descriptive and meaningful
name indicating the reason behind using it. This is not possible
if an identifier is used for multiple purposes and thus it can lead
to confusion to the reader. Moreover, it leads to more difficulty
during future enhancements.

50. 49
Coding Guidelines
3.Code should be well documented:
The code should be properly commented for understanding easily.
Comments regarding the statements increase the understandability of the
code.

4.Length of functions should not be very large:
Lengthy functions are very difficult to understand. That‟s why functions
should be small enough to carry out small work and lengthy functions
should be broken into small ones for completing small tasks.


5.Try not to use GOTO statement:
GOTO statement makes the program unstructured, thus it reduces the
understandability of the program and also debugging becomes difficult.
•

51. 50
Advantages of Coding Guidelines:
•Coding guidelines increase the efficiency of the software and
reduces the development time.
•Coding guidelines help in detecting errors in the early phases, so it
helps to reduce the extra cost incurred by the software project.
•If coding guidelines are maintained properly, then the software
code increases readability and understandability thus it reduces
the complexity of the code.
•It reduces the hidden cost for developing the software.

52. 51
Code Walkthrough
•Form a peer review
•A formal presentation of software architecture or source code to the
team members
•Team members asks questions and spot the errors
•Review sessions can be formal or informal
•Formal reviews – Hold Review meeting
•Recorder records all issues raised and creates a report.
•Intend is to find errors and uncover issues early on, so that these
don‟t get propagated to other phases

53. 52
Reference Model for Technical reviews
Review
Planning and
Preparation
Meeting
Structure
Correction
and
Verification
Roles
Individuals
Play

54. 53
Coding Inspection
•Deployed using pair programming
•Pair works and share ides together to tackle the complexities
of software development
•They continuously perform inspection on each other‟s
programs leading to earliest, most efficient form of defect
removal possible.
•They make sure they are focused on the task at hand.

55. 54
Cleanroom testing
•Pioneered by IBM, Formal approach to software development
•Used to build correctness verification in developed software
rather than testing
•Follows incremental planning, each increment is certified, and
integrated in proper time according to the plan.
•The Software component is divided into series of sub-
functions.
•To prove the correctness of the subfunctions, exit conditions
are defined for each subfunction, and a set of sub proofs
applied. If the exit condition is satisfied, the design must be
correct.

56. 55
Software Testing
•Testing is the process of exercising a program with the specific
intent of finding errors prior to delivery to the end user.

57. 56
What Testing Shows

(Pressman, R.S. (2010) Software Engineering: A Practitioner’s Approach. 7th Edition, McGraw Hill, New York.)

58. 57
Strategic Approach
•To perform effective testing, you should conduct effective technical
reviews. By doing this, many errors will be eliminated before
testing commences.
•Testing begins at the component level and works "outward" toward
the integration of the entire computer-based system.
•Different testing techniques are appropriate for different software
engineering approaches and at different points in time.
•Testing is conducted by the developer of the software and (for
large projects) an independent test group.
•Testing and debugging are different activities, but debugging must
be accommodated in any testing strategy.

59. 58
V & V
•Verification refers to the set of tasks that ensure that software
correctly implements a specific function.
•Validation refers to a different set of tasks that ensure that the
software that has been built is traceable to customer
requirements.
•Boehm [Boe81] states this another way:
•Verification: "Are we building the product right?"
•Validation: "Are we building the right product?"

60. 59
Who Tests the Software?
•(Pressman, R.S. (2010) Software Engineering: A Practitioner’s Approach. 7th Edition, McGraw Hill, New York.)