The choice of representation is made according to the requirements to avoid inconsistencies and ambiguities. Each of these describes a different manner to represent the functional and behavioral information, the analysis model comprises
1.Structured Analysis: Structured analysis expresses this information through data-flow diagrams
2.Object-oriented modeling: Whereas object-oriented modeling specifies the functional and behavioral information using objects
3.other approaches: Other approaches include ER modeling and several requirements specification languages and processors
1) Structured Analysis
Structured analysis is a top-down approach, which focuses on refining the problem with the help of functions performed in the problem domain and data produced by these functions. This approach facilitates the software engineer to determine the information received during analysis and to organize the information in order to avoid the complexity of the problem. The purpose of structured analysis is to provide a graphical representation to develop new software or enhance the existing software.
2) Object-oriented Modeling
Nowadays, an object-oriented approach is used to describe system requirements using prototypes. This approach is performed using object-oriented modeling (also known as object-oriented analysis), which analyzes the problem domain and then partitions the problem with the help of objects. An object is an entity that represents a concept and performs a well-defined task in the problem domain. For this, an object contains information of the state and provides services to entities, which are outside the object(s). The state of an object changes when it provides services to other entities.
Object-oriented modeling defines a system as a set of objects, which interact with each other by the services they provide. In addition, objects interact with users through their services so that they can avail of the required services in the system.
Generally, it is considered that object-oriented systems are easier to develop and maintain. Also, it is considered that the transition from object-oriented analysis to object-oriented design can be done easily. Note that object-oriented analysis comprises a number of steps, which include identifying objects, identifying structures, identifying attributes, identifying associations, and defining services.
3) Other Approaches
Many other approaches have been proposed for requirements analysis and. specification. These approaches help to arrange information and provide an automated analysis of requirements specification of the software. In addition, these approaches are used for organizing and specifying the requirements. The specification language used for modeling can be either graphical (depicting requirements using diagrams) or textual (depicting requirements in text form). Generally, the approaches used for analysis and specification include SADT, PSL/ PSA, RSL/REVS, and ER Modeling.
Structured Analysis and Design Technique (SADT) uses a graphical notation, and is generally applied in information processing systems. It comprises two parts, namely, Structured Analysis (SA) and Design Technique (DT). SA describes the requirements with the help of diagrams whereas DT specifies how to interpret the results.
Problem Statement Language (PSL) is a textual language, which is developed to describe the requirements of information systems. The Problem Statement Analyzer (PSA) is the processor that processes the requirements specified in PSL and then generates reports. PSL/PSA helps to document and communicate the software requirements.
1. Database modification report
2. Reference report
3. Summary report
4. Analysis report
Requirements Statement Language (RSL) is developed for real-time control systems. The REquirements Validation System (REVS) processes and analyzes the RSL statements. Note that both RSL and REVS are components of the Software Requirements Engineering Methodology (SREM).
ER diagram is used in different phases of software development.ER diagram comprises data objects and entities, data attributes, relationships, and cardinality and modality.
Data object is a representation of composite information used by software. Composite information refers to different features or attributes of a data object and this object can be in any of the following forms.
1. External entity: Describes the data that produces or accepts information. For example, a report.
2. Occurrence: Describes an action of a process. For example, a telephone call.
3. Event: Describes a happening that occurs at a specific place or time. For example, an alarm.
4. Role: Describes the actions or activities assigned to an individual or object. For example, a systems analyst.
5. Place: Describes the location of objects or storage area. For example, a wardrobe.
6. Structure: Describes the arrangement and composition of objects. For example, a file.
An entity is a data that stores information about the system in a database. Examples of an entity include real-world objects, transactions, and persons.
Data attributes describe the properties of a data object. Attributes that identify entities are known as key attributes. On the other hand, attributes that describe an entity are known as non-key attributes.
Generally, a data attribute is used to perform the following functions.
1. Naming an instance (occurrence) of data object
2. Description of the instance
3. Making reference to another instance in another table. Based on this, three types of relationships exist among entities.
1. One-to-one relationship (1:1): Indicates that one instance of an entity is related only to one instance of another entity. For example, in a database of users in a bank, each user is related to only one account number.
2. One-to-many relationship (I: M): Indicates that one instance of an entity is related to several instances of another entity. For example, one user can have many accounts in different banks.
3. Many-to-many relationship (M: M): Indicates that many instances of entities are related to several instances of another entity. For example, many users can have their accounts in many banks.
Cardinality specifies the number of occurrences (instances) of one data object or entity that relates to the number of occurrences of another data object or entity. It also specifies the number of entities that are included in a relationship. Modality describes the possibility of whether a relationship between two or more entities and data objects is required. The modality of a relationship is a if the relationship is optional. However, the modality is 1 if an occurrence of the relationship is essential.
To understand the concept of cardinality and modality properly, let us consider an example. The user entity is related to the order entity. Here, the cardinality for the 'user' entity indicates that the user places an order whereas modality for the 'user' entity indicates that it is necessary for a user to place an order. Cardinality for 'order' indicates that a single user can place many orders whereas modality for 'order' entity indicates that a user can arrive without any 'order'.
A use-case diagram describes what exists outside the system (actors) and what should be performed by the system (use-cases).
Let us consider the example of online registration of a user with a bank to understand how users interact with the system. The Use-case diagram represents two actors that interact within the system. These actors are the user (who interacts with the system to register in the bank) and the bank staff (who provides facilities to the user). There are several use-cases in this diagram, namely, request for registration, display registration form, edit user database, add user name and date, and update.
No comments:
Post a Comment