Chapter 6. System Models
6.1 Data-flow models
-. Show the proccessing steps as data flows through a system.
-. Intrinsic part of many analysis methods.
-. Simple and intuitive notation that customers can understand.
-. Show end-to-end processing of data.
-. Data-flow diaagrams (DFD)
+. May be used to show processing at different levels of abstraction from
+. May also be used for architectural description showing data interchange
between the sub-systems making up the system.
+. Not a good way to describe system interfaces.
6.2 Semantic data models
-. Used to describe the logical structure of data processed by the system.
-. Entity-relation model seets out the entities in the system, the relationships between
these entities and the entity attributes.
-. Widely used in database design. Can readily be implemented using relational
6.3 Object models
-. Object models describe the system in terms of object classes.
-. An object class is an abstraction over a set of objects with common attributes and
the services(operations) provided by each object.
-. Various object models may be produced.
+. Inheritance models
+. Aggregation models
+. Service models
-. Natural ways of reflecting the real-world entities manipulated by the system.
-. More abstract entities are more difficult to model using this approach.
-. Object class identification is recognised as a difficult process requiring a deep
understanding of the applicaation domain.
-. Object classes reflecting domain entities are reusable across systems.
-. Inheritance models
+. Organise the domain object classes into aa hierarchy.
+. Classes at the top of the hierarchy reflect the common features of all classes.
+. Object classes inheerit their attributes and services from one oor more
+. Class hierarchy design is a difficult process if duplication in different branches is
to be avoided.
-. Multiple inheritance
-. Object aggregation
-. Service-usage models
6.4 Data dictionaries
-. A data dictionary is a list of names and associated descriptions of entities used
in the system.
-. It repressents a shared repository of system information.
-. It serves as
+. A mechanism for name management. As a system model may be
developed by different people, there is potential for name clashes.
+. A link from analysis to design and implementation.
-. All names used in the system model, design and implementation should be entered
in the data dictionary.
-. Support software should be used to create, maintain and query the dictionary.
-. The data dictionary may be integrated with CASE tools so that its construction and
maintenance may be partially automated.