Ouyang's Blog

Working on ML Infra

0%

Software Engineering

Posted on Edited on In Disqus:

Testing

  • Testing is a whole-team responsibility
  • Different roles and different testings:
    • Developers: unit, integration, system, acceptance
    • Disigners: integration
    • Customers: acceptance
    • Analysts: acceptance
    • Test engineers and QA team: system, acceptance, exploratory
    • End Users: beta
    • Architects: integration, system
  • Varification: Software is right; Validation: We build the right software.
  • Fault (Also called defect, testing is aim to reveal this) -> Error -> Failure (Test will cause this)
  • Unit Testing: Individual components; Integration/Functional Testing: Groups of related components; System/Acceptance Testing: System as whole;

UML

Package Diagrams

  • Package diagrams are used to reflect the organization of packages and their elements. When used to represent class elements, package diagrams provide a visualization of the namespaces.
  • Package Merge: A «merge» connector between two packages defines an implicit generalization between elements in the source package, and elements with the same name in the target package. The source element definitions are expanded to include the element definitions contained in the target.
  • Package Import: The «import» connector indicates that the elements within the target package, which in this example is a single class, use unqualified names when being referred to from the source package. The source package’s namespace gains access to the target classes.

Class Diagrams

  • Class Notation: “+” means public level of visibility; “-“ means Private level; “#” allows an operation, or attribute, to be defined as protected; “~” symbol indicates package visibility;
  • Associations: An association implies two model elements have a relationship (knows-about) - usually implemented as an instance variable in one class.
  • Aggregations are used to depict elements which are made up of smaller components (is-part-of). Aggregation relationships are shown by a white diamond-shaped arrowhead pointing towards the target or parent class.
  • Inheritance (is-a-kind-of)

Deployment diagram,

  • Deployment diagram models the run-time architecture of a system. It shows the configuration of the hardware elements (nodes) and shows how software elements and artifacts are mapped onto those nodes.
  • An instance can be distinguished from a node by the fact that its name is underlined and has a colon before its base node type.
  • In the context of a deployment diagram, an association represents a communication path between nodes.

SOLID Principle

  • Single-responsibility principle: It states that a class should only have a single responsibility, which means only changes to one part of the software’s specification should be able to affect the specification of the class.
  • Open-closed principle: It states that a class should be extendable, but closed to modification. That simply means any desired additional behavior should be added to another class that extends your original class instead of modifying it.
  • Liskov substitution principle: This principle states that a derived class must be substitutable for its base class.
  • Interface segregation principle: This principle states that client-specific interfaces are better than one general-purpose interface.
  • Dependency inversion Principle: This principle states that the high-level module must not depend on the low-level module, but they should depend on abstractions.

Architecture haiku

  • Introduction: An architecture haiku aims to capture the architecture’s most important details on a single piece of paper.
  • It includes:
    • A brief summary of the overall solution
    • A list of important technical
    • A high-level summary of key functional requirements
    • A prioritized list of quality attributes
    • A brief explanation of design decisions, including a rationale and tradeoffs
    • A list of architectural styles and patterns used
    • Only those diagrams that add meaning beyond the information already on the page
  • Haiku creates a cognitive trigger that facilitates the recall of essential contextual information about a design decision.
  • Treat the Haiku as a living document
  • Use the Haiku as an Outline for future documentation

Design Partten

  • Singleton: Ensure that only one instance of a class is created. Provide a global point of access to the instance.
  • Bridge:
    • Expecting implementation of a class to change in anticipation of new vendor, new technology, or future optimizations
    • Intent: Decouple interfaces of a class from its implementations so that the two can vary independently.
  • Observer:
    • Then change of a state in one object must be reflected in another object without keeping the objects tightly coupled
    • Intent: maintain consistency across the states of one publisher and several subscribers.
  • Composite:
    • You want to deal with objects uniformly regardless of position in an object hierarchy
    • Intent: Compose objects into tree structures to represent part-whole hierarchies.
    • Window and panel are composites that may contain other windows or panels.
  • Facade
    • It is desirable to isolate a complex subsystem through a simple interface
    • Intent: reduce coupling among a set of related classes and the rest of the system
  • Strategy
    • It is desirable to make an object adaptable by allowing clients to change its behavior dynamically
    • Intent: define a family of algorithms, encapsulate each one and make them interchangeable at runtime.
  • Factory Method
    • You want a superclass to handle all standard behavior related to the processing of a set of products, but defer the creation of the proeucts to contrete subclasses
    • Intent: define an interface for creating objects, but let subclasses decide which class to instantiate at runtime.
  • Adapter
    • A client has a strong coupling to a legacy component which may be replaced
    • Intent: Convert the interface of a legacy class into a different interface expected by the client so that the client and legacy class work together with any changes to the client or the legacy class.
  • Inversion of Control (IoC) is used to invert different kinds of controls in object-oriented design to achieve loose coupling. Here, controls refer to any additional responsibilities a class has, other than its main responsibility. This include control over the flow of an application, and control over the flow of an object creation or dependent object creation and binding.

IoC is all about inverting the control. To explain this in layman’s terms, suppose you drive a car to your work place. This means you control the car. The IoC principle suggests to invert the control, meaning that instead of driving the car yourself, you hire a cab, where another person will drive the car. Thus, this is called inversion of the control - from you to the cab driver. You don’t have to drive a car yourself and you can let the driver do the driving so that you can focus on your main work.

The IoC principle helps in designing loosely coupled classes which make them testable, maintainable and extensible.

  • Dependency Injection (DI) is a design pattern used to implement IoC (Inversion of Control). It allows the creation of dependent objects outside of a class and provides those objects to a class through different ways. Using DI, we move the creation and binding of the dependent objects outside of the class that depends on them.

Presentation Skills

  • Assertion-Evidence is a style of presentation in which a sentence headline states the main message of the slide—this is the “assertion” part. The assertion is then supported with visual evidence—a photograph, chart, diagram, or video clip. Bulleted lists have no place in this style of presentation.
  • Assertion-Evidence talks are comprehended better by audiences and project more confidence from speakers.