Software Design Principles

Object

an object is an entity with a defined boundary that is an abstraction of a real-world entity that exhibits a behaviour. all objects have a unique identity a state (internal condition at any moment) and behaviour (operations that cam change state and communicate with other objects). Communicate by message passing (target, requested operation, any other info).

Refactoring

changing the internals of a program to improve performance but not changing outward behaviour (run faster).

Design PAtterns

describes a problem that occurs repeatedly in an environment, followed by core of the solution to problem that is always reusable. Creational (creation of objects), structural (composition of objects into structures), behavioural (define how objects interact and responsibility is shared). Anti-pattern is a wrong or inferior solution.

Design by Contract:

designers should define precise, formal, verifiable interface specs for components which extend the definitions of abstract data types (mathematical model for data types where data types are defined by its behaviour). specifies pre and post conditions and invariants, decide under what preconditions a component will behave appropriately.

Component Based Software Engineering

development paradigm centred around re-using prefabricated components to speed up development and maintenance and reduce cost. Component is reusable self-contained asset that requires no customisation.

GRASP (general responsibility assignment software patterns)

guidelines for assigning responsibility to classes and objects in object-orientated design. Low coupling is an evaluative pattern that dictates how to assign responsibilities.

Software engineering

is concerned with developing and maintaining software that behaves reliably and efficiently as well as it being affordable and maintainable as well as satisfying all customer requirements.

Architectural Patterns

means of representing, sharing and reusing knowledge. Stylized description of good, tested design practices. Contain info about when/when not to use them. MVC is an architectural pattern, layered architecture is another but it tends to be very artificial to implement. Repository pattern is when all the components work off a single central repository of information with all communication passing to and from it. Client-server pattern sees isolated services connected over the internet, this is very vulnerable to attack but can be convenient.

Software Metrics

measure of characteristics that are quantifiable or countable, important for measuring performance, planning work and measuring productivity. Believed to evaluate a quality property of the software.

Activity Diagram

model dynamic behaviour of use cases, classes, variant of statechart diagram (dot, bubble, diamond diagram). model internal flow of control between activities of use case scenarios. Can have swimlanes to show ownership. (thin separator bar for parallel flows).

MVC (MOdel view controller)

model stores and maintains data, view displays data, controller detects and forwards user input. Not a design pattern.

Data Flow Diagram

shows flow of data through a system, modelling its process. Often used as a preliminary step to create an overview of a system to be later elaborated. Visualization of data processing (structural design). Shows data input/output, how it advances, where its stored not timing or mention sequence/parallel.

Class Diagram

used during requirements analysis for problem domain concepts or system design to model subsystems. A class has a name, attributes (has a type (int, str, etc) information/2nd box) and operations (functions in the class/3rd box), each operation has a signature. Only the class name is mandatory everything else can be empty.

UML Sequence Diagram

used during requirements analysis refine use cases descriptions and find additional objects. Used during system design to refine subsystem interfaces. Classes are represented by columns, messages are arrows, "activations" are narrow rectangles (on dotted line), lifeline is dotted line leaving objects. Functions belong to class at point end of arrow, horizontal dotted lines are data flow (data belongs to blunt end of arrow), destruction shown by X. (actor interacting with classes on vertical lines by arrows diagram).

Use Case Diagram

used during requirements elicitation, complete description of the functionality of the system. Actors are external entities that communicate with system (user, external system). Use case represents a class of functionality (stick figures pointing to bubbles point to each other diagram). Includes invokes another use case, extends continues behaviour of a case.

Coupling/Cohesion

Cohesion good, coupling bad. Coupling is when modules depend on each other, cohesion is how well elements of a module are functionally related. High coupling means changing one thing can bugger everything else.

Model Loop

Given a single entity you can find everything related to them (son from father, mother from son).

Component Diagram

Graph of components connected by dependency relationships, shows dependencies between components. Dependencies are shown as dotted arrows from client to supplier component.

Encapsulation

Protects from accessing info one should not be aware of, part of info hiding, helps low coupling.

System Model

Static models show the structure of a system such as how objects are related. Dynamic/functional models show the functions, data flow, behaviour and reaction to external/internal events that software exhibits.