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 fairly detailed. +. 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 databases. 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 super-classes. +. 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.


[Previous]     [Next]