INF2011S Study Material PDF

Lesson 1.1 - Design Key Term: Definition of Systems Design The objective of design is to define, organise, and structure the components of the final solution to serve as a blueprint for development. Systems analysis provides the starting point for systems design. Systems design: This level of de...

Lesson 1.1 - Design Key Term: Definition of Systems Design The objective of design is to define, organise, and structure the components of the final solution to serve as a blueprint for development. Systems analysis provides the starting point for systems design. Systems design: This level of design focuses on the system\'s high-level architecture, including structural elements and standards. This encompasses the hardware and network infrastructure, how different sub-systems interact, and standards for elements such as screens, reports, and help systems. Detailed design: This goes deeper than the initial analysis to provide specific system specs. It includes class design, which defines attributes and methods. It also covers the implementation of classes for the user interface and business logic, sequence design to guide software methods, UI and report design, database design, and security and controls design. Measurable Objectives in Design: These objectives are used to determine if design requirements have been met. They should be quantifiable and testable, following the **SMART criteria: Specific, Measurable, Actionable, Realistic, and Time-Based.** Specific: Objectives should have a clear meaning and avoid ambiguity. For example, instead of aiming for \"more visitors,\" specify a target number or percentage increase. Measurable: Design objectives should be quantifiable to track progress and determine success. For instance, instead of focusing on \"improving user morale\" which is subjective, aim to \"decrease user sick leave by 20%,\" which can be measured. Actionable: Objectives should be achievable through concrete design solutions. Instead of aiming for users to \"read articles completely,\" focus on \"increasing user engagement on articles.\" This can be achieved through design elements such as upvote buttons, feedback forms, or commenting sections. Realistic: Objectives should be attainable within given constraints. For instance, aiming for \"every visitor to sign up\" might be overly ambitious. Time-Based: A clear timeframe should be defined for achieving the objectives. Instead of vaguely aiming to \"increase site traffic,\" specify a target like \"acquire 1,000 users monthly for six months.\" **Qualities of Design** These qualities assess how well non-functional requirements are addressed alongside functional ones. While analysis emphasizes doing the right things, design focuses on doing things right. **Functional:** The system should effectively perform all its stated functions, fully meeting documented requirements. **Efficient:** The system should perform its functions using minimal time and resources like disk space, processing power, and network capacity. Design strives for optimal solutions. **Economical:** This considers both the initial setup costs (hardware and software) and the ongoing running costs (Total Cost of Ownership) of the system. **Reliable:** The system should be resistant to both hardware and software failures. It must reliably maintain data integrity. Thorough testing contributes to reliability. **Secure:** The system must have safeguards against unauthorized access and malicious attacks, both internal and external. This can be achieved through measures like passwords and firewalls. **Flexible:** The system should be adaptable to changing needs over time. It should also be configurable to handle different situations based on user-adjustable settings. **Buildable:** The design should be clear and manageable for programmers to translate into code. A good design aligns with the development language\'s features. **Manageable:** A well-designed system allows project managers to accurately estimate the workload for different sub-systems. It allows for the independent completion and testing of sub-systems without interference from other parts still under development. **Maintainable:** The system should be easy to maintain to minimize costs and effort. **Usable:** The system should provide a positive and productive user experience, incorporating principles of good Human-Computer Interaction (HCI). **Reusable:** Designers should strive for reusability by: 1.Incorporating inheritance to reuse components within the system. 2.Implementing design patterns, which offer templates for reusable elements. 3.Reusing existing classes or components where possible. **Elegant-Beautiful:** A well-designed system should be delightful to use, encouraging user engagement. Lesson 1.2 - Architecture What is a System? A System is a set of connected components which form a complex whole which accomplishes a specific function - e.g. Respiratory & digestive systems. It serves as a blueprint for designing, building, and deploying systems. What is Architecture? The Architecture of a system is the fundamental organisation of a system, its components, their relationships to each other and to the environment. Cloud Services Architectures - 5 **Cloud services:** These are on-demand services, made available to users over the internet by cloud computing providers. **IaaS (Infrastructure as a service)** Provides users with the fundamental computing resources, such as virtual machines, storage, and networking, allowing them to build and manage their own platforms and applications on top of this infrastructure. Users have a high control over the operating systems and software. An example is **Amazon Web Services (AWS).** **PaaS (Platform as a service)** Providing a pre-configured platform for developing, deploying, and managing applications. Users can focus on application development without managing the underlying infrastructure. An example is **Heroku**. **SaaS (Software as a service)** Delivers ready-to-use software and applications that run on cloud infrastructure i.e. **Office 365.** **BaaS (Backend as a Service)** Provides cloud-based backend services for mobile and web applications, including data storage, user authentication, push notifications, and social media integration. An example is **Firebase**. **FaaS (Function as a Service)** Allows developers to deploy and run individual functions or pieces of code in the cloud without managing servers. An example is **AWS Lambda** Client/server architecture A software design pattern where an application is divided into two main parts: **Client:** Typically, a user interface (UI) component that runs on the user\'s device, it sends requests to the server for data or processing. **Server:** A more powerful computer that processes client requests, manages data storage, and sends responses back to the client. Three-Layer architecture Divides an application into three interconnected layers: **View layer:** Handles the user interface. **Logic layer:** Contains the business logic and rules of the application. (Implement functions) **Data layer:** Functions to access data. Application programming interface (API) APIs act as intermediary interfaces, following a set of rules and specifications that define how software components or systems interact with each other. eg. YouTube. They: **Define interactions:** Specifies the types of requests that can be made (e.g. retrieving data, creating a new user, making a payment), how to make those requests (e.g. using specific URLs, methods, or headers), and the data formats that should be used (e.g. JSON, XML). **Data formats and conventions:** Establishes standard ways to structure and exchange data, ensuring that different applications can understand each other. **Extension mechanisms:** May provide ways for developers to extend existing functionality or integrate with other systems, enhancing flexibility and customisation. Web protocols Specific protocols used for communication on the World Wide Web, enabling web browsers and servers to exchange data and render web pages. Examples include: **HTTP (Hypertext Transfer Protocol):** Defines the format for web content transfer. **HTTPS (Hypertext Transfer Protocol Secure):** A secure version of HTTP that encrypts communication between the client and server, protecting sensitive information from unauthorised access. HTTPS uses SSL (Secure Sockets Layer) certificates to establish a secure connection. A diagram of a network diagram HOW COMPONENTS ARE INTERCONNECTED  Lesson 1.3 - Class Design **Object-Oriented Design** This is a software development process where detailed object-oriented design models are created. Used by programmers for writing and testing programs. What are classes? A class is a category or classification used to describe a collection of objects. It acts as a blueprint or template for creating objects. It defines the structure and behaviour of objects. A class doesn\'t physically exist until the program runs and creates an instance of that class (an object). **Classes can be categorised as either**: **Domain classes** (describing things in the problem domain) or **Design classes** (describing objects in the system domain) **Object:** Represents a real-world entity within a system and can interact with other objects. It possesses attributes (data), identity, and behaviour (methods). Objects are created based on a class definition, acting as an instance of that class. **Design Class Diagram (DCD)**: This diagram displays objects within a system, outlining their attributes and methods. A diagram of a company Description automatically generated with medium confidence **Domain Model Class Diagram:** A visual representation of the things within the user\'s problem domain. It uses rectangles (representing classes) with sections for names and attributes, and lines to show relationships (associations) between these classes. **Association:** Represents the relationship between classes in a diagram. It signifies how objects of one class are connected to or interact with objects of another class. (0, 1, or many \*) to clarify the nature of the relationship. **Aggregation:** A type of relationship where one class represents a part of another class (whole/part relationship). In aggregation, the \"part\" can exist independently from the \"whole.\" **Composition:** A stricter form of aggregation where the \"part\" cannot exist independently from the \"whole.\" If the \"whole\" is deleted, the \"part\" ceases to exist as well. **Inheritance:** A mechanism where subclasses inherit attributes and methods from their superclasses. **Generalization/Specialization:** Represents an inheritance relationship where classes are ranked from general to more specific. This allows subclasses (specialized classes) to inherit attributes and behaviours from their superclasses (general classes). For instance, \"Motor vehicles\" would be a superclass, and \"Cars,\" \"Trucks,\" and \"Motorcycles\" would be subclasses. **Abstract Class:** - A class that cannot be instantiated (no objects can be created directly from it). - Abstract classes serve as templates for more specific concrete classes. **Concrete Class:** - A class that can be instantiated, meaning objects can be created from it. - These classes represent actual, tangible entities in the system. **Persistent Class:** - A class whose objects continue to exist even after the system shuts down. - Data associated with these objects is saved (usually in a file or database) and can be retrieved later. **Controller Class:** - Acts as an intermediary between boundary classes (user interface) and entity classes (data). - It receives requests from the boundary classes and directs them to the appropriate entity classes for processing. **Attributes** Represent the properties or characteristics of an object. Defined by: **Visibility:** Indicates (+ or −) if an attribute can be directly accessed by other objects. They\'re usually private (−) to ensure data protection and accessed through methods. **Attribute Name:** Uses lower camel case notation (e.g., accountNumber). **Type Expression:** Specifies the attribute\'s data type, like String, Integer, Double, Date. **Initial Value:** The default value assigned to the attribute when an object is created. **Property:** Specifies any additional characteristics of the attribute, like {key} for primary keys. **Method Signature** Defines how a method is invoked and provides essential information about the method, including: **Visibility:** Indicates (+ or −) whether other objects can invoke this method. Public (+) methods are accessible from anywhere, while private (−) methods are only accessible from within the class itself. **Method Name:** Uses lower case with a verb-noun format (e.g., calculateBalance). **Parameters:** Input values passed to the method when it\'s called. **Return Type:** The type of data the method sends back after execution. **Class-Level Method (Static Method):** A method associated with the class itself rather than with individual objects. It\'s indicated by underlining the method name and often used for operations that apply to the class as a whole. For example, a class-level method might be used to count the total number of instances of a class. **Class-Level Attribute (Static Attribute):** An attribute associated with the class itself rather than with instances of the class. Like class-level methods, it\'s underlined. It stores data that\'s shared among all objects of the class. **Derived Attribute:** An attribute whose value is calculated or derived from other attributes. For example, \"availableBalance\" might be calculated based on \"balance\" and \"overdraftLimit.\" **Constructor:** A special method used to create instances (objects) of a class. **Get Operations (Accessor):** Methods to retrieve the value of an object\'s attributes. **Set Operations (Mutator):** Methods to modify the value of an object\'s attributes. GRASP (General Responsibility Assignment Software Patterns) A set of nine principles that guide the assignment of responsibilities to objects during software design. These principles help create systems that are more maintainable and understandable. The nine principles are: 1\. Information Expert The class with the most knowledge about something ought to be responsible for that thing. Responsibilities include "knowing" and "doing". Start assigning responsibilities by clearly stating them. Objects know about other objects (associations). 2\. Creator Who should be assigned the responsibility to create objects? Solution: Whoever is closest to it. If A aggregates B, A creates B (aggregation). If A contains B, A creates B (composition). If A records instances of B, A creates B. If A closely uses B, A creates B Step I: Closely look at domain/design model and ask: Who should be creating these objects? Step II: Search for the classes that create, aggregate, contain etc. Step III: Assign the responsibility of creation to those classes 3\. Controller Who should be responsible for handling an input system event? Solution: A class representing the overall system, device or subsystem or a use case scenario within which the system event occurs. 4\. Low Coupling Coupling is a measure of how strongly one class is connected to or has knowledge of or relies/depends upon the other classes. How to encourage reuse and reduce the impact of change? Solution: Assign the responsibility to minimize connectedness (coupling) How low coupling can be achieved: Step I: Closely look for classes with many associations to other classes. Step II: Look for the methods that rely on a lot of other methods in other classes i.e. dependencies Step III: Rework the design so as assign responsibilities to different classes in such a way that they have lesser association and dependency (loose coupling). 5\. High Cohesion High Cohesion refers to how single-minded a module (class, object, or method) is within a system. How to keep complexity manageable? Solution: Class should represent only one thing, and a method should solve only a single task. How can high cohesion be achieved: Step I: Closely look for classes with probability of many responsibilities i.e. classes with too few or disconnected methods. Step II: Look for the methods which do a lot (look for method names having words like "AND", "OR") Step III: Assign a responsibility in such a way that all the responsibilities in a class are related (cohesive) 6\. Polymorphism Where to assign responsibility to handle related but varying elements based on element type? Solution: Assign the responsibility to the subtype. How to achieve this principle: Step I: Identify classes/types which would have the behaviour changing slightly Step II: Look for the methods which use conditional statements Step III: Assign a responsibility to a type for which the behaviour varies 7\. Pure Fabrication Give responsibility to an artificial class to fix high cohesion and low coupling (New Class to handle loaded work) eg. Sales handling all DB sales relations. 8\. Indirection Indirection is used to support security by directing messages to an intermediate class in a firewall. How to combine low coupling and high potential for reuse? Solution: Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled. A design principle that states an intermediate class is placed between two classes to decouple them but still link there. Eg. A controller class between U I classes, and problem domain classes. 9\. Protection from Variations Protection from variations principle states that parts of a system unlikely to change are separated (protected) from those that will surely change. Ensure current or future changes don't affect the whole system. Assign responsibility to stable interfaces. 1\. Separate user interface forms and pages that are likely to change, from application logic. 2\. Put database connection and SQL logic that is likely to change in separate classes from application logic. 3\. Use adaptor classes that are likely to change when interfacing with other systems If deciding between two alternative designs, choose the one where there is protection from variations Lesson 1.4 - Systems Sequence Diagrams What is a System Sequence Diagram? A System sequence diagrams (SSDs) is a UML diagram that shows the inputs and outputs for a specific use case as messages. It depicts the messages exchanged between an actor and the system.  Actor: This refers to the external entity (like a user or another system) that interacts with the system. System: The systems internal processing is not shown. The focus is solely on the messages exchanged between the actor and the system boundary. Messages: Represent communication between the actor and the system. They are categorized into two types: Input Messages: Sent from the actor to the system, initiating an action or requesting a service. (Solid Line) Output Messages: Sent from the system back to the actor, typically in response to an input message. They often represent the results of an operation or a confirmation. (Dashed Line) System Sequence Diagram (SSD) Notation Message Notation for SSD: A close-up of a note Description automatically generated \~The \"\[true/false condition\]\" is optional and indicates a condition that must be met for the message to be sent. \~An asterisk (\*) indicates repeating or looping of the message. \~Message-name is the description of the requested service written as a verb-noun. \~Parameter-list (with parentheses on initiating messages and without parentheses on return messages) shows the data that are passed with the message. \~\"Return-value\" denotes the data returned from the message and is assigned using ": =\". Frame: An optional element in an SSD used to enclose a group of messages and represent specific conditions or alternative flows. Types of frames include: Optional Frame (Opt): Indicates that the messages within the frame may or may not be sent based on a specified condition. Alternate Frame (if-else): Represents alternative message flows. Only one of the paths within the frame will be executed based on a condition. Lesson 1.4b - Detailed Sequence Diagrams What is a Detailed Sequence Diagram?  An expanded version of the SSD, created during the design phase, that provides a more detailed view of interactions within the system for a specific use case. It includes not only the actor and system but also the internal objects and their collaborations. Understanding Sequence Diagrams Lifeline: The dashed line under the object which serves as an origin point and a destination point for messages. Activation bar: The vertical box on a lifeline which indicates the time period when the object is executing based on the message. It is used to indicate that an object is active (or instantiated) during an interaction between two objects. A close-up of a computer code Description automatically generated Lesson 1.5a - UI Design User Interface **The user interface (UI)** is the point at which human users interact with a computer, website or application. The UI encompasses all elements that a user interacts with, including buttons, icons, menus, and the overall visual design. **Visual Language** in UI design refers to the overall visual style and aesthetic of the interface. This encompasses elements such as colour palettes, typography, imagery, and the overall layout of elements. User Experience (UX) A concept that encompasses a user\'s overall experience while interacting with a product or service. UX focuses on making the interaction enjoyable, efficient, and satisfying. **Usability** is a key aspect of UX design that refers to the ease with which users can learn to use a product or service. Easy to navigate and forgiving of errors. **Components of the User Interface:** **Metaphors**, in the context of HCI, are used to relate familiar concepts to users to help them understand and navigate unfamiliar digital environments. **Direct Manipulation Metaphor** is one where objects on the screen are designed to resemble and behave like physical objects, allowing users to interact with them in a more intuitive way. This often involves actions like dragging, dropping, and resizing. **Desktop Metaphor** organizes the display screen to resemble a physical desktop, with icons representing files, folders, and applications. **Document Metaphor** presents data to users in a familiar document-like format, often resembling pages or forms. **Dialog Metaphor** simulates a conversation between the user and the computer. This can be seen in systems that provide prompts, ask questions, and guide the user through a series of steps to complete a task. **KISS (Keep It Simple, Stupid)** is a design principle that emphasizes simplicity and clarity. In UI design, KISS encourages designers to create interfaces that are easy to understand and use. **Principles of UI Design: (Important)** 1\. Human Interface Objects Affordable -- icons and buttons suggest a function. Eg. Visibility -- immediate feedback and ability to see available functions. 2\. Consistency -- across platforms. 3\. Continuity -- consistency across releases. 4\. Discoverability -- clues to help user find "hidden" features. Eg. mouse hovers, tooltips. 5\. Closure -- clearly defined begin and end. Eg. Saving, undo features. 6\. Readability and Navigation -- text readable and pages have clear reversable navigation. 7\. Usability and Efficiency -- Shortcuts for experienced users, meaningful error messages. Lesson 1.5b - Report Design Report Design Involves the planning and creation of effective reports that present information from a system in a clear, concise, and organized manner, tailored to the specific needs of the intended audience. **Real-time** reports provide up-to-the-minute data as transactions or events happen, reflecting the most current state of operations. **Drill Down** allows users to access more detailed information by clicking on a summary item. For example, a sales report might summarize sales by region. **Key Performance Indicators (KPIs)** are measurable values that demonstrate how effectively a company is achieving key business objectives. **Designing Reports, Statements, and Turnaround Documents** **Operational reports** Provide information about the day-to-day operations of a business. They are often used to track performance, identify trends, and make operational decisions. Examples of operational reports include sales reports, inventory reports, and production reports. **Detailed reports** Provide comprehensive information about specific business transactions or events. Provides a detailed breakdown of information for a specific thing. For example, a detailed sales report might list every sales transaction made during a specific period. **Summary reports** aggregate data to provide a concise overview of performance for a specific period. Focusing on key totals, averages, or trends. For example, a sales summary report might show total sales revenue, average order value, and sales growth compared to the previous period **Exception reports** Highlights data points or events that fall outside predefined norms or thresholds. These reports help identify anomalies, potential problems, or areas that require attention. **Executive Reports** Tailored for high-level executives and typically provide a strategic overview of organizational performance. They focus on key performance indicators (KPIs), trends, and insights that are relevant to high-level decision-making. BI / Analytics A data management solution to track and analyze past data and help predict future trends and therefore make better business decisions. BI: What and how it happened in the past, ID trends without digging into why or future predictions. Analytics: Deals with Why's of past happenings (contributing factors and causes) and uses it to predict future. C\# Section CLASSES AND OOP Classes: \- Blueprint for a specific object \- a collection of objects of a similar type \- Basically a way of modelling real life objects Object: \- An instance of a class \- Block in memory that has been configured according to the "blueprint" ---\> Class \- An object is a combination of Fields and Methods \- Instances can be stored in variables, collections \- Objects have a state(fields) and behaviour(methods) Characteristics of a class/object 1.Accessibility level: private, public.. 2.Class name 3.Fields: Variables ---\> Default accessibility is private 4.Properties: Helpers for private fields(get and set) 5.Methods: Actions Abstraction Principle of OOP used to hide implementation details, only showing relevant info:  Encapsulation Mechanism of wrapping data and code, variables are hidden from other classes and can only be accessed through methods: A screenshot of a computer code Description automatically generated Inheritance Principle of OOP that allows you to reuse, extend and modify behaviour defined in other classes. baseClass (a class with fields, properties, methods) derivedClass is the inheritor, can only have 1 direct baseClass class (Single inheritance) A Derived class gains all members except Con- and Destructors eg. Using base constructor in derived Polymorphism Principle of OOP that works when there is inheritance, allowing the use of a method to do different tasks \--\> One method definition There are 2 types Static and Dynamic Static Polymorphism Static Binding (Early) ---\> Linking a function with an object at compile time Method overloading ---\> Same method name, different parameters (applies with constructors)  Dynamic Polymorphism 1.Declare virtual methods in base class 2.Can override the methods, add own implementation A screenshot of a computer program Description automatically generated **\ ** **DATABASES** **LAYERED ARCHITECTURE** - **Presentation (boundary classes) - Presents information to user, GUI** - **Application logic (control classes) - Coordinates application activity, no business logic, does not hold state of business objects, holds state of an applications tasks progress** - **Domain (entity classes) - Contains business logic info, the rules and use-case** - **Database - DBMS layer, can be accessed through business services layer (Business logic) or user services layer (UI)** **ACITVEX DATA OBJECTS (ADO)** - **Set of classes that allow data services** - **A programming interface to access data in a database** **ADO COMPONETS** - **Data providers - a set of components such as a Connections** - **Data objects - is a copy of the data in the data source---\> A dataset is an in-memory database, a set of DataTable objects.** - **Data adapter - retrieve data from source and populate dataset ---\> write back changes to data source. Uses Connection object to connect, uses Command object to retrieve and write data.** **\ ** **COLLECTIONS AND ADO** **Collections** **When looking for ways to group you can either create an array of objects or create a collection of objects.** - **Collections are preferred as they are flexible While arrays are fixed in size.** - **Collections are classes specialised for data retrieval and access.** - **They contain methods such as Remove, Navigate, Search..** **using System.Collections.Generic and System.Collections.ObjectModel\ ** **More On GRASP** **Part I: Introduction** - **Software Patterns and GRASP:** Defines software patterns as reusable solutions to common design problems, introducing GRASP as a set of principles for assigning responsibilities in object-oriented design. - **Understanding Responsibility:** Explores the concept of responsibility in software design, differentiating between \"knowing\" and \"doing\" responsibilities of objects. **Part II: Information Expert** - **Assigning Responsibilities:** Presents the Information Expert pattern, advocating assigning responsibilities to the class with the most relevant information to fulfil them. - **POS System Example:** Illustrates Information Expert with a Point-of-Sale system example, demonstrating how responsibility for calculating sales totals is distributed among classes. **Part III: Creator** - **Responsibility for Creation:** Discusses the Creator pattern, guiding the assignment of object creation responsibility to classes with existing or aggregation relationships. - **POS System Example (Continued):** Extends the POS example to show how \"Register\" creates \"Sale\" and \"Sale\" creates \"SaleLineItem\", adhering to the Creator pattern. **Part IV: Controller** - **Handling System Events:** Introduces the Controller pattern, focusing on assigning responsibility for handling system and UI events to designated controller classes. - **POS System Example (Continued):** Demonstrates Controller by assigning system operations like closing sales and payments to a dedicated controller class within the POS system. **Part V: Low Coupling** - **Reducing Dependencies:** Explains Low Coupling as minimizing dependencies between classes, aiming for a more modular and maintainable design. - **POS System Example (Continued):** Revises the POS system design to decrease coupling between \"Register,\" \"Payment,\" and \"Sale\" classes, improving system flexibility. **Part VI: High Cohesion** - **Promoting Class Focus:** Presents High Cohesion, emphasizing the grouping of related responsibilities within a single class to enhance maintainability and reusability. - **POS System Example (Continued):** Refactors the \"Register\" class to improve cohesion, separating unrelated responsibilities to create more focused classes. **Part VII: Polymorphism** - **Handling Type-Based Alternatives:** Discusses Polymorphism, advocating for using inheritance and method overriding to handle variations in behaviour based on object types. - **POS System Example (Continued):** Implements Polymorphism to manage different payment types (cash, card, check) through a base \"Payment\" class and specialized subclasses. **Part VIII: Pure Fabrication** - **Balancing Design Principles:** Introduces Pure Fabrication, a pattern for creating artificial classes to encapsulate functionalities and improve cohesion and coupling when existing domain classes are unsuitable. - **POS System Example (Continued):** Adds a \"StorageAgent\" class (a Pure Fabrication) to handle database persistence, decoupling this responsibility from domain classes. **Part IX: Indirection** - **Decoupling for Reusability:** Explains Indirection, a pattern that introduces intermediary objects to reduce coupling and enhance reusability, often in conjunction with Pure Fabrication. - **POS System Example (Continued):** Shows Indirection with \"PersistentStorageBroker,\" acting as an intermediary between domain classes and the database, increasing flexibility. **Part X: Protected Variations** **Designing for Change:** Explores Protected Variations, a principle advocating for designing systems to be resilient to future changes and variations in requirements.