Download
1 / 90
900 likes | 905 Views
Analysis and design modeling. Chapter 3. Visit to more Learning Resources. Analysis Modeling. Basic aim of analysis modeling is to create the model that represents the information,functions and behavior of the system to be built.
E N D
Analysis and design modeling Chapter 3 Visit to more Learning Resources
Analysis Modeling • Basic aim of analysis modeling is to create the model that represents the information,functions and behavior of the system to be built. • Afterwards these all are translated into architectural,interface and component level designs in design modeling. • Analysis model acts as a bridge between system description and design model.
Objectives of analysis modeling • To state clearly what customer wants exactly. • To establish the basic of the design model. • To define the set of requirement
Analysis modeling approaches • Analysis modeling is the first technical representation of system • Methods for analysis modeling are:- • Structured analysis • Object oriented analysis.
Structure of structured analysis model is as shown in above fig. • At the center of model is a data dictionary. • Data dictionary is a repository that contains descriptions or information of all data objects used or created by the software. • Surrounding area of the core is occupied by different diagrams such as:- • E-R diagram • Data Flow Diagram • State transition diagram
1. E-R diagram E-R diagram is mainly used to represent the relationship between two entities or data objects. • This diagram is used to execute data modeling activity. • The additional information about data objects can be given with the help of data objects description.
2. Data flow diagram Data Flow Diagram used for following reasons:- • Representing data transformation through the system. • To show the functions with its sub functions those are responsible for transforming the data flow. • The description of every function is written using process specification
3. State transition diagram • It indicates the behavior of the system as an outcome of external events. • It represents the different modes of behavior called states of the system. • It also shows the fashion in which transitions are made from one state to another state. • The additional information that is required for control attribute is written using control specification
Object oriented analysis • The basis of object oriented analysis is classes and members,objects and attributes. • Classes are collection data members and operations to be operated on data members. • Objects are run time entities that encapsulates data members and member functions. • The objective of OOA is to define all classes that are related to the problem,operations and attributes with class,relationship between classes ,operations,and attributes need to be presented.
Steps to perform object oriented analysis • Find out the exact customer requirement. • Prepare scenarios or use cases. • Selection of classes and objects based on requirement. • Defines attributes and operations for every system object. • Design structure and hierarchies that will help organizing classes. • Construct an object relationship and behavior model.
Domain analysis. • Software domain analysis can be designed as a process of recognizing, analyzing and specifying of common requirements from a specific application domain. • It finds the common requirements in the project. • Application domain common objects, common classes, common frameworks can be identified and can be reused. • Eg: The specific application domain may be 'bus reservation system' can be used for 'railway reservation system'.
Technical Domain • Technical domain of the software is related to the common technical requirements which can be shared by many products. • Ex: most of the mobile applications use common facilities called calling, sending messages, access to the Internet etc. • Many applications can be developed where we do not write above requirements again and again. • They can be used by any applications once installed on the mobile phone. These activities use specific technical requirements that combine hardware with software.
Application Domain • The application domain is the common library that contains the classes that can be used by other products to minimize their work. • Domain analysis helps in finding out common requirements of the software and its domain is created. It is called specific application domain. • Ex: In finance and banking, different financial products are offered to the customers such as different types of accounts, fixed deposits, mutual funds, insurance , loans, etc., comes under specific application domain. • Once it is created, many other software products can use it.
Goals of Domain Analysis • Find out common requirement specification. • To save the time. • Reduce the repeated or duplicate work. • Reduction in the complications of the project. • To make library of classes available. • To enhance the portability.
Figure shows the flow of the input and the output data in the domain analysis module. • The main goal is to create the analysis classes and common functions. • The input consists of the knowledge domain. • The input is based on the technical survey, customer survey and expert advice. • This data is then analyses, meaningful information comes out from this. • The output domain consists of reusable classes,standards,functional models and domain language.
Scenario based Elements The system is described from the user‘s point of view using this approach. This is often the first part of analysis model that is developed to serve as input for the creation of other modeling elements.
Class-based Elements Each usage scenario implies a set of objects that are manipulated as an actor interacts with the system. These objects are categorized into classes – a collection of things that have similar attributes and common behaviors.
Behavioral Elements The behavior of the system can have profound effect on the design that is chosen. The analysis model must provide modeling elements that depict the behavior. The state diagram is one of the methods for representing behavior of a system.
Flow-Oriented Elements The information is transformed as it flows through the computer based system. The system accepts inputs in a variety of forms, applies functions to transform it; and produces output in different forms. The transforms may comprise a single logical comparison, a complex numerical algorithm or an expert system. The elements of the information flow are included here.
Data modeling concepts It includes :- • Data objects • Data attributes • Data relationship • Cardinality and Modality
1. Data objects A data object is a representation of almost any composite information that must be understood by software. A data object can be an external entity, a thing, an occurrence or event, a role, an organizational unit, a place or a structure. For ex, a person or a car can be viewed as a data object in the sense that either can be defined in terms of a set of attributes. A data object encapsulates data only—there is no reference within a data object to operations that act on the data.
Data Attributes Data attributes define the properties of a data object and take on one of three different characteristics. They can be used to 1. name an instance of data object. 2. describe the instance. 3. make reference to another instance in another table. In addition, one or more attribute must be identifier. Referring to data object car, identifier might be ID number.
Data Relationship Relationship indicates how Data objects are connected to one another in different ways. ex. Consider two data objects, person and car. Customer purchases the car. Here purchase is the relation. These objects can be represented using the simple notation.
A connection is established person and car because the two objects are related. But what are the relationships? We can define a set of object/relationship pairs that define the relevant relationships. For ex > A person owns a car. > A person is insured to drive a car. The arrows provide important information about the directionality of the relationship and reduce confusion.
Cardinality and Modality A simple pair that states that objectX relates to objectY does not provide enough information for software engineering purposes. We must understand how many occurrences of objectX are related to how many occurrences of objectY. This leads to data modeling concept called cardinality. “Cardinality is the specification of the number of occurrences of one object that can be related to the number of occurrences of another object.”
For ex, one object can relate to only one other object (1:1 relationship)- a college is having only one principal; one object can relate to many objects (1:N relationship)-one class may have many students; some number of occurrences of an object can relate to some other number of occurrences of another object (M:N relationship) -an uncle may have many nephews while a nephew may have many uncles.
Cardinality also defines ”the maximum number of objects that can participate in a relationship”. The modality of a relationship is 0 if there is no explicit need for the relationship to occur or the relationship is optional. The modality 1 if an occurrence of the relationship is mandatory
Flow oriented modeling Data flow oriented modeling continues to be one of the most widely used analysis notations today. The DFD takes an input-process-output view of a system. Data object flow into the software, are transformed by processing elements, and resultant data objects flow out of the software. Data objects are represented by labeled arrows and transformation are represented by circles.
Data flow diagram DFD enables the software engineer to develop models of the information domain and functional domain at the same time.
A few simple guidelines can aid immeasurably during derivation of a data diagram 1. The level 0 data flow diagram should depict the software/system as single bubble. 2. Primary input and output should be carefully noted. 3. Refinement should begin by isolating processes, data objects and data stores to be represented at the next level. 4. All arrows and bubbles should be labeled with meaningful names. 5. Information flow continuity must be maintained from level to level 6. One bubble at a time should be refined.
A data flow diagram is a graphical representation that depicts information flow and the transforms that are applied as data move from input to output. A DFD shows what kinds of data will be input to and output from the system, where the data will come from and go to, and where the data will be stored.
DFD Notations • A circle (bubble) represents a process or transform that is applied to data (or control). • An arrow represents one or more data items (data objects). • All arrows on a data flow diagram should be labeled. • The double line represents a data store stored information that is used by the software.
Context Level Data Flow Diagram • Shows the interaction between the system and external agents • The system's interactions with the outside world are modeled purely in terms of data flows across the system boundary. • Shows the entire system as a single process, and gives no clues as to its internal organization
Level 0 DFD • This context‐level DFD is next "exploded", to produce a Level 0 DFD that shows some of the detail of the system being modeled. • The Level 0 DFD shows how the system is divided into sub‐systems (processes) • It also identifies internal data stores that must be present in order for the system to do its job • It shows the flow of data between the various parts of the system.
Data Dictionary Data dictionary is the centralized collection of information about data. It stores meaning and origin of data, its relationship with other data, data format for usage etc. Data dictionary has rigorous definitions of all names in order to facilitate user and software designers. Data dictionary is often referenced as meta-data (data about data) repository. It is created along with DFD (Data Flow Diagram) model of software program and is expected to be updated whenever DFD is changed or updated. Data dictionary provides a way of documentation for the complete database system in one place. Validation of DFD is carried out using data dictionary.
Requirement of Data Dictionary The data is referenced via data dictionary while designing and implementing software. Data dictionary removes any chances of ambiguity. It helps keeping work of programmers and designers synchronized while using same object reference everywhere in the program.
Contents Data dictionary should contain information about the following 1. Data Flow 2. Data Structure 3. Data Elements 4. Data Stores 5. Data Processing
