Creational Pattern – Singleton : Ensure a class has only one instance and provide a global point of access to it.
Structural Pattern – Proxy : Provide a surrogate for another object to access to it.
Behaviour Pattern – Iterator : Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
S.O.L.I.D is an acronym for the first five object-oriented design(OOD) principles by Robert C. Martin, popularly known as Uncle Bob.
These principles, when combined together, make it easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or adaptive software development.
S.O.L.I.D stands for:
When expanded the acronyms might seem complicated, but they are pretty simple to grasp.
S – Single-responsiblity principle
O – Open-closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion Principle
S – Single-responsiblity principle: A class should have one and only one reason to change, meaning that a class should have only one job.
for example, An AreaCalculator class for calculating area for different shapes such as circle, rectangle etc. The output method of AreaCalculator class should only sum the areas of the provided shapes, it should not care whether the user wants the output in JSON or HTML or XML. To achieve a SumCalculaterOutputter class is used this to handle.
O – Open-closed principle : Objects or entities should be open for extension, but closed for modification.
This simply means that a class should be easily extendable without modifying the class itself.
for example, A method Sum on the AreaCalculator class is required to be able to sum the areas of more shapes, we would have to add more if/else blocks which goes against the Open-closed principle. Another method is to define the sum in the shape class and each shape will need to implement the interface. In the sum method of AreaCalculator class, we can check the shapes provided are actually instances of ShapeInterface and calculate the area.
Liskov substitution principle
This means that every subclass/derived class should be substitutable for their base/parent class.
For example Child classes must not 1)remove base class behavior 2)Violate base class invariants.
And in general must not require calling code to know they are different from their base type.
Interface segregation principle
A client should never be forced to implement an interface that it doesn’t use
for example, if there are two methods area() and volumne() in the shapeInterface, the shapes like cubes and need not be implement volume() because they dont have. To achieve this we have to create another ManageShapeInterface and implement it on both the flat and solid shapes.
Dependency Inversion principle
It states that the high level module must not depend on the low level module, but they should depend on abstractions
Reference:- https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design
V Model Unit Testing Starting from the bottom the first test level is “Unit Testing”. It involves checking that each feature specified in the “Component Design” has been implemented in the component. In theory an independent tester should do this, but in practice the developer usually does it, as they are the only people who understand how a component works. The problem with a component is that it performs only a small part of the functionality of a system, and it relies on co-operating with other parts of the system, which may not have been built yet. To overcome this, the developer either builds, or uses special softwareto trick the component into believe it is working in a fully functional system. Integration Testing As the components are constructed and tested they are then linked together to check if they work with each other. It is a fact that two components that have passed all their tests, when connected to each other produce one new component full of faults. These tests can be done by specialists, or by the developers. Integration Testing is not focused on what the components are doing but on how they communicate with each other, as specified in the “System Design”. The “System Design” defines relationships between components. The tests are organized to check all the interfaces, until all the components have been built and interfaced to each other producing the whole system. System Testing Once the entire system has been built then it has to be tested against the “System Specification” to check if it delivers the features required. It is still developer focused, although specialist developers known as systems testers are normally employed to do it. In essence System Testing is not about checking the individual parts of the design, but about checking the system as a whole. In fact it is one giant component. System testing can involve a number of specialist types of test to see if all the functional and non-functional requirements have been met. In addition to functional requirements these may include the following types of testing for the non-functional requirements: √ Performance √ Performance – Are the performance criteria met? √ Volume – Can large volumes of information be handled? √ Stress – Can peak volumes of information be handled? √ Documentation – Is the documentation usable for the system? √ Robustness – Does the system remain stable under adverse circumstances? There are many others, the need for which is dictated by how the system is supposed to perform. Acceptance Testing Acceptance Testing checks the system against the “Requirements”. It is similar to systems testing in that the whole system is checked but the important difference is the change in focus: Systems testing checks that the system that was specified has been delivered. Acceptance Testing checks that the system will deliver what was requested. The customer should always do acceptance testing and not the developer . The customer knows what is required from the system to achieve value in the business and is the only person qualified to make that judgment. This testing is more of getting the answer for whether is the software delivered as defined by the customer. It’s like getting a green flag from the customer that the software is up to the expectation and ready to be used.
Requirement analysis: 1.need of the project, 2.cost of the project 3.what are the benfits and advantages of the project 4.Identify the requirement 5.Identify the scope of the project 6.agrement with any development company to develop the software
Right of customer : To set objectives, to know the duration of project
to decide which features are in and which are out, to make reasonable changes to requirements throughout the course of the project and to know the costs of making those changes, to know project’s status clearly and confidently, To be apprised regularly of risks that could affect cost, schedule, or quality, and to be provided with options for addressing potential problems, To have ready access to project deliverables throughout the project
Classic Waterfall model: is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Requirement Analysis, Design Development, Integration, Testing, Installation and Maintenance.
Advantages of Waterfall Model:- 1. Clear project objectives. 2. Stable project requirements. 3. Progress of system is measurable. 4. Strict sign-off requirements.
Disadvantages of Waterfall Model 1. Time consuming 2. Never backward (Traditional) 3. Little room for iteration 4. Difficulty responding to changes 5.A working version of the program will not be available until late in the project time-span
The V-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The Verification Phases are on the Left hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the Right hand side of the V.
Phases:- Requirement Analysis – acceptance testing , System Design – System Testing , Architectural Design –Integration Testing, Module Design – Unit Testing Coding(start)
Spiral SDLC Model, the development team starts with a small set of requirements and goes through each development phase (except Installation and Maintenance) for those set of requirements. Based on lesson learned from the initial iteration (via a risk analysis process), the development team adds functionality for additional requirements in ever-increasing “spirals” until the application is ready for the Installation and Maintenance phase (production). Each of the iterations prior to the production version is a prototype of the application.
In Top-down model,high-level requirements are documented, and programs are built to meet these requirements. Then, the next level is designed and built. This approach a good fit when the application is a new one and there is no existing functionality that can be incorporated into the new system
n the Bottom-up SDLC model, the lowest level of functionality is designed and programmed first, and finally all the pieces are integrated together into the finished application he disadvantage of the Bottom-up model is that an extreme amount of coordination is required to be sure that the individual software components work together correctly in the finished system.
Hybrid SDLC model combines the top-down and bottom-up models. Using the menu driven application example, the design team primarily works top down, but the development team identifies two types of lower level components to work on at the same time as the high-level components.
Rapid Application Development (RAD) was introduced as a better way to add functionality to an application. The main new tenant of RAD compared to older SDLC models is the use of prototypes. After a quick requirements gathering phase, a prototype application is built and presented to the application users. Feedback from the user provides a loop to improve or add functionality to the application
Model-driven engineering (MDE) is a software development methodology which focuses on creating models, or abstractions, more close to some particular domain concepts rather than computing (or algorithmic) concepts. It is meant to increase productivity by maximizing compatibility between systems, simplifying the process of design, and promoting communication between individuals and teams working on the system.
Chaos model is a structure of software development that extends the spiral model and waterfall model. The chaos model notes that the phases of the life cycle apply to all levels of projects, from the whole project to individual lines of code.
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. A set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.
Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change. It is a conceptual framework that focuses on delivering working software with the minimum amount of work.
Agile values:-
Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
The Agile Manifesto is based on twelve principles
Customer satisfaction by rapid delivery of useful software
Welcome changing requirements, even late in development
Working software is delivered frequently (weeks rather than months)
Close, daily cooperation between business people and developers
Projects are built around motivated individuals, who should be trusted
Face-to-face conversation is the best form of communication (co-location)
Working software is the principal measure of progress
Sustainable development, able to maintain a constant pace
Continuous attention to technical excellence and good design
Simplicity—the art of maximizing the amount of work not done—is essential
Self-organizing teams
Regular adaptation to changing circumstances
UML Unified Modeling Language (UML) is a standardized general-purpose modelling language in the field of software engineering.UML diagrams represent two different views of a system model:
Class diagram: the class diagrams describes the structure of a system by showing the system’s classes, their attributes, and the relationships among the classes.
Component diagram: depicts how a software system is split up into components and shows the dependencies among these components.
Composite structure diagram: describes the internal structure of a class and the collaborations that this structure makes possible.
Deployment diagram: serves to model the hardware used in system implementations, and the execution environments and artifacts deployed on the hardware.
Object diagram: shows a complete or partial view of the structure of a modeled system at a specific time. Package diagram: depicts how a system is split up into logical groupings by showing the dependencies among these groupings.
Data modelling is a process used to define and analyze data requirements needed to support the business processes within the scope of corresponding information systems in organizations. Therefore, the process of data modeling involves professional data modelers working closely with business stakeholders, as well as potential users of the information system.
There are three different types of data models produced while progressing from requirements to the actual database to be used for the information system.[2] The data requirements are initially recorded as a conceptual data model which is essentially a set of technology independent specifications about the data and is used to discuss initial requirements with the business stakeholders. The conceptual model is then translated into a logical data model, which documents structures of the data that can be implemented in databases. Implementation of one conceptual data model may require multiple logical data models. The last step in data modeling is transforming the logical data model to a physical data model that organizes the data into tables, and accounts for access, performance and storage details. Data modeling defines not just data elements, but also their structures and the relationships between them.[3]
Data modeling techniques and methodologies are used to model data in a standard, consistent, predictable manner in order to manage it as a resource. The use of data modeling standards is strongly recommended for all projects requiring a standard means of defining and analyzing data within an organization, e.g., using data modeling:
to assist business analysts, programmers, testers, manual writers, IT package selectors, engineers, managers, related organizations and clients to understand and use an agreed semi-formal model the concepts of the organization and how they relate to one another
to manage data as a resource
for the integration of information systems
for designing databases/data warehouses (aka data repositories)
Papooze 