a systems model for the field of informatics a. j. cowling department of computer science university...

A Systems Model for the Field of Informatics

A. J. Cowling

Department of Computer Science

University of Sheffield

Inf. Edu. Europe 2006 University of Sheffield Department of Computer Science

Structure of Presentation

Background A model for the structure of the SE curriculum General systems theory applied to Informatics Hierarchical curriculum models

The Proposed Three-Dimensional Model The products dimension The process dimension The people dimension

– relationships with products and processes

Evaluation and Conclusions Comparison with the Great Principles model Conclusions.


The SE Curriculum

A Multi-Dimensional Model Three main dimensions: products, processes and people 1

Products defined in terms of levels of abstraction of components 2

Processes defined in terms of relationships to people:– individuals, groups and markets

Also introduced a further dimension:– balance of theory and practice.

Application to SE Described its relationships with other disciplines:

– Computer Engineering, Computer Science, Information Systems

1. A. J. Cowling, A Framework for Developing the SE Curriculum, Proc. International Workshop on SE Education, Sorrento, 1994, pp 111 – 118.

2. A. J. Cowling, A Multi-Dimensional Model of the SE Curriculum, Proc 11th CSEE&T, Atlanta, 1998, pp 44 – 55.


General Systems Theory

The British Computer Society The UK Professional Body for Information Systems Engineering; Accredits degree programmes in this whole area:

– viz Computer Science, Computer Engineering, Software Engineering, Information Systems, Information Technology, Artificial Intelligence, etc

Hence covers the whole of Informatics; Accreditation criteria need to be applicable throughout.

The Artefacts Being Studied For all programmes the products are information systems; Different programmes focus on different aspects of these systems; General Systems Theory is applicable to all of them; It defines key aspects that must be covered in all programmes.


Hierarchical Curriculum Models

Usual Structure Curriculum for a discipline consists of knowledge areas; Knowledge areas consist of knowledge units; Knowledge units consist of topics; Topics may have attributes:

– core or optional, levels on Bloom’s taxonomy, etc.

Limitations Different disciplines may need different views of the same

knowledge area 3:– different structures of units, or emphases;

Within a discipline, relationships between different areas or units are not easily represented.

3. A. J. Cowling, Teaching Data Structures and Algorithms in a Software Engineering Degree: Some Experience with Java, Proc 14th CSEE&T, Charlotte, 2001, pp 247 – 257.


Unifying These Approaches

Focus: Knowledge Structures and Relationships

Approach: A Three-Dimensional Model Places Informatics knowledge areas in a space; Key dimensions for this space:

– Products, Processes and People Each dimension has a hierarchical sub-structure:

– For products, from general systems theory;– For processes, from activities and the information they use;– For people, from organisational structures.

Omission The balance of theory and practice is not included as a dimension:

– this would be desirable, to link theory to applications,– but the structure for such a dimension is not clear.


The Products Dimension 1

Hierarchical Structure Root levels (nearest the origin) derived from core computing

concepts; Layered to match levels of abstraction; Leaf levels derived from application domains of computing.

Aspects of the Levels All levels relate to kinds of information systems; Aspects of the root levels come from General Systems Theory:

– systems are structured from sub-systems by some paradigm,– systems have a purpose (ie processing and storage of

information),– systems have a boundary, across which they communicate,– internal sub-systems must communicate to achieve purpose;

Aspects of the leaf levels all involve different kinds of abstract software components interacting.


The Products Dimension 2Level of Abstraction

Structuring Paradigm

Processing Storage Internal Communication

External Communication

Analogue Circuits

Modulation Gate circuits Feedback Analogue signals Analogue signals

Digital Circuits Clocking Combinatoric logic

Sequential logic

Digital signals Physical layer protocols

Digital Components

Micro-programming

Processors Memories Buses MAC layer protocols

Computers Assembly language

Interrupt handling, etc

Virtual memory

Device level I/O Link & network layer protocols

OS Services Imperative programming

Process management

Filing systems

Buffer management

Transport layer protocols

Programming Concepts

Programming paradigms

Translators, VMs

Data typing Data streams Session layer protocols

Programming Abstractions

ADTs Procedures and methods

Data structures

GUIs, event streams

Application layer protocols

APIs Software components

Software Architecture

Design patterns

Domain - specific abstractions


The Processes Dimension 1

Two Structures for Processes Abstract, in terms of sequences of activities that produce models; Concrete, in terms of plans, resources and their control.

specify

Methodologies

Activities Sequencing

Models

Notations

manipulate

use

Process Models

Objectives & Constraints

Schedule & Work Breakdown

Resources

need

need


The Processes Dimension 2

Combining These Structures

manipulate

use

specify

Methodologies

Processes

Activity Sequence

Objectives & Constraints

Schedule & Work Breakdown

Models

Notations

need

Resources

need allocate


The People Dimension

Levels of Organisational Structure The opposite way round to the usual organisational hierarchy;

– root level (nearest the origin) – individuals,– middle levels – different sizes of teams,– outermost level – organisations or business units.

Structures Within Levels Each level will have a variety of purposes; These will lead to different application domains.

Roles of People Reflected in relationships with product and process dimensions:

– as users of products,– as developers working within processes.


Combining the Dimensions

Forming a Knowledge Space Any topic can therefore be located in the space by:

– which abstraction level of products it refers to,– which aspect of systems theory it covers, or which application

domain,– which abstraction level of processes it refers to,– what size group of people it relates to.

Example Database normalisation (a topic in CS, CE, SE, IS and IT); Irrespective of programme, this is concerned with:

– the storage aspect of the software components level, – for domains involving information with an ER structure,– the design activity that involves manipulating ER models,– the business of the organisation requiring the database.


The Great Principles Model 1

Also Multi-Dimensional Two main dimensions: principles and practice.

The Principles Dimension Has two elements: mechanics and design; Both focus on laws: for “what” and “how”. Mechanics corresponds to the general properties of systems

– cf the five windows: automation, coordination, computation, recollection (storage), and communication;

Design corresponds to how two elements are brought together:– the characteristic properties for specific products, and – the relationships between components that produce these.

The Practice Dimension Identifies generic activities that underpin processes:

– innovating, engineering, modelling, validation, programming, applying.


The Great Principles Model 2

Structuring The Space Identifies two components: applications and core technologies.

Applications and Domains Concerned with why people need computing; Correspond to the application domains for products, and their

relationships with people.

Core Technologies Currently 30 of these: from algorithms to workflow; Capture key common features of domains; The principles and practices capture how this happens. Correspond to areas within the knowledge space:

– some mainly focus on lower level products (databases, compilers, networks, operating systems, etc),

– others on kinds of applications (graphics, robots, vision, etc).


Evaluation

Application of the Model to the Whole Field All informatics disciplines involve products:

– which are information systems, so general systems theory is applicable to them;

All informatics disciplines involve processes:– historically some have not given them much attention, but to

prepare students adequately for careers they should!– maybe this part of the Great Principles model is weak;

All informatics disciplines involve people, either as users, developers or both.

Does the Model Cover The Whole Field? The above suggests that it does; The acid test will be mapping current curriculum models into it:

– one example topic is not enough!


Conclusions

A Model for the Whole Field of Informatics The structure of the model has been defined; It reflects fundamental principles:

– eg the application of general systems theory to products; Its structure allows it to capture relationships between topics:

– in a more general fashion than conventional hierarchical curriculum models.

Restricted to Knowledge Structures It does not capture the balance of theory and practice; Hence, it ignores some distinctions between disciplines.

Future Work To map existing curriculum models into this model:

– ie to place actual topics in this space; To include the balance of theory and practice.


The End

Thanks for your attention!!

Any Questions?

a systems model for the field of informatics a. j. cowling department of computer science university...

Documents