Abstract

• Object-Oriented Thinking
• Design in the Software Process
  • Requirements
  • Design
  • Compromise in Requirements and Design
• Design for Quality Attributes
• Class Responsibility Collaborator

Object-Oriented Thinking

Object-oriented modeling is a significant topic in this specialization. Before discussing this topic in depth, it is essential to learn how to think about problems and concepts as object-oriented.

You probably associate the term “object-oriented” with coding and software development. While that is true, the notion of being object-oriented can apply outside of the role of a developer.

Object-oriented thinking involves examining the problems or concepts at hand, breaking them down into component parts, and thinking of those as objects. For example, a tweet on Twitter or a product on an online shopping website could be considered
objects.

💡 By using objects to represent things in your code, the code stays organized, flexible, and reusable

Design in the Software Process

A process is generally iterative. 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, which can then be used to create a working software implementation, which must also pass testing. This process is repeated for each set of requirements, eventually creating a complete solution for the project.

Requirements

📌 Requirements are conditions or capabilities that must be implemented in a product, based on client or user requests. They are the starting point of a project—you must understand what your client wants.

To better understand requirements, imagine you are an architect building a house. Requirements allow you to understand what a homeowner wants in a house before you start building. The homeowner may tell you what rooms they want, but you may need to ask follow-up questions about what rooms may be missing from their list, what size the house and rooms might be, any constraints on the house based on restrictions, how clients want rooms to be placed, or what direction the house should face. These help you better understand what you will be building

Design

📌 When the initial set of requirements has been created, the next step is to produce a conceptual and technical design. This results in the creation of two different kinds of artifacts:
conceptual mock-ups and technical diagrams.

Conceptual Design: is created with an initial set of requirements as a basis. The conceptual design recognizes the appropriate components, connections, and responsibilities of the software product.

💡 The best practice is to form the conceptual design before moving on to the technical design. The clearer the conceptual design, the better the technical design, and the more likely your software will be built right.

Technical Design: build on conceptual designs and requirements to define the technical details of the solution.

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.

Compromise in Requirements and Design

💡 When in the design phase, there may need to be compromise in creating an acceptable solution. Constant communication and feedback are key to creating the right solution that meets client needs and works within any restrictions that may exist.

Design for Quality Attributes

This course has reviewed the importance of requirements and design in creating software. Sometimes, there are restrictions on a design that requires compromise. Besides software requirements based on desired functionality, there are also quality attributes to
define how well this functionality must work. But your decisions may also involve trade-offs in different quality attributes, such as performance, convenience, and security, and these attributes need to be balanced.

• 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.

  Non-functional requirements specify how well the system or application does what it does.

💡 Below are some common trade-offs in qualities for software design:
• Performance and maintainability – High-performance code may be less clear and less modular, making it harder to maintain. Alternatively, extra code for backward compatibility
may affect both performance and maintainability.
• Performance and security – Extra overhead for high security may lessen performance.

Class Responsibility Collaborator

CRC Cards

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 with each other. Therefore, they also help refine the components of your
software design.

• The Components

  • class name is at the top of the card.
  • the responsibilities on the left side of the card.
  • collaborators on the right side of the card.

  

💡 A key advantage of using CRC cards is that they allow you to physically reorganize your design. As each of the components is represented by a card, you can move related cards together, or situate cards to suggest relationships. This allows you to theoretically explore how your system will work and to identify any shortcomings in the design.