Google

One Liner - Creational Design Patterns

Creational Patterns deal with initializing and configuring classes and objects.

One liner definitions for creational patterns are given below:

Factory Method
Method in derived class creates associates

Abstract Factory
Factory for building related objects

Builder
Factory for building complex objects incrementally

Prototype
Factory for cloning new instances from a prototype

Singleton
Factory for a singular instance

Design Patterns - An Easy Way to Remember Common Design Patterns

Design patterns are well documented solutions to recurring problems in software design in given context.

Design Patterns can be classified as:

  • CREATIONAL
  • STRUCTURAL
  • BEHAVIORAL
Remember Code: CBS (Core Banking Solutions)

Creational Patterns are of following types:
  • Abstract Factory
  • Builder
  • Factory Method
  • Prototype
  • Singleton
Remember Code: ABFPS (Abraham Became First President of States)

Structural Patterns are of following types:
  • Adaptor
  • Bridge
  • Composite
  • Decorator
  • Facade
  • Flyweight
  • Proxy
Remember Code: ABCDFFP

Behavioural Patterns are of following types:
  • Mediator
  • Memento
  • Interpreter
  • Iterator
  • Chain of Responsibility
  • Command
  • State
  • Strategy
  • Observer
  • Template Method
  • Visitor
Remember Code: MMIICCSSOTV (2 MICS ON TV)

Do remember to visit computer-science-notes.blogspot.in later for a detailed easy to digest post on design patterns.


Java Interview Questions

1. Difference between Java and C++.
Hint: i) Java is purely object oriented ii) Java is Platform Independent

2. Difference between JDK, JRE, and JVM. Which one is required only to run Java Application

3. How Java is robust?

4. What are access modifiers in Java and what is default modifer?

5. Why there are no destructors in Java?

6. Explain various uses of static keyword.

7. What are abstract classes and how do they differ from interfaces?

8. How is multiple inheritance problem handled by Java?

9. Explain lifecycle of an Applet.

10. What are JDBC steps for connecting to database?

11. What are different types of JDBC drivers and what is thin driver?

12. How Swing is different from AWT?

13. Difference between class and object?

14. What are major characteristics of Object Orientation? Hint: Encapsulation, Inheritance, Polymorphism, Data Hiding, Abstraction.

15. Explain above characteristics with example.

Note: Study Java Swing for GUI development and JDBC for databases

Software Maintenance

Software maintenance is most costly phase. 80% of the budget is on maintenance with more than 3/4th engineers involved in maintenance activities.

Maintenance is inevitable for almost any kind of product but software maintenance is not same as hardware maintenance. It is so because software does not deteriorates over time.

Software maintenance is doing anything to software after delivery, typically, after acceptance testing.

Why maintenance cost is high?

  • future maintenance is not kept in mind while developing
  • systems to be maintained are unstructured
  • sometimes, complete development cycle to be executed for the change
    Solution: Follow non-linear life cycle like incremental development as enhancement done in increments is more manageable.

Maintenance Management
Includes:
  • development consideration: maintenance should be forethought throughout development, IPR, development and maintenance contract. Fixed price vs cost plus contract. Software engineering being new field, this has weakness
  • anticipated life cycles
  • scope of maintenance
  • initial product status
Types of Maintenance
  1. Preventive: during life cycle, extra effort to make it easier to maintain
  2. Corrective: rectify bugs while system is in use
  3. Adaptive: adapting to new platforms, OS, software and hardware interfaces
  4. Perfective: support new features, different functionality demanded by user, performance enhancement
Why maintenance is required?
  • Rate of hardware obsolescence
  • demand of user community to support
    • new platforms
    • new environments
    • enhanced features
      Comments: 
  • If software does some low level functions then it must also change with hardware change
  • If support environment changes then software must change for newer itself
  • Software may require change with change of OS
Maintenance Cost Factor = Technical Costs + Non-Technical Costs

Technical Costs = Quality of original product i.e. quality of development (Req Specs, Design, Code, Testing, Documentation

Non-Technical Costs = Applications, changes operating systems, hardware stability, system lifespan

Belady-Lehman Model of Maintenance Effort

M = P + K pow (c-d) where
 P = productive maintenance comprising analysis, coding, design, testing
 c = system complexity (fixes new errors introduced - 1 error for every 6 changes, structure is compromised
 d = familiarity of the staff with the system (new staff, low maintenance profile, specialisation)

Observations: 
  • Maintenance effort M is directly related to amount of maintenance carried out
  • But, exponentially related to system complexity and staff familiarity
Staffing for Software Maintenance Phase
Wrong: No creativity involved so place new staff or lame ducks is wrong and will lead to high maintenance costs
Right: Better have higher rated software engineers who has better understanding of SDLC and will not increase system complexity

Scrap the System?
  • maintenance cost too high
  • product no longer competitive
  • hardware cost is high
  • application environment is disappearing
  • technical viability - compromise performance, compromise reliability
   IBM considers a 12% change to an existing system as cut-off point in deciding to start a fresh

Software Maintenance Phase
  • understand the software
    • If documentation is good then follow Top-Down approach: evaluate design, plan approach, modify design, re-code
    • if no proper documentation then follow Bottom-Up approach: evaluate code, re code
      • if no proper documentation then cost is 4 times higher
  • generate maintenance proposals
  • predict consequences
  • modify code
  • cope with any ripple effect
  • regression test
  • distribute new versions
Retesting the Modified Code
  • Test
    • required change
    • for side effects
    • for degradation in quality
  • Perform Regression Testing
  • Update Regression test suite
   undocumented systems take longer time to change + No test data stored for them implies regression testing is impossible as ripple effect cannot be checked

Maintenance Tools
  • Tools that give information about the code e.g. cross references, flow analysers (data+control)
  • Tools that restructure the badly written unstructured code
  • Reverse Engineering tools that generates design model from code
  • Development tools that are required for new requirements and design needs to be modeled, new code produced and testing e.g. auto code generators
  • Automated Regression Testing tools
Belady and Lehman 3 Laws of Characteristics of Software Evolution
  1.  A software product must change continually or become progressively less useful
  2. The structure tends to degrade as more and more maintenance is carried out
  3. Over a program's lifetime, its rate of development is constant
       Elaboration of Laws:
         1. This is irrespective of how well the system was designed. Remember good products are 
         maintained and bad products are thrown away
         2. Addition to an existing system that is not intended to support it. If system is not re-designed 
         then it will become too complex. Quick fix solutions will only degrade program structure, 
         documentation becomes inconsistent and less helpful
         3. i.e. the rate at which code is written or modified is approximately same during development    
           and maintenance

Extreme Programming (XP)

Introduction
XP originated in mid 1990s by Kent Beck in collaboration with Ward Cunningham. It was first used in project Daimler Chrysler in 1996. XP practice is not new but how they interact is.

Extreme comes from taking the principles and practices to extreme lengths.

In a survey, it was found that 40% of the projects were late by 67% and 30% were over budget by an average of 127%. It is because of false assumptions about development process:

  • all requirements can be captured at start
  • requirements will not change significantly
  • complete architectural design can be specified start
  • developers will not take shortcuts in the process
  • developers must be rigidly controlled
XP improves a software project by addressing:
  • communication
  • simplicity
  • feedback
  • courageness
XP - New Terms
  • User Stories - functional requirements
  • Spikes - throwaway prototype
  • Velocity - measure of how much work is being done
  • CRC - Class, Responsibility, Collaboration cards
  • Re-factoring - evolving software architecture
  • Metaphor - picture of the system
  • Test Driven Development
XP Core Practices
  1. small and frequent releases
  2. continual planning of software release
  3. use of metaphor
  4. simple design
  5. continual testing (Test Driven Development)
  6. pair programming
  7. constant refactoring
  8. collective ownership
  9. continuous integration
  10. sustainable pace - max 40 hours/week
  11. use of coding standards
  12. collective coding

XP Roles
  • Manager - Overall Project Manager
  • Tracker - Monitor estimates and iteration progress
  • Consultant - external technical expert
  • Coach - expert in XP Process
  • Customer - writes stories, tests, and decides priorities
  • Programmer - design, write and test code
  • Tester - assist customer to write functional tests, run tests, maintain testing tools
XP Evaluation
  • Bottom-Up - design evolves through refactoring
  • designed for projects where requirements are initially unknown and/or continually changing
  • only suitable for small, co-located teams (2-10 developers)
  • testing is paramount - Test Driven Development
  • collective code ownership
  • minimal documentation e.g. no requirement specs
  • relies on the user knowing what they want
  • constant small software releases
  • emphasis on people and realistic timelines
References
  • www.extremeprogramming.org/rules/collective.html
  • ftp://ftp.sei.cmu.edu/pub/documents/.../xp-from-a-cmm-perspective.pdf



Agile Software Development

Background
In spring 2000, conference of gurus organised by Kent Beck agreed the need of Light methodologies. First meeting of Lightweight Method leaders were held in September, 2000. Later, in Feb 2001, second meeting was held at which they agreed the need for an alternative to document driven heavyweight process.

Agile processes when compared to their counterparts are often called lightweight, light, lean, internet speed while rigorous processes are called heavyweight, disciplined, bureaucratic, industrial strengths, plan-driven, document-driven.

Manifesto Statement
We are uncovering better ways of developing software and helping others to do so.
We value:

  • people and interactions over processes and tools
  • working software over comprehensive documentation
  • customer collaboration over contract negotiations
  • responding to change over following a plan
Misconceptions Addressed by Agile Manifesto
  • process is skill
  • documentation is understanding
  • formality is disciplined
  • in small teams, individuals are interchangeable
Principles of Manifesto
  • satisfy customer with frequent delivery (upto 6 weeks) of quality tested software ==> Measure of Progress
  • build projects around motivated individuals. Give them environment and support they need and trust them to do job
  • quality work is from self organising teams who communicate face-to-face regularly and monitor and adjust behaviour
  • welcome changing requirements, even in late development stages
Summary
  • short increments
  • experienced developer
  • onsite user experts
  • 2-8 people in a room
  • fully automated regression testing tools
  • agile methods are adaptive rather than predictive, people oriented rather than process oriented
A development method is agile when it is incremental, cooperative, adaptive, straight forward

Examples
XP, Scrum, DSDM

Salient Features of Windows 10

Windows 10 = Best features of Windows 7 and Windows 8 - Troublesome aspects of Windows 8


  1. Come back of Start Menu of Windows7 with switch-off/resizable tiles of Windows 8
  2. Transition from keyboard to touch
  3. Search including web results built into Start Menu
  4. Virtual Desktops i.e. multiple desktops for multi-tasking
  5. Improved Command Prompt - cut, copy, paste
  6. Cortana - personal digital assistant
  7. Hello - Face/Voice recognition for login
  8. Continuum - Seamless utilisation of devices - Start Menu changing to full screen mode when keyboard disconnected from Surface
  9. Revamped apps like Mail, Calendar, Photos etc
  10. Neat browser Edge with Curtana and note taking mode with draw on webpage capabilities
  11. Action Centre - Organised notifications from apps/settings etc
  12. Xbox Streaming with recording