CS302: Software Engineering (2021.B.01)

Introduction

A central distinction between OOA and structured analysis is decomposition by concepts (objects) rather than decomposition by functions. The key point in this decomposition is to find what can behave, and then to decide later on in the design and implementation how they behave to realize the system functionality. Object-oriented requirement analysis is more concerned in identifying concepts related to the requirements and to create a conceptual model of the problem domain or the application area we are working with. This activity will guide you on how to identify objects or concepts, make them relate to each other, and finally create a conceptual or domain diagram.

Concepts and Classes in Conceptual Modelling 

Conceptual Modelling (sometimes called Domain Modelling) is the activity of finding out which concepts are important to a system. This process helps us to understand the problem further, and develop a better awareness of our customer's business. A concept is an idea, thing, or object. More formally, a concept may be considered in terms of its symbol, intension, and extension:

• Symbol – words or images representing a concept. It can be referred to when we talk about the concept.
• Intention – the definition of a concept.
• Extension – the set of examples or instances to which the concept applies.

For an example, the symbol Module as applied in some Universities can have:

• The intention to "represent a course offered as part of a degree in that university"; and
• The extension of all other modules offered by that university

Note that the terms class and type are used more by UML and not concept. As long as we are in the requirement analysis stage, the two terms class and concept may be used interchangeably.  Each instance of a class is called an object of the class. For example a class called "Student". Jahn Smith and Jane Brown are instances of a class Student. Therefore, a class defines a set of objects. The notions of class and object are interlinked as one cannot exist without the other, and any object belongs to a class. The differences are:

• An object is a concrete entity – exists in space and time (persistence property of objects);
• A class is an abstraction of a set of objects

The UML defines the term class as "a description of a set of objects that share the same attributes, operations, methods, relationships, and semantics". 

Identifying Concepts 

The requirement document which is up to now including: the overview, goal, functional requirements, use cases, use case diagram and use case descriptions is the good source of information in identifying concepts. Two activities that are fundamental to the useful application of object oriented in OOA are:

• To identify as many candidate objects from the problem domain, and 
• Later select those candidate objects that are significant to develop and be specified in an object model (conceptual model)

Liu (2001) suggests the following candidate concepts from the requirement document as shown in Table 3.10.

Table 3.10: Guide to Identify Concepts

Concept Category	Examples
physical or tangible objects (or things	POST (i.e. Point-of-Sale Unit), House, Car, Sheep, People, Airplane
places	places Store, Office, Airport, Police Station
documents, specifications, designs, or descriptions of things	Product Specification, Module Description, Flight Description
transactions	Sale, Payment, Reservation
roles of people	Cashier, Student, Doctor, Pilot
containers of other things	Store, Bin, Library, Airplane
things in a container	Item, Book, Passenger
other computers or electromechanical systems external to our system	Credit Card Authorization System, Air-Traffic Control
abstract noun concepts	Hunger, Acrophobia
organizations	Sales Department, Club, Object Airline
historic events, incidents	Sale, Robbery, Meeting, Flight, Crash, Landing
Processes (often not represented as a concept, but may be)	Selling A Product, Booking A Seat
rules and policies	Refund Policy, Cancellation Policy

Catalogs	Product Catalog, Parts Catalog
records of finance, work, contracts, legal matters	Receipt, Ledger, Employment Contract, Maintenance Log
financial instruments and services	Line Of Credit, Stock
manuals, books	Employee Manual, Repair Manual

 

Another useful and simple technique for the identification of concepts is to identify or extract noun and noun phrases from the requirement document and consider them as candidate concepts or attributes.

Warning:

Care must be applied when these methods are used; mechanical noun-to-concept mapping is not possible, words in natural languages are ambiguous, and concept categories may include concepts which are about either attributes, events or operations which should not be modeled as classes. We should concentrate on the objects/classes involved in the realization of the use cases. 

Consider the POST system, from the use case Buy Items with Cash. We can identify some noun phrases as shown in Figure 3.8. Some of the noun phrases in the use case are candidate concepts; some may be attributes of concepts.

Figure 3.8: Selected Possible Concepts for the POST System

The following guidelines are useful when identifying concepts:

• It is better to over specify a conceptual model with lots of fine-grained concepts, than to under specify it.
• Do not exclude a concept simply because the requirements do not indicate an obvious need to remember information about it.
• It is common to miss concepts during the initial identification phase, and to discover them later during the consideration of attributes or associations, or during the design phase. When found, they are added to the conceptual model.
• Put a concept down as a candidate in the conceptual model when you are not sure it must not be included.

Adding Associations in a Conceptual Model

A conceptual model with totally independent concepts only is obviously useless, as objects in different classes must be related to each other so that they can interact and collaborate with each other to carry out processes. In UML, an association is a relationship between two classes that specifies how instances of the classes can be linked together to work together.
In the same sense that instances of a class are objects, instances of an association are links between objects of the two classes – this is what we meant that objects in the same class "share the same relationships".
With respect to an association between classes, an important information is about how many objects of one class (say "A") can be associated with one object of another (say "B")n , at a particular moment in time. We use multiplicity to represent this information. An example in Figure 3.9 shows the multiplicity expressions and their meanings.

Figure 3.9: An Example on Multiplicity Use

Some high priority associations useful to include in a conceptual model are:

• A is a physical or logical part of B.
• A is physically or logically contained in/on B.
• A is recorded in B.

From the list of concepts identified, one can start thinking of the possible associations concepts have to each other. This can accelerate the creation of a conceptual diagram. In this way relevant associations will not be forgotten. Figure 3.10 shows possible aggregation relationships of concepts in a POST system.

Figure 3.10: Aggregation Association in POST Application as an example, a conceptual model, or sometimes known as a class diagram for a POST system domain is as shown in Figure 3.11. This has also considered concepts' association: inheritance, aggregation and composition as discussed earlier.

Figure. 3.11: A Conceptual/Class model for the POST System (concepts, associations and Attributes)

Add Attributes in a Conceptual Model 

Instances of a concept may have some properties. For example, a Sale can have a date and time; a Payment can have amount, a Furniture can have a size, a Module can have a code, title, and number of credits, a Student has a name, registration number and age, etc. 

An attribute of a class is the abstraction of a single characteristic or a property of entities that have been abstracted as objects of the class. At any given moment of time, the attribute of an individual object in the class is a logical data value representing the corresponding property of the object, and called the value of attribute for the object at that time. One object has exactly one value for each attribute at any given time. Therefore, the value for an attribute of an object may change over time. For examples,

• time and date are attributes of class Sale, and an instance of Sale can be a sale at 13.30 on 1/10/1998. 
• code, title, and credit are three attributes of class Module, and an instance of Module can have a code MC 206, title: Software Engineering and System Development, and credit: 20. 
• name and age are attributes of Student, an individual student can have the name John Smith, and age 19.

Something to note in attributes: 

(a) The attributes in a conceptual model should be simple and clear without ambiguity. Examples of simple attributes are Date, Number, PhoneNumber, Name, Description, Code, Title etc 

(b) In object-oriented approach no foreign keys. Attributes are not to be used to relate concepts in the conceptual model, but to store some information about the objects themselves. Liu, (2001) states that the most common violation of this principle is to add a kind of foreign key attribute, as is typically done in relational database designs, in order to associate two types. For example, the currentPOSTNumber attribute in the Cashier type in Figure 3.12 is undesirable because its purpose is to relate the Cashier to a POST object. The better way to express that a Cashier uses a POST is with an association, not with a foreign key attribute Once again 

Relate types with an association, not with an attribute

Figure 3.12: Do not use attributes as foreign keys

Steps to Create a Conceptual Model 

The following steps can be applied to create a conceptual model: 

• Identify and List candidate concepts using the Concept Category List and noun phrase identification related to the current requirements under consideration. 
• Represent them in a conceptual model. 
• Add associations necessary to record relationships for which there are a need to preserve some memory. 
• Add the attributes necessary to fulfill the information requirements.

Conclusion 

System concepts can be identified by investigating the requirement document which includes: system function, use cases and other initial reports on the domain. A conceptual model shows the static view of associations of concepts, they include as shown in Figure: 3.8 above; Concepts, Relationship or association between concepts and Attributes of concepts. The following elements are not suitable in a conceptual model:

• A software artifact, such as a window or a database, unless the domain being modeled is of software concepts, such as a model of a graphical user interface. 
• Operations (responsibilities) or methods.

---

Source: Ellen Ambakisye Kalinga
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.