Analysis Modeling | Software Engineering

3 min read

Analysis Modeling

At a technical level, software engineering begins with a series of modeling tasks that lead to a complete specification of requirements and a comprehensive design representation for the software to be built.

The first technical representation of a system which is the analysis model, actually a set of models. There have been many methods proposed for analysis modeling.

The structured analysis (a classical modeling method) and object-oriented analysis are two main methods for analysis modeling.

Structured analysis is a model building activity. The analysis model must achieve three primary objectives:

  1. to describe what the customer requires
  2. to establish a basis for the development of software design
  3. to define a set of requirements that can be validated once the software is developed.
Figure 1: Structure of Analysis Model

The data dictionary is a repository that contains descriptions of all data objects consumed or produced by the software.

The entity relation diagram (ERD) represent the relationships between data objects. The entity relation diagram is the notation that is used to conduct the data modeling activity. The attributes of each data object noted in the entity relation diagram (ERD) can be described using a data object description.

The data flow diagram (DFD) serves two purposes: (1) to provide an indication of how data are transformed as they move through the system, (2) to depict the functions (and sub-functions) that transform the data flow. The description of each function presented in the DFD is contained in a process specification. The DFD serves as a basis for the function modeling.

The state transition diagram (STD) indicates how the system function/behave as a consequence of external events. To achieve this, the STD represents the various modes of behavior (called states) of the system and the manner in which transitions are made from state to state. The STD serves as the basis for behavioral modeling. The information about the control aspects of the software is contained in the control specification.

Entity Relationship Diagram (Data Modeling)

The data model consists of 3 inter-related information: the data object, the relationships that connect data objects to one another and the attributes that describe the data object.

Data Object

A data object is a representation of almost any composite information that must be understood by software.

By composite information, we mean something that has a different number of properties or attributes. Therefore, width (a single value) would not be a valid data object, but dimensions (incorporating height, width, and depth) could be defined as an object. A data object can be an external entity (e.g., anything that produces or consumes information), a thing (e.g., a document or a display), an event (e.g., a call) or a role (e.g., manager), an organizational unit (e.g., computer science department), a place (e.g., a storehouse), or a structure (e.g., a file).

For example, a person or a bike can be viewed as a data object in the sense that either can be defined in terms of a set of attributes. The data object description incorporates the data object and all of its attributes.

Attributes

Attributes define the properties of a data object. The set of attributes that is appropriate for a given data object is determined through an understanding of the problem context.

Relationships

Data objects are connected to one another in different ways. Relationships indicate the manner in which data objects are “connected” to one another. Consider two data objects, food and Grocery Store. We can define a set of relationship pairs that define the relevant relationships.

For example:
– A Grocery Store orders food.
– A Grocery Store displays food.
– A Grocery Store stocks food.
– A Grocery Store sells food.
– A Grocery Store returns food.

The relationships orders, sells, displays, stocks and returns define the relevant connections between Grocery Store and food.

Figure 2: Relationships between Objects (Food and Grocery Store)

Figure 2 illustrates these relationships pairs graphically. It is important to note that object/relationship pairs are bidirectional, i.e., they can be read in either direction. A Grocery Store orders food or food are ordered by a Grocery Store.

Cardinality

Cardinality is the specification of the number of an event of one [object] that can be related to the number of an event of another [object]. Cardinality is usually expressed as simply “one” or “many”.
For example, a wife can have only one husband (in most cultures), while a parent can have many children. All combinations of “one” and “many”, two [objects] can be related as:

  • One-to-one (l: l) – An event of [object] ‘A’ can relate to one and only one event of [object] ‘B’, and an event of ‘B’ can relate to only one event of ‘A’.

  • One-to-many (l: n) – One event of [object] ‘A’ can relate to one or many events of [object] ‘B’, but an event of ‘B’ can relate to only one event of ‘A’. For example, a father can have many children, but a child can have only one father.

  • Many-to-many (m: n) An event of [object] ‘A’ can relate to one or more event of ‘B’, while an event of ‘B’ can relate to one or more event of ‘A’. For example, an uncle can have many nephews, while a nephew can have many uncles.

Also Read

  1. Requirements Elicitation
  2. Software Requirement Specification

Read Complete: Software Engineering (Free)

Leave a Reply

Close
Shares