Please enable JavaScript.

Coggle requires JavaScript to display documents.

260CT S. EG - Coggle Diagram

- - - - Best for user requirements that are not well understood (new systems), stakeholders are involved, possible design can only be made when a concrete form has been made, and to resolve issues between dev team and customers when specifying requirements
      - Dis: Avoids formal docs, may be unusual or odd to customers using the software, checks in SDLC are bypassed so small but important things might be forgotten.
    - - Breaks tasks into small increments, with minimal planning. Increments are short time frames: 1-4 weeks, usually called sprints. Each iteration involves a team doing SDLCs and presenting it to the stakeholders for further evaluation and refinement. Minimal documentation.
      - Best for: unpredictable requirements, responsible and motivated dev team, customers that knows the process and will get involved
      - Submethods
        
        Scrum, Ex. Prog, Adaptive Software Dev, Crystal, Feature Driven
      - Principles
        
        Customer Involvement
        
        Incremental Delivery
        
        Embrace Change
        
        People, not Process
        
        Maintain Simplicity
      - Dis: Lack of documentation, how would we keep customers involved, due to the lack of documentation maintenance would also be hard, because if a new team is hired to maintain the system they wouldn't have any clue on what the system is doing
  - - - Accommodates good features of previous approaches, while risk-approach reduces their problems. Focuses on early elimination of errors and weak solutions. Helps prepare the evolution of the system.
      - Dis: risk of not meeting the schedule, only large projects due to the demand in risk assessment expertise, strict, costly.
- - - - Unit (every single feature)
      - System (does the system meet the business requirements)
      - Integration (if modules are working fine when integrated with each other)
      - Acceptance (similar to system testing + meet end user's requirements, end users must test)
    - - Performance (How system will behave under certain conditions)
      - Usability
      - Security (find loopholes and security risks in system)
      - Compatibility
  - - - Weaken: Less restrictive, more widely usable
    - - Strengthen: more restrictive, define a narrower range of answer situations, ensures output is as expected.
- - - - Separate program into different sections, which addresses different concerns
      - Concerns are set of infos that affects the code of a program.
      - High cohesion -> a module should only contain related functions
    - - Low coupling, objects should be as independent from each other as possible.
    - - Software is designed, implemented, and tested incrementally.
    - - Remove tentative/unneeded details and focus on more important objectives
    - - Common properties are formulated as general concepts
    - - Rigor = (Exact, careful, strict), and highest degree of rigor
  - - - Software should be open for extension, to meet new requirements, but the original source code shouldn't be changed. We can do this through polymorphism, abstraction, inheritance
- - - - The controller (who handles the requests of actors?)
        
        The controller should delegate the work that needs to be done to other objects; it coordinates or controls the activity.The one who handles events.
      - Info expert
        
        determine where to delegate responsibilities such as methods, computed fields, and so on.
      - The creator (who creates object x?)
        
        Which class is responsible for creating objects is a fundamental property of the relationship between objects of particular classes. The one who creates should be the class that contains/aggregates or uses the other class frequently, or if the class has information that the other class needs.
      - indirection (supports low coupling, by creating an intermediate object between processes)
      - low coupling
      - high cohesion
      - polymorphism
      - protected variations
      - pure fabrication
  - - - Templates/Reusable solutions to recurring problems. Is not ready-to-use code like algorithms, but its more of a way of thinking / general concept.
    - - Creational: manage the creation of objects
        
        Factory Method
        
        Define an interface for creating an object, but let the subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
        
        Abstract Factory
        
        Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
        
        Builder
        
        Separate the construction of a complex object from its representation so that the same construction processes can create different representations.
        
        Prototype
        
        Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
        
        Singleton
        
        Ensure a class only has one instance, and provide a global point of access to it.
      - Structural: build objects into large structures while still upholding flexibility and efficiency
        
        Adapter
        
        Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatibility interfaces.
        
        Bridge
        
        Decouple an abstraction from its implementation so that the two can vary independently.
        
        Composite
        
        Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
        
        Decorator
        
        Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
        
        Facade
        
        Provide a unified interface to a set of interfaces in a system. Façade defines a higher-level interface that makes the subsystem easier to use.
        
        Flyweight
        
        Use sharing to support large numbers of fine-grained objects efficiently. A flyweight is a shared object that can be used in multiple contexts simultaneously. The flyweight acts as an independent object in each context; it’s indistinguishable from an instance of the object that’s not shared.
        
        Proxy
        
        Provide a surrogate or placeholder for another object to control access to it.
      - Behavioral: how code is organised, assignment of responsibility to objects, and how objects communicate between each other.
        
        Chain of responsibility
        
        Avoid coupling the sender of a request to its receiver by giving more then one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
        
        Command
        
        Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
        
        Iterator
        
        Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
        
        Mediator
        
        Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and lets you vary their interaction independently.
        
        Memento
        
        Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later.
        
        State
        
        Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
        
        Strategy
        
        Defines a family of algorithms, encapsulates each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients who use it.
        
        Template Method
        
        Define a skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithms structure.
        
        Visitor
        
        Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
- - - - Alternatives: an alternative way to achieve the same use-case, or possible exceptions.
      - Main-success scenario: steps to achieve a certain use-case
      - Description: written account of a use-case
      - Purpose of the use-case: what is the use-case made for
      - Post-conditions: what must be achieved upon completion, new object created, etc
      - Pre-conditions: what the state of the system must be for the use-case to begin, including required infos, objects.
      - Name of the use-case
    - - Extras
        
        Secondary actors should be on the right.
        
        System Boundary, a rectangle containing the use-cases, actors should be outside.
      - Use-case
        
        Must be verb.
      - Actors
        
        Specialized Actor, shown with the (------|>) notation but -90 degrees, the tip of the arrow should point to the general actor. Used to show that another actor inherits the use-cases that the base actor has access to, while also having other use-cases that the base actor does not have access to. It can also just be used to group several actors into one generalized actor.
        
        Secondary Actor, the actors that the system needs assistance from to achieve the primary actor's goal. They may or may not have their own goals. reactionary
        
        Primary Actor, the actors using the system to achieve a goal. The primary actor would always have a goal, and the use-case exists to satisfy the primary actor. WHO WE'RE BUILDING THE SYSTEM FOR, OR WHO DOES IT HELP THE MOST, OR WHO'LL INITIATE SOMETHING
      - Relationships
        
        Association, a notation used to show that an actor has access to a specific use case (------------)
        
        Generalization, a notation used to show that the child use-case is a subset or a part of the base use-case. Used to generalized similar use-cases. (----------|>) no spaces between arrow lines
        
        Extend Dependency, a notation used to show that the extending use case's behavior is one of the options in the base use-case, or may be used by the base use-case. Alternate course of the base use case, shown with (<-----) [the tip of the arrow should point to the base use case] <<extend>>
        
        Include Dependency, a notation used to show that the base use-case depends on the included use-case, or will use the included use-case, showed with (----->) literal (<<include>>) <- this included at the top of the arrow.
  - - - Attributes
        
        Properties of a class, variables that will be used or stored in the class. Describes the object.
        
        Visibilities
        
        ( - ) private, is only visible/can be used in the same class
        
        ( + ) public, all classes that has access to it or instantiated it can access and modify variables
        
        ( # ) protected, is only visible to elements that is derivation a class
        
        An attribute can be derived. For example, in a class, we would have DOB and Age. Age is easily calculated from the DOB variable, so it is a derived variable. This is shown using the ( / ) notation. E.g. + /age : int
      - Operations/Methods
        
        Operations have similar visibility to attributes
        
        Operations that have parameters, should look like this: ( - / + / #) method_name(variable_name : data_type) : data_type_returned.
    - - Aggregation
        
        A relationship where the child class can exist without the parent class. (Students can still exist without a Class (Grade)).
      - Composition
        
        A relationship where the child class cannot exist without the parent. (Rooms can't exist without a house/apartment)
      - Association
        
        A communication between two classes. https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-aggregation-vs-composition/
      - Generalization
        
        Combining similar classes into a class (not technically combining). More to saying: "Class B is a subset/part of A as it is similar". Class B would inherit all the attributes and methods in class A except for the private attributes. Savings and CC account is generalized into a Bank Account. Also known as inheritance.
      - Specialization
        
        Specialization is the reverse process of Generalization means creating new sub-classes from an existing class.