“Object-oriented” is associated with coding and software development. In general, this is true. The notion of being object-oriented can apply outside of the role of a developer. Object-oriented thinking at first glance involves examining the problems, breaking them down into parts, and thinking of those as objects.
Translating object-oriented modeling involves representing key concepts through objects in our software. Concepts have a wide range
By using object-oriented design our code stays organized, flexible, and reusable. In object-oriented thinking, often everything is considered an object, even if animated or live and they are all self-aware.
Requirement
When software is developed, it generally goes through a process. A process takes a problem and creates a solution. These iterations consist of taking a set of requirements based on the identified problem(s) and using them to create conceptual design mock-ups and technical design diagrams.
Many projects fail when this process is skipped over, especially when work immediately begins with coding, and there is a lack of understanding of the requirements and design. So, we must bear in mind that it is important to allot time to form the requirements and design, even if they are not perfectly established. The coding process relies on certain assumptions, and it can be difficult to change those assumptions once coding has begun. Requirements and design activities help us understand what assumptions we need so that we can create the right product.
When the initial set of requirements has been created, the next step in the process is to produce a conceptual design and technical design. This results in the creation of two different kinds of artifacts: conceptual mock-ups and technical diagrams.
Design – Conceptual Design
Conceptual designs are created with an initial set of requirements as a basis. It outlines the more high-level concepts of the final product. They are expressed or communicated through conceptual mock-ups.
Conceptual mock-ups are visual notations that provide initial thoughts for how requirements will be satisfied. They are often presented as wire-frames, which are a kind of blueprint or basic visual representation of the product, helping to clarify design decisions with clients and users by providing a simple way to illustrate and discuss how a product will work.
Mock-ups illustrate major components and connections, or relations between the components, allowing us to easily see what components are missing or may not work. Also, every component has a responsibility it needs to perform. Mock-ups do not outline technical details, because that falls outside the scope of conceptual design. Technical detail is related to a technical design that we will cover in the technical design section.
Object-Oriented – Class, Responsibility, Collaborator (CRC)
Class, Responsibility, Collaborator (CRC) cards are an important technique to help represent the components, responsibilities, and connections at a high level when forming the conceptual design. CRC cards help record and organize components into classes, identify component responsibilities, and determine how they collaborate. Therefore, they also help refine the components of our software design.
CRC cards are used also to refine the components of system design. They are designed with three sections: the class name at the top of the card, the responsibilities of the class on the left side of the card, and collaborators on the right side of the card.
To keep track of each candidate component and its responsibilities using a CRC card, we place a component’s name in the class name section and the responsibilities in the responsibilities section. Connections are captured in the collaborator’s section. Connections indicate other classes that the class at the top of the card interacts with to fulfill its responsibilities. These steps are repeated iteratively and new cards are created until all the components of the cards are identified for a system.
CRC cards have the purpose to coerce designers to keep breaking components down into smaller components and classes that can be individually described on a card. They are cheap, editable, and widely available. They help sort information into manageable pieces and allow us to physically reorganize our design.
So before we move on to technical design, bear in mind that the best practice is to form the conceptual design first. The clearer they are, the better will be the technical design, and the more likely our software will be built right
Design – Technical Design
Technical designs build on conceptual designs and requirements to define the technical details of the solution. In the conceptual design, the major components and connections, as well as their associated responsibilities for the software being developed, are outlined.
The technical design uses the outline of conceptual design to describe how these responsibilities are met until each component has been refined to be specific enough to be designed in detail. To accomplish this, the components are split into smaller and smaller components that are specific enough to be designed in detail. By breaking down components into further components, we get down to a level where we can do a detailed design of a particular component with their technical details specified.
To communicate technical design, technical diagrams are used. Technical diagrams visualize how to address specific issues for each component, once the conceptual mock-ups are generally not specific enough to capture this information. Many different technical diagrams can be used to describe the structure and behavior of components.
Object-Oriented – UML Class Diagram
CRC cards make it easy to communicate with the client, and they allow us to create designs without the distraction of code. However, a more sophisticated technique to communicate our needs is needed. That is the UML class diagram, also known as the class diagram. These class diagrams provide more detail than CRC cards and allow for easier conversion to classes for coding and implementation.
Every concept or class in a class diagram is represented with a box, as above. The class name is the same as the class name in our POJO or POCO class, the properties section is equivalent to member variables and the operations section is equivalent to methods in Object-Oriented Programming.