ASD-Notes

My notes on Advanced-Software-Development

View the Project on GitHub angus-mackenzie/ASD-Notes

Summary

This is a summary of the content of ASD, I recommend reading through the other notes on this repository alongside this. Mainly because there are some omissions.

Introduction

Software Engineering (SE)

Establishment and use of effective engineering principles to create software that is reliable and works efficiently on real machines

Application of a systematic, disciplined, quantifiable approach to the creation, operation and maintenance of software

Elements of SE

Process of SE

Project Management

Planning

The 4 P’s

Planning vs Management

Triangle

YAGNI - You Ain’t Gonna Need It

These all happen linearly

Modern Alternatives

Guidelines of Agile Methods

  1. Active user involvement is imperative
  2. The team must be empowered to make decisions
  3. Requirements evolve but the timescale is fixed
  4. Capture requirements at a high level, lightweight and visual
  5. Develop small, incremental releases and iterate
  6. Focus on frequent delivery of product
  7. Complete each feature before moving on to the next
  8. Apply 80/20 rule
  9. Testing is integrated throughout the project lifecycle - test early and often
  10. A collaborative & cooperative approach between all stakeholders is essential

Pareto’s Law

Active User Involvement

Principles of XP

| Principle | Description| | — | — | | Incremental planning | Requirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development ‘Tasks’. | | Small releases | The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. | | Simple Design | Enough design is carried out to meet the current requirements and no more. | | Test-First Development | An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented | | Refactoring | All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable | | Pair programming | Developers work in pairs, checking each other’s work and providing the support to always do a good job. | | | Collective ownership | The pairs of developers work on all areas of the system, so no islands of expertise develop and all the developers take responsibility for all of the code: anyone can change anything. | | Continuous integration | As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. | | Sustainable pace | Large amounts of overtime are not acceptable as the net effect is often to reduce code quality & medium term productivity | | On-site customer | A representative of the end-user of the system (the customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation |

System Metaphor

TDD

Scrum

Roles

  1. Product Owner
  2. Team
  3. Scrum Master (SM)
    • All involved are Players or Spectators
    • Players - committed, accountable, responsible
    • Spectators - interested, consults, informed (management)

Sprints

Daily Scrum

Retrospective

Artefacts

General Scrum Flow

Prototypes

Evolutionary

UML & Architecture

Architectural thinking is the translation from the problem domain to the solution concept

An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behaviour as specified in the collaborations among those elements, the composition of these structural and behavioural elements into progressively larger subsystems, and the architectural style that guides this organization—these elements and their interfaces, their collaborations, and their composition

- Booch, Rumbaugh and Jacobson, The UML User Guide, 1999

RUP 4 + 1

MVC

Model-View Controller

  Description
Problem Used when there are multiple ways to view and interact with data. Also used when the future requirements for interaction and presentation of data are unknown
Solution Separates presentation and interaction from the system data. The system is structure into three logical components that interact with each other. The Model component manages the system data and associated operations on the data. The View component defines and manages how the data is presented to the user. The Controller component manages user interactions (e.g.: key presses, mouse clicks, etc) and passes these interactions to the View and the Model
Pro Allows the data to change independently of its representation and vice versa. Supports presentation of the same data in different ways with changes mode in on representation shown in all of them
Con Can involve additional code and code complexity when the data model and interactions are simple

Layered

  Description
Problem Used when building new facilities on top of existing systems; when the development is spread across several teams with each team responsibility for a layer of functionality; when there is a requirement for multi-level security.
Solution Organises the system into layers with related functionality associated with each layer. A layer provides services to the layer above it so the lowest-level layers represent core services that are likely to be used throughout the system
Pro Allows replacement of entire layers so long as the interface is maintained. Redundant facilities (e.g.: authentication) can be provided in each layer to increase the dependability of the system
Con In practice, providing a clean separation between layers is often difficult and a high-level layer may have to interact directly with a lower-level layer rather than through the layer immediately below it. Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer

Repository

||Description| |—|—| |Problem| You should use this pattern when you have a system in which large volumes of information are generated that has to be stored for a long time. You may also use it in data-drive systems where the inclusion of data in the repository triggers an action or tool| |Solution|All data in a system is managed in a central repository that is accessible to all system components. Components do not interact directly, only through the repository.| |Pro|Components can be independent - they do not need to know of the existence of other components. Changes made by one component can be propagated to all components. All data can be managed consistently as it is all in one place.| |Con|The repository is a single point of failure so problems in the repository affect the whole system. May be inefficiencies in organizing all communication through the repository. Distributing the repository across several computers may be difficult.|

Client-Server Pattern

||Description| |—|—| |Problem|Used when data in a shared database has to be accessed from a range of locations. Because servers can be replicated, may also be used when the load on a system is variable.| |Solution|In a client-server architecture, the functionality of the system is organized into services with each service delivered from a separate server. Clients are users of these services and access servicers to make use of them.| |Pro|The principal advantage of this model is that server can be distributed across a network and servers can be added or upgraded with minimal disruption. General functionality can be available to all clients and does not need to be implemented by all| |Con|Each service is a single point of failure so it is susceptible to denial of service (DOS) attacks or server failure. Performance may be unpredictable because it depends on the network as well as the system. May be management problems if servers are owned by different organizations|

Pipe And Filter

||Description| |—|—| |Problem|Commonly used in data processing applications (both batch and transaction based) where inputs are processed in separate stages to generate related outputs| |Solution|The processing of the data in a system is organized so that each processing component (filter) is discrete and carries out one type of data transformation. This data flows (as in a pipe) from one component to another for processing| |Pro|Easy to understand and supports transformation reuse. Workflow style matches the structure of many business processes. Evolution by adding transformation is straightforward. Can be implemented as either a sequential or concurrent system| |Con|The format for data transfer has to be agreed upon between communicating transformations. Each transformation must parse its input and unparse its output to the agreed form. This increases system overhead and may mean that it is impossible to reuse functional transformations that use incompatible data structures|

Reference Architectures

Design Patterns

9 Grasp Patterns

  1. Information Expert
    • Expert
    • Assign responsibility to the information expert, the class that has the information necessary to fulfil the responsibility\
  2. Creator
    • Who should be responsible for creating a new instance of some class?
    • Solution: Assign class C the responsibility to create instances of class X if one or more of the following is true:
      • C aggregates X objects
      • C contains X objects
      • C records instances of X objects
      • C closely uses X
      • C has the initializing data that will be passed to X when it is created
  3. Controller
    • What object in the domain receives the requests for work form the UI layer
    • Solution: Choose a class whose name suggests an overall device or subsystem
  4. Low Coupling
    • How to support low dependency, low change impact and increased reuse?
    • Assign responsibility so that coupling remains low
  5. High Cohesion
    • How to keep complexity manageable?
    • Assign responsibility so that cohesion remains high
  6. Polymorphism
    • How to design for varying, similar cases?
    • Assign a polymorphic operation to the family of classes for which the cases vary
  7. Pure Fabrication
    • Where to assign a responsibility, when the usual options based on expert lead to problems with coupling and cohesion, or are otherwise undesirable
    • Make an artificial class, whose name is not necessarily inspired by the domain vocabulary
  8. Indirection
    • What is a common mechanism to reduce coupling?
    • Assign a responsibility to an intermediate object to decouple collaboration from 2 other objects
  9. Protected Variation
    • How to design objects so that changes in these objects do not have side effects on other objects
    • Put a wrapper or interface object around them. The awrapper gives a stable interface and is all that has to be altered when the changes happen
    • Dont talk to strangers
      • Special case of Protected Variation
      • Only send messages to familiars
        • GoF patterns
    • Singleton Pattern
      • Ensures a class only has one instance and provides a global point of access to it
    • Composite Pattern
      • Applications need to manipulate hierarchical collection of primitive and composite objects uniformly
      • Define an abstract base class that specifies the behaviour that needs to be exercised uniformly across all primitive and composite objects. Subclass the Primitive and Composite classes off of the base class. Each composite objects couples itself only to the abstract type as it manages its children
    • Facade Pattern
      • Define a single point of contact to the system
    • Observer Pattern
      • Generalization of MVC pattern
        • Want to display data in more than one form at the same time and have all of the displays reflect any changes in that data
        • Designing for Low Representational Gap
    • Normally we design for a low representational gap between real world and software. i.e.: we design software to be as close to real life as possible (in an abstract sense)
    • Thus, designed objects correspond to real world objects
    • However, this might not be the best as actors do more work than a specific class, and it may be sensible to talk about one actor but divide that work into multiple separate classes

      Open Source Software Development

      * OSS, FOSS, FLOSS > Free (Libre) and Open Source Software

Open Source is a development methodology; free software is a social movement

Onion