Object-Oriented Modeling (Module 1)
A month ago We start a new project in my company which is a logistics company and the new project is to build a fulfillment system to be running in our fulfillment center in Egypt and Saudi Arabia.
As a junior backend developer, I used to write new functions or models on our code base. My daily tasks are to take the stories and tasks from the product manager and start implementing them within my sprint. it was hard for me to start thinking about this project from scratch. So I found that I need to learn how to make design and how to put the first architecture of the program.
My friend suggests taking this specialization from the University of Alberta through Coursera. and this specialization you will learn how to apply design principles, patterns, and architectures to create reusable and flexible software applications and systems. You will learn how to express and document the design and architecture of a software system using visual notation.
Object-Oriented Modeling
This is the first course in this specialization and it is very important as a starting point for thinking about how to build a software system from scratch.
the term object-oriented is always related to coding as most of us are working with object-oriented programming languages. So you are building classes, interfaces dealing with objects and other object-oriented programming concepts like polymorphisms...etc.
but the meaning of object-oriented modeling here is a little bit different. We need to look at the problems with a high-level view and break downs then identify objects that we have
Objects may have specific details associated with them, which are relevant to users. For example, a person object may have details such as name, age, gender, and occupation. A place object may have a size or a name. An inanimate object may have dimensions or color. It is good practice to prepare for object-oriented design by accustoming yourself to thinking about the world around you in terms of objects, and the attributes those objects might have.
Design in the Software Process
When software is developed, it generally goes through a process. In simple terms, a process takes a problem and creates a solution that involves software.
To identify our problem We always start by building conceptual design mock-ups and technical design diagrams.
Conceptual Design
Conceptual designs are created with an initial set of requirements as a basis. The conceptual design recognizes the appropriate components, connections, and responsibilities of the software product.
conceptual mock-ups are visual notations that provide initial thoughts for how requirements will be satisfied.
Technical Design
Technical designs build on conceptual designs and requirements to define the technical details of the solution. The technical design brings this information to the next stage. it aims to describe how these responsibilities are met. The technical design is not finished until each component has been refined to be specific enough to be designed in detail.
By breaking down components more and more into further components, each with specific responsibilities, you get down to a level where you can do a detailed design of a particular component. The final result is that each component will have its technical details specified.
Technical diagrams visualize how to address specific issues for each component, as conceptual mock-ups are generally not specific enough to capture this information.
Satisfying Qualities
Qualities are achieved through satisfying functional and non-functional requirements, which in turn are the basis for the design process.
Functional requirements describe what the system or application is expected to do. A key quality to achieve by satisfying a functional requirement is that of correctness. For example, if you are designing a music app, the app must be able to download and play a song. The design needs to be able to outline a solution that correctly meets this requirement.
Non-functional requirements to satisfy might include performance, resource usage, and efficiency; these requirements can be measured from the running software. For example, the music app may have non-functional requirements to download music only to a certain memory limit. Other qualities that software often satisfies in non-functional requirements include reusability, flexibility, and maintainability. This helps inform how well the code of software can evolve and allow for future changes.
Class Responsibility Collaborator (CRC)
This technique is the use of Class, Responsibility, and Collaborator (CRC) cards. 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 your software design.
CRC cards 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 the collaborators on the right side of the card.