design

• Requirements in software engineering are statements in natural language of user expectations of system and system requirements are descriptions in natural language of functions, services, and operational constraints.
• Functional requirements in software engineering are what the system should do, reaction to specific scenarios & data specifications.
• When a student is constructed, it should automatically have the the next unique student number, but its programme of study should be passed as parameter.
• Non-functional requirements in software engineering are global statements on the system and not directly concerned with specific services to users.
• There are many ways to specify requirements in software engineering, including natural language, tables and diagrams, UML, logics, e.g., Propositional and Predicate Logic, Formal Specification Languages, e.g., CASL, Process Algebras, e.g., CSP.
• UML 2.0 has 13 diagram types categorised into structural and behavioural diagrams.
• Understanding every line of code in Facebook source is extremely hard, but the problem can be divided into smaller components and precisely defined how these bits work.
• Cars don’t have all functionalities lumped together, everything is divided into components and understanding pistons won’t help with fixing your windshield wipers.
• Requirements specification in software engineering is precisely what software should do, and its limitations.
• Design in software engineering is the system of how software fulfils requirements, including system of how software fulfils requirements, description of public behaviour of components, communications between components, and implementation.
• History of software abstraction includes top-down design/structured programming, which abstracts the algorithmic process into stages, and strongly related to mathematical functions.
• Abstract Data Types (ADTs) in software engineering specify some data to be stored and precise operations on that data, abstracting away implementation details.
• Operations and data are always present in object-oriented design.
• Applications are complete programs meeting specifications.
• A class is a precisely defined unit of the system.
• Classes are the components of the design.
• Encapsulation groups data and operations together and hides details from the rest of the system.
• Data and inner workings of an object can be treated as private information.
• Functionality of a component should also never be duplicated.
• Data is stored by component as attributes.
• Operations are executed on the data as methods.
• A class is a component that has a role to play in our system, such as pistons, brakes, and windshield wipers.
• Duplication of data should never be done.
• Group of methods for an object is its behaviour.
• A class is a blueprint and an instance of a class or object is an actual instance of the class where all attributes given values.
• Responsibilities of a class include the data it is responsible for (attributes) and the operations it can execute on that data (methods).
• Black box code allows users to only have to see public methods.
• Design goals include maintainability and extensibility.
• A class is represented by a rectangle with 3 areas: the class name in the first row, attributes in the second row, and operations in the final row.
• A class consists of some data that it stores and some operations that it can execute on the data.
• Object-oriented design helps with this goal.
• Design goals include generalisability and maximum reusability.
• Software reusability is a major goal of good design.
• A class lives up to its responsibilities and does what it says on the tin.
• Software component: Reusable code.
• Public methods define how the class interfaces with the world.
• Classes help organise the code and achieve this goal.
• In UML, attributes to instance variables are represented as attributes.
• In UML, static is indicated with an underline and is associated with the class (and not with instances).
• In UML, behaviours to methods are represented as methods.