## 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. ### 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** 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 ![Untitled](https://i.pinimg.com/originals/95/b3/55/95b3551a487c0f2db44da47ff773e237.jpg) **Design** **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. **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 ### 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. ### 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. ![Untitled](http://agilemodeling.com/images/models/crcCardLayout.jpg)

ahmedelkady

Object-Oriented Analysis and Design (part 1)

Join Our Newsletter. No Spam, Only the good stuff.