Software Modelling

1. Software Modelling
 : The practice of creating and analysing software models
 - Software Model: A description (textual or visual) of any aspect of a software system
 - Modelling can help us check our understanding / communicate

2. Design / Modelling
 - a set of activities that need to be performed by the designer
  * in deriving and specifying a solution to a problem
  * to produce a workable solution
 - The fitness of the solution is measured by the correctness or appropriateness of the solution
 - The process: iterative in nature
  * Postulate a solution
  * Build a model of the solution
  * Evaluate the model against original requirements
  * Elaborate the model to produce a detailed specification of the solution

 !! The design process is not straightforward because of the nature of software
  * The complexity of software
  * The problem of conformity
  * The (apparent) ease of changeability
  * The invisibility of software

3. Modelling principles
 1) Modularisation: drives the continuous decomposition of the software system until fine-grained components are created
 2) Abstraction: focuses on essential characteristics of entities - in their context - while deferring unnecessary details
  - Procedural abstraction: simplifies reasoning about behavioural operations containing a sequence of steps
  - Data abstraction: simplifies reasoning about structural composition of data objects
 3) Encapsulation: deals with providing access to the services of abstracted entities by exposing only the information that is essential to carry out such services while hiding details of how the services are carried out
 4) Coupling: measurement of dependency between units
  * Content / Code Coupling
  * Data Coupling
  => reusability and maintainability decrease
  => a high degree of coupling gives rise to negative side effects
 5) Cohesion: measures how well design units are put together for achieving particular tasks
  => High cohesion good, low cohesion bad ...
 6) Separation of Interface and Implementation: deals with creating modules in such way that a stable interface is identified and separated from its implementation
  => different implementations of the same interface can be swapped to provide modified or new behaviour
 7) Sufficiency: deals with capturing enough characteristics of the abstraction to permit meaningful interaction
 8) Completeness: deals with interface capturing all the essential characteristics of the abstraction

http://ecomputernotes.com/software-engineering/principles-of-software-design-and-concepts

4. System Modelling Techniques
 - Classic: Entity-Relationship Modelling / Finite State Machines / Data Flow Diagrams
 - Object-oriented: variety of UML diagrams
 - Formal Modelling Methods

5. Unified Modelling Language (UML)
 : a visual modelling language for specifying, analysing, and designing/documenting essential aspects of software systems before construction
 - uses graphical notation to communicate more clearly than natural language and code
 - Structural diagram: shows the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other
  * Class Diagram: static relationships between classes
  * Component Diagram: the organisations and dependencies of the physical components
 - Behaviour diagram: shows the dynamic behaviour of the objects in a system, which can be described as a series of changes to the system over time
  * Use Case: capture requirements. Displays the relationships amongst actors and use cases
  * Sequence Diagram: displays the time sequence
  * State Machine Diagram: displays the sequence of states
  * Activity Diagram: shows flow of control or object flow

http://www.uml.org/

6. Use Case Diagram
 - Core components
  * System boundary
  * Actors: human users and other systems
  * Use case: A set of scenarios
 - Relationships between use cases
  * Association: communication
  * Generalisation: one general use case and one specific use case
  * Include: is used to indicate that a particular Use case must include another use case to perform its function
  * Extend: the extending use case may add behaviour to the base use case

https://msdn.microsoft.com/en-us/library/dd409432.aspx

7. Class Diagram
 - A class describes a group of objects with
  * similar properties (attributes)
  * common behaviours (operations)
  * common relationships to other objects
  * common meaning ("semantics")
 - Relationships between classes
  * Generalisation: an inheritance link indicating one class is a superclass of the other
  * Association: a relationship between instances of the two classes
  * Aggregation: an association in which one class belongs to a collection
  * Composition: a "strong" form of aggregation

https://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/

8. State Machine Diagram
 : a graph in which nodes correspond to states and directed arcs correspond to transitions labelled with event names
 - Elements
  * state: defines as the duration of time during which an object is doing an activity
  * event: occurs at a point in time
  * action: occurs in response to an event
  * activity: an operation with certain duration that can be interrupted by another event
  * guard: a logical condition

http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm

9. Sequence Diagram
 - Elements
  * Lifelines
  * Messages
  * Activation bar
  * Deletion

http://www.ibm.com/developerworks/rational/library/3101.html