Computing Students - Computer Science Degree Notes
Home Contact Shop Notes Questions Programming Links Dictionary Coursework FORUM Tutors
  Recommended Amazon Searches: Computer Science | Computing | Computer Systems | Database | Computing Revision  

Notes > Software Engineering > System Modelling

Domain Models

A domain model is a simplified class diagram. A domain model can be used to supplement or provide more detail for the use cases related to the system. Initial class models (the domain model) are based around the real domain that exists in the real world. Later models represent the new functionality of the new system. Classes in the domain model therefore typically represent real entities or concepts that exist in the real world context of the system.

Classes are identified by analyzing the use cases. Relationships and data to be stored also need to be realised. Analysis of the use cases can also be used to ensure that the domain model meets the full system requirements. It is important to note that different models can be equally suitable in fulfilling the requirements of a new system. There is not always a single, "best" model.

Analysis Model

The Analysis Model contains the following:

  • Class diagram - sometimes derived from the domain model
  • Interaction diagrams
  • Architectural description - describes the overall system

Use case realization plays an important role in moving the system model nearer to implementation. The interactions involved in each use case should be determined so that the required system behaviour and functionality will be achieved. The classes required for each use case need to be defined. Each set of classes that create the required functionality are called a collaboration.

Class Stereotypes

Classes can be grouped into general categories called "stereotypes". The stereotype of a class can be denoted by the sterotype name appearing above the class name enclosed with guillemets ("<< >>" - French quotation marks). The three class stereotypes are as follows:

  • Boundary - represent interaction between the system and its environment
  • Entity - have stored data and associated behaviour (methods)
  • Control - control the collaborative behaviour of the classes / objects in the system

Class Responsibility Collaboration (CRC)

Using physical CRC cards can help at various stages of the system development cycle. They can be used to analyze object interaction and identify any missing classes or collaborations. CRC cards can also help determine the required messages that need to be sent between objects within the system.

Class Responsibility Collaboration (CRC)

The above diagram shows the typical layout for a CRC card or a CRC diagram. The class name is at the top of the CRC in bold. The rest of the card is split into two columns which show the responsibilities and collaborations of the class.

All classes should have at least one responsibility otherwise the existence of that class is unnecessary. Too many collaborations in the CRC diagram indicates a high level of coupling which is undesirable in good object-oriented systems development.

Search for "System Modelling" on: Google | Kelkoo | Amazon | eBay (UK) | eBay (US)

Search for "System Modelling" on the rest of Computing Students: System Modelling

Home | Contact | Shop | Notes | Questions | Programming | Links | Dictionary | Coursework | Tutors Sponsored Links: Affiliate Program Articles | Computer Science Definitions | CS Degree Notes
Copyright © 2005-2009
This site is to be used in accordance with the User Agreement
High Wycombe Web Design