Unit ii update
- 1. Major Learning Outcomes Topics and Sub-topics
- 2. Identify software requirement Analyze and design requirement Develop Activity and use-case diagram Topics and Sub-topics Requirement Gathering and Analysis Software Requirement Specification(SRS) Characteristic ,Customer requirement ,Functional Requirement Design Process Classification of Design Activities and Design Methodology Cohesion and Coupling Data Modelling Concepts Data Objects ,Data Attributes ,Relationships ,Cardinality and Modality Data-Flow Diagrams Primitive Symbols of DFD ,Develop DFD Model of System Shortcoming of DFD Model Scenario-Based Modelling Writing Use-Cases and Developing an Activity Diagram Architectural design decisions Architectural views , Architectural patterns ,Application architectures
- 3. The requirements analysis and specification phase starts once the feasibility study phase is complete and the project is found to be financially and technically feasible. Goal of this phase is to clearly understand the customer requirements and to systematically organize these requirements in a specification document. This phase consist of the two activities: o Requirements gathering and analysis o Requirements specification
- 4. Requirements Gathering : it involves interviewing the end users and customers and studying the existing documents to collect all possible information of the system. If there is no old working system is present than this task is required more imagination and creativity. Analysis of gathered requirements : the main purpose of this activity is to clearly understand the exact requirements of the customer The following basic questions can be used to understand exact requirement.
- 5. What is the problem? Why is it important to solve the problem? What are the possible solutions to the problem? What exactly are the data input to the system and what exactly are the data output by the system? What are the likely complexities that might arise while solving the problem? If there are external software or hardware with which the developed software has to interface, then what exactly would the data interchange formats with the external system be?
- 6. After the analyst has understood the exact customer requirements, he proceeds to identify and resolve the various requirements problems. The most important requirements problems that the analyst has to identify and eliminate are the problems of anomalies, inconsistencies, and incompleteness. When the analyst detects any inconsistencies, anomalies or incompleteness in the gathered requirements, he resolves them by carrying out further discussions with the end users and the customers.
- 7. After the software analyst has collect all information and remove all problems than he starts to systematically organize the requirements in the form of SRS document. SRS Document usually contains all the user Requirements. it is a contract document between customer and development organization. Once the customer agree to SRS Document the development team starts to develop the product and implement all functionalities which are specified in SRS document. There are many types of users of SRS Document during software development process.
- 8. Users ,Customers and marketing personnel. Software developers. Test Engineers. User Documentation writers. Project managers. Maintaince engineers
- 9. The important parts of SRS document are: Functional requirements of the system Non-functional requirements of the system Goals of implementation Functional requirements:- The functional requirements part discusses the functionalities required from the system. The system is considered to perform a set of high- level functions {fi}.
- 10. Each function fi of the system can be considered as a transformation of a set of input data (i) to the corresponding set of output data (o). The user can get some meaningful piece of work done using a high-level function
- 11. Nonfunctional requirements deal with the characteristics of the system which can not be expressed as functions - such as the maintainability of the system, portability of the system, usability of the system, etc. Nonfunctional requirements may include: reliability issues, accuracy of results, human - computer interface issues, constraints on the system implementation, etc.
- 12. The goals of implementation part documents some general suggestions regarding development. The goals of implementation section might document issues such as revisions to the system functionalities that may be required in the future, new devices to be supported in the future, reusability issues, etc. These are the items which the developers might keep in their mind during development so that the developed system may meet some aspects that are not required immediately.
- 13. So if the requirements in form of the function (input and output) than you can documented as a functional requirements. Any other requirements which can be verified by inspecting the system, are documented as a non-functional requirements. The suggestions for the developers , are documented as goals of the implementation.
- 14. The high-level functional requirements often need to be identified either from problem description or from a conceptual understanding of the problem. Each high-level requirement means to perform some meaningful piece of work. There can be many types of users of a system and their requirements from the system may be very different. So, it is often useful to identify the different types of users who might use the system and then try to identify the requirements from each user.
- 15. Here we list all functions {fi} that the system performs. Each function fi as shown in fig.is considered as a transformation of a set of input data to some corresponding output data.
- 16. Example: Consider the case of the library system, where F1: Search Book function Input: an author’s name Output: details of the author’s books and the location of these books in the library
- 17. So the function Search Book (F1) takes the author's name and transforms it into book details. Functional requirements actually describe a set of high-level requirements, where each high-level requirement takes some data from the user and provides some data to the user as an output. Also each high-level requirement might consist of someother functions.
- 18. For documenting the functional requirements, we need to specify the set of functionalities supported by the system. A function can be specified by identifying the input to the system(input domain) , and the type of processing to be carried on the input data to obtain the output data, the output data domain. Let us first try to document the withdraw-cash function of an ATM (Automated Teller Machine) system. The withdraw-cash is a high-level requirement. It has some sub-requirements corresponding to the different user interactions. These different interaction sequences capture the different scenarios.
- 19. Example: - Withdraw Cash from ATM R1: withdraw cash Description: The withdraw cash function first determines the type of account that the user has and the account number from which the user wishes to withdraw cash. It checks the balance to determine whether the requested amount is available in the account. If enough balance is available, it outputs the required cash, otherwise it generates an error message.
- 20. R1.1 select withdraw amount option Input: “withdraw amount” option Output: user prompted to enter the account type. R1.2: select account type Input: user option Output: prompt to enter amount. R1.3: get required amount Input: amount to be withdrawn in integer values greater than 100 and less than10,000 in multiples of 100. Output: The requested cash and printed transaction statement. Processing: the amount is debited from the user’s account if sufficient balance is available, otherwise an error message displayed.
- 21. The important properties of a good SRS document are the following: Concise : The SRS document should be concise and at the same time unambiguous, consistent, and complete. irrelevant descriptions reduce readability and also increase error possibilities. Structured : It should be well-structured. A well- structured document is easy to understand and modify. Therefore, in order to make the modifications to the SRS document easy, it is important to make the document well-structured.
- 22. Black-box view : It should only specify what the system should do and not specify how to do these. This means that the SRS document should specify the external behavior of the system. The SRS document should view the system to be developed as black box. For this reason, the SRS document is also called the black-box specification of a system. Conceptual integrity : It should show conceptual integrity so that the reader can easily understand it. Verifiable : All requirements of the system as documented in the SRS document should be verifiable.
- 23. Most important problems are incompleteness, ambiguity and contradiction Following are the some other category of problems that occur in many SRS documents Over Specification :over specification means when you try to address ‘how to’ aspects in SRS document. Forward references :you should not refer to aspects that are discussed much later in the SRS document. Wishful thinking :The type of problem aspects which would be difficult to implement
- 24. The important problems that an organization would face if it does not develop an SRS document are as follows : Without developing the SRS document, the system would not be implemented according to customer needs. Software developers would not know whether what they are developing is what exactly required by the customer Without SRS document, it will be very much difficult for the maintenance engineers to understand the functionality of the system. It will be very much difficult for user document writers to write the users’ manuals properly without understanding the SRS document.
- 25. Software design deals with transforming the customer requirements, as described in the SRS document, into a form (a set of documents) that is suitable for implementation in a programming language The following item must be designed during the design phase : Different modules and relationship between modules Interface among the modules. Data base and Data structure for individual modules Algorithm to implement individual modules So in design phase SRS document as the input and all the above document is output.
- 26. A good software design is not a single step procedure but require several iterations. Design activities can be broadly classified into two important parts (Classification of Design Activities): Preliminary (or high-level) design and Detailed design. Preliminary and detailed design activities High-level design means identification of different modules and the control relationships among them and the interfaces among these modules. The outcome of high-level design is called the program structure or software architecture. During detailed design, database ,data structure and the algorithms of the different modules are designed. The outcome of the detailed design stage is usually known as the module-specification document.
- 27. Design methodology provide guidelines for the design activity. It depends on the following factors. Type of software Software development environment User requirements Qualification of development team Available software and hardware resources. There are many methodologies for software design for different types of problems.
- 28. Design methodology Functional oriented Design(Top Down) Structured Analysis (DFD Diagram) Structured Design Object Oriented Design(bottom up) Class Diagram and UML Diagrams
- 29. The definition of “a good software design” can vary depending on the application being designed. For example, the memory size used by a program may be an important issue to for a good solution for embedded software development. For embedded applications, the other factors of design are not important. Therefore, the criteria used to judge the good design depends upon the application.
- 30. However, the general features of good design that must be in all types of software. Correctness: A good design should correctly implement all the functionalities identified in the SRS document. Understandability: A good design is easily understandable. Efficiency: It should be efficient. Maintainability: It should be easily amenable to change.
- 31. Possibly the most important goodness criterion is design correctness. Second important goodness criterion is understandability of a design. A design that is easy to understand is also easy to develop, maintain and change.
- 32. In order to facilitate understandability, the design should have the following features(Features of a Design Document) : It should use consistent and meaningful names for various design components. The design should be modular. The term modularity means that it should use a cleanly decomposed set of modules. It should neatly arrange the modules in a hierarchy, e.g. in a tree-like diagram. In short Modularity ,clean decomposition ,Neat arrangement are three main features of any software design.
- 33. Good software design means that clean decomposition of the problem into modules, and the neat arrangement of these modules in a hierarchy. The primary characteristics of neat module decomposition are high cohesion and low coupling. Cohesion is a measure of functional strength of a module where as the coupling between two modules is a measure of the degree of interdependence or interaction between the two modules. A module having high cohesion and low coupling is said to be functionally independent of other modules. By the term functional independence, we mean that a cohesive module performs a single task or function. A functionally independent module has minimal interaction with other modules.
- 34. Functional independence is a key to any good design due to the following reasons : Error isolation is easy so one error in one module not directly affect other module. Scope for reuse become possible. Understandability is easy because all module are independent so complexity is less.
- 35. The different classes of cohesion that a module may contain are shown in the following fig. Coinci- dental Logical Temporal Proce- dural Communi- cational Sequen- tial Funct- ional Low high Fig. - Classification of Cohesion
- 36. Coincidental cohesion: A module is said to have coincidental cohesion, if it performs a set of tasks that relate to each other very loosely. Logical cohesion: A module is said to be logically cohesive, if all elements of the module perform similar operations. Temporal cohesion: when all functions of module execute in same time span than we can say module contain temporal cohesion Procedural cohesion: when set of functions of the module are all part of a same procedure (algorithm) than we can say module contain Procedural cohesion
- 37. Communicational cohesion: A module is said to have communicational cohesion, if all functions of the module refer to or update the same data structure, e.g. the set of functions defined on an array or a stack. Sequential cohesion: if the elements of a module form the parts of sequence, where the output from one element of the sequence is input to the next than we can say module contain Sequential cohesion Functional cohesion: Functional cohesion is said to exist, if different elements of a module achieve a single function.
- 38. Coupling between two modules is a measure of the degree of interdependence or interaction between the two modules. A module having high cohesion and low coupling is said to be functionally independent of other modules. If two modules interchange large amounts of data, then they are highly interdependent. The degree of coupling between two modules depends on their interface complexity. The interface complexity is basically determined by the number of types of parameters that are interchanged while invoking the functions of the module.
- 39. The different classes of Coupling that can exist between module are shown in the following fig. Data Stamp Control Common Content Low high Fig. - Classification of coupling
- 40. Data coupling: Two modules are data coupled, if they communicate through a parameter. An example is an elementary data item passed as a parameter between two modules, e.g. an integer, a float, a character, etc. Stamp coupling: Two modules are stamp coupled, if they communicate using a composite data item such as a record in PASCAL or a structure in C. Control coupling: Control coupling exists between two modules, if data from one module is used to direct the order of instructions execution in another. An example of control coupling is a flag set in one module and tested in another module.
- 41. Common coupling: Two modules are common coupled, if they share data through some global data items. Content coupling: Content coupling exists between two modules, if they share code, e.g. a branch from one module into another module. High coupling among modules not only makes a design difficult to understand and maintain but it also increase development effort because modules having high coupling can not be developed independently by different team members. modules having high coupling are difficult to implement and debug.
- 42. Data Model is a conceptual relationship between data structure (tables) used in database. It provide abstract and conceptual representation of data. Data modeling or ER diagram gives the concept of Data objects (entity),attributes and relationship between objects .
- 43. Data Objects(Entity Set) : real world entity or thing for which you want to store data. Attributes : it is property of entity. Relationship : connection between entities. Cardinality : no of objects that participate in relationship. One to one ,one to many and many to many. Modality : Classification of relationship.it is 0 if no need for the relationship. And it is 1 if relationship is mandatory.
- 46. COLLEGE has PRINCIPAL COLLEGE STUDENTShas STUDENTS SUBJECTS have
- 48. The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that shows the different processing activities or functions that the system performs and the data interchange among these functions. Each function is considered as a processing station (or process) that consumes some input data and produces some output data. The system is represented in terms of the input data to the system, various processing carried out on these data, and the output data generated by the system.
- 49. Main five symbols used for constructing DFDs are: Function symbol External Entity Symbol Data Flow Symbol Data Store Symbol Output Symbol
- 51. Function symbol is used to represent a function. This symbol is called a process or bubble. These bubbles are annotated with the corresponding function names. External Entity Symbol is used for representing those physical agents that are external to the software system. These agents interact with the software by providing or consuming data with the software system. Data Flow symbol shows the data flow between processes or physical agents and processes. The direction of data flow is given by the arrow and is usually labeled with corresponding data name. Data Store symbol represents a data structure or a logical file or a physical file on disk and will be connected to processes using data flow symbols. Output symbol is for representing output data produced by the software.
- 52. The complete DFD of a system is not constructed in a single step. Rather, first an abstract DFD is constructed and is refined in further stages to obtain a detailed DFD. Construction of a DFD starts with the most abstract definition of the system. This abstract representation is called a Context Diagram or Level 0 DFD. In the Context Diagram the entire software is represented as a single bubble. The data inputs and outputs of the system is represented as a single bubble. The data inputs and outputs of the system is represented as incoming and outgoing arrows. In the Context Diagram the external entities with which the system interacts are identified and the data interchange occurring between the system and these external entities are represented.
- 53. Numbering of Bubbles:- It is necessary to number the different bubbles occurring in the DFD. These numbers help in uniquely identifying any bubble in the DFD by its bubble number. The bubble at the context level is usually assigned the number 0 to indicate that it is the 0 level DFD. Bubbles at level 1 are numbered, 0.1, 0.2, 0.3, etc, etc. When a bubble numbered x is decomposed, its children bubble are numbered x.1, x.2, x.3, etc.
- 54. Many beginners commit the mistake of drawing more than one bubble in the context diagram. A context diagram should depict the system as a single bubble. Many beginners have external entities appearing at all levels of DFDs. All external entities interacting with the system should be represented only in the context diagram. The external entities should not appear at other levels of the DFD. It is a common oversight to have either too less or too many bubbles in a DFD. Only 3 to 7 bubbles per diagram should be allowed, i.e. Each bubble should be decomposed to between 3 and 7 bubbles. Many beginners leave different levels of DFD unbalanced.
- 55. A common mistake committed by many beginners while developing a DFD model is attempting to represent control information in a DFD. It is important to realize that a DFD is the data flow representation of a system, and it does not represent control information.
- 58. UML is a modeling language. Standard language for specifying, visualizing, constructing, and documenting the software systems. The UML uses mostly graphical notations to express the design of software projects. It provides a set of notations (e.g. rectangles, lines, ellipses, etc.) to create a visual model of the system. UML Particularly useful for OO design. UML is Independent of implementation language
- 59. UML can be used to construct nine different types of diagrams to capture five different views of a system. The UML diagrams can capture the following five views of a system: User’s view Structural view Behavioral view Implementation view Environmental view
- 61. User’s view: This view defines the functionalities (facilities) made available by the system to its users. The users’ view captures the external users’ view of the system in terms of the functionalities offered by the system. The users’ view is a black-box view of the system where the internal structure, the dynamic behavior of different system components, the implementation etc. are not visible.
- 62. Structural view: The structural view defines the class and object which are important to the understanding of the working of a system and its implementation. It also captures the relationships among the classes(objects). The structural model is also called the static model, since the structure of a system does not change with time. Behavioral view: The behavioral view captures how objects interact with each other to realize the system behavior. The system behavior captures the dynamic behavior of the system.
- 63. Implementation view: This view captures the important components of the system and their dependencies. Environmental view: This view models how the different components are implemented on different pieces of hardware.
- 64. Use case model of the system consists of a set of use cases. Use cases represent the different ways in which a system can be used by the users. The purpose of a use case is to define the logical behavior of the system without knowing the internal structure of it. It provides understanding of the system. It identifies the functional requirements of the system. it describes “who can do what in a system”. A use case typically represents a sequence of interactions between the user and the system. A simple way to find all the use cases of a system is to ask the question:“What the users can do using the system?”
- 65. Thus for the Library Information System (LIS), the use cases could be: • issue-book • query-book • return-book • create-member • add-book, etc
- 67. Use case: Represented by an ellipse with the name of the use case written inside the ellipse. All the use cases are enclosed with a rectangle representing system boundary. Rectangle contains the name of the system. Actor: An actor is anything outside the system that interacts with it. Actors are represented by using the stick person icon. An actor may be a person, machine or any external system. Actors are connected to use cases by drawing a simple line connected to it.
- 68. Relationship: It is also called communication relationship. Actors are connected to use cases through relationship lines. An actor may have relationship with more than one use case and one use case may relate to more than one actor.
- 71. Activity diagrams represent workflows in an graphical way. The activity diagram focuses on representing activities. Activity diagrams are similar to flow charts. The difference is that activity diagram support parallel activities. An activity is a state with an internal action and one or more outgoing transitions. An interesting feature of the activity diagrams is the swim lanes. It enable you to group activities based on who performing them. Swim lanes subdivide activities based on responsibilities.
- 72. 72