Difference between revisions of "Definitions in EUDP"

From EUDP
Jump to: navigation, search
 
(One intermediate revision by the same user not shown)
Line 10: Line 10:
  
 
'''Development specific definitions in EUDP'''
 
'''Development specific definitions in EUDP'''
 +
 +
Architecture Diagram: A diagram showing how the individual blocks are organised and potentially interconnected.
  
 
Block Diagram: A diagram showing the blocks the hardware is divided into.
 
Block Diagram: A diagram showing the blocks the hardware is divided into.
  
Problem Domain: The part of the system-to-be should control or administer.
+
Problem Domain: The part of the world that the system-to-be should control or administer.
  
 
Usage Domain: The users and other systems that controls or administers a problem domain.
 
Usage Domain: The users and other systems that controls or administers a problem domain.

Latest revision as of 12:57, 12 August 2012

Definitions in EUDP

General definitions in EUDP

The Developer: One or more persons developing the system-to-be.

The Customer: One or more persons representing the customer's company.

System-to-be: The system under development.

Development specific definitions in EUDP

Architecture Diagram: A diagram showing how the individual blocks are organised and potentially interconnected.

Block Diagram: A diagram showing the blocks the hardware is divided into.

Problem Domain: The part of the world that the system-to-be should control or administer.

Usage Domain: The users and other systems that controls or administers a problem domain.

Domain Model: An object model of the domain that incorporates both behaviour and data.

Object: A run-time entity that packages both data and the procedures that operate on that data.

Class: A class defines an object's interface and implementation. It specifies the object's internal representation and defines the operations the object can perform.

Event: An instantaneous occurrence that will influence on one or more objects.

Generalizations and Specialization:

Class A is a generalization of class B if and only if:

  • every instance of class B is also an instance of class A; and
  • there are instances of class A which are not instances of class B.

Equivalently, A is a generalization of B if B is a specialization of A.

Class B is a specialization of class A if and only if:

  • every instance of class B is also an instance of class A; and
  • there are instances of class A which are not instances of class B.

Packages: Packages are collections of classes that are connected.

Association: A very loose relationship, which might even be rather short term and changing.

Aggregation: Whole-part, a medium, typically long term relationship.

Composition: Whole-part, a strictly defined lifetime relationship.