Object Oriented Modelling of the problem : Describing the problem, data and user requirements in the paradigm of Objects. Asking the client right questions to get out right requirements which may be hidden and describing them in designs.

In designing, we are concerned with the first two phases of the SDLC.

First two stages of SDLC :

1. Requirements gathering : Collecting, specifying and consolidating the SRC.

Talking to all the stakeholders, getting all technical, non-technical requirements, deciding and negotiating trade-offs with the client.

1. Design : Errors in this phase are hardest to remit. We need both a conceptual design and a technical design.

Conceptual design can capture the system as a set of interacting components. These components then, can translate into functions, classes, databases, elements, etc in the technical design.

Identifying the major components and relationships between them. This is where system software architecture comes into the picture. The design documents are expressed in diagrams which capture different views of the software system.

Check out different ways of gathering requirements from the customers. How to categorize and finally specify them in the SRS document.

Categories of Objects:

When we think of modelling the problem in OOP, we generally look for entity objects. Theobjects which are present in the physical world : The shopping cart, the account, the person, etc. However, the software consists of other types of objects as well which coordinate, provide utilities, perform control operations, provide interfaces, etc. It is important to recognize that a software does not consist just of entity objects.

1. Entity objects : Those which can be seen in the real world as well.
2. Boundary objects : The objects which appear at the boundary of different systems, providing interface between different services, etc. Eg : the data access objects(DAO) provide interface between the database and other systems, DTOs are used as returning and receiving objects from API calls, user interface objects, etc.
3. Control objects : These objects provide coordination among different objects, systems. They are used to ensure loose coupling between other objects.
4. Utility objects : These are the class of objects who perform random tasks. They generally consist of static functions and do not store any state information. Even if their instance is required, only one is sufficient for the whole program(The service objects).

Tradeoffs

Thereare always competing attributes in a software. We have to weigh their importance and include them accordingly. For example : too much security| user convenience, Nice UI with great animations, graphics | system performance and hardware utilization, Code quality | time to release the code, etc. Backward compatibility | maintainability.

Consider all consequences of any design decision.

Class Responsibility Collaborator

Conceptual Design : Components, responsibilities and connections. There should be a way to document it or arrange it. The solution is CRC. They help us organize our components into classes. Card has three sections : Class name, responsibilities and collaborators. We decompose the components such that they can be represented in terms of a class on a CRC card.