Download
1 / 36
360 likes | 383 Views
Software Modelling and Design. Unit IIII. Translating requirement model into design model.
E N D
Software Modelling and Design Unit IIII
The Control Specifications (CSPEC) is used to indicate (1) how the software behaves when an event or control signal is sensed and (2) which processes are invoked as a consequence of the occurrence of the event. • The process specification describes the input to a function, the algorithm, the PSPEC indicates restrictions and limitations imposed on the process (function), performance characteristics that are relevant to the process, and design constraints that may influence the way in which the process will be implemented. • A data dictionary is a structured repository of data about data. Weekly timesheet=Emplyee_Name+ Employee_ID + {Regular_hours + overtime_hours} Pay_rate = {Horly | Daily | Weekly} + Dollar_amount Employee_Name = Last + First + Middle_Init
Each of the elements of the analysis model provides information that is necessary to create the four models required for a complete specification of design. 1. The data/class design transforms analysis classes into design classes along with data structurerequired for a complete specification of design. 2. The architectural design defines the relationship between major structural elements of the software; architectural styles and design patterns help achieve the requirements defined for the System. 3. The interface design describes how the software communicates with systemsthat interoperate with it and with humans that use it. 4. The component-level design transforms structural elements of the software architecture into procedural description of software components.
Data Modelling • Data modeling is the process of creating a data model for the data to be stored in a Database. • This data model is a conceptual representation ofData objects.
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. • Cardinality is usually expressed as simply ‗one‘ or ‗many‘. • Example: One object can relate to only one other object (a 1:1 relationship); • One object can relate to many other objects (a 1: N relationship); • Some number of occurrences of an object can relate to some other number of occurrences of another object (an M: N relationship);
Relationships • Data object are connected to one another in variety of different ways. This links or connection of data objects or entities with each other is called as relationship. • Example: A connection is established between person and car , because the two objects are related. 1. A person owns a car 2. A person purchase a car
Data objects A data object‖ is a representation of almost any composite information that must be understood by software. By composite information, something that has a number of different properties or attributes. Example: Width‖ (a single value) would not be a valid data object, but dimensions (incorporating height,widthand depth) could be defined as an object.
Attributes Attributes define the properties of a data object and take one of three different characteristics. (The data stored in database at a particular moment of time is called instance of database.) They can be used to: 1. Name an instance of the data objects, 2. Describe the instance, 3. Make reference to another instance in another table. Example: attributes must be defined as ―identifier‖. Referring to data object car‖, a reasonable identifier or attribute might be the ID No‖,‖ Color‖.
Analysis Modeling • The analysis model and requirements specification provide a means for assessing quality once the software is built. • Requirements analysis results in the specification of software‘s operational characteristics.
The analysis model as a bridge between the system description and the design model. Objectives Analysis model must achieve three primary objectives: 1. Describe customer needs 2. Establish a basis for software design 3. Define a set of requirements that can be validated once the software is built.
Scenario based Elements The system is described from the user‘s point of view using this approach. This is 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. A Class Responsibility Collaborator (CRC) model
Behavioral Elements The behavior of the system can have profound effect on the design that is chosen. 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.
Domain Analysis 1.Defination • Domain Analysis is the process that identifies the relevant objects of an application domain. • The goal of Domain Analysis is Software Reuse. • The higher is the level of the life-cycle object to reuse, the larger are the benefits coming from its reuse, and the harder is the definition of a workable process.
2. Concept and technical application domain of the software • Frameworks are excellent candidates for Domain Analysis: they are at a higher level than code but average programmers can understand them. (b) Umbrella activity involving the Identification, analysis, and specification of common requirements from a specific application domain, typically for reuse in multiple projects (c) Object-oriented domain analysis involves the identification, analysis, and specification of reusable capabilities within a specific application domain in terms of common objects, classes, subassemblies, and frameworks
3. Input and Output Structure of domain analysis (a) Figure shows the flow of the input and the output data in the domain analysis module. (b) The main goal is to create the analysis classes and common functions. (c) The input consists of the knowledge domain. (d) The input is based on the technical survey, customer survey and expert advice. (e) The output domain consists of using the input as the reference and developing the functional models
Design Modeling Software design is an iterative process through which requirements are translated into a ―blueprint‖ for constructing the software. The design is representation at a high level of abstraction – data, functional, and behavioral requirements. As design iterations occur, subsequent refinement leads to design representations at much lower levels of abstraction. There are three characteristics that serve as a guide for the evaluation of a good design: 1. The design must implement all the explicit requirements contained in the requirements model, and it must accommodate all the implicit requirements desired by stakeholders. 2. The design must be a readable, understandable guidefor those who generate code and for those who test and subsequently support the software. 3. The design should provide a complete picture of the software, addressing the data, functional and behavioral domains for implementation.
Modularity : Software architecture and design patterns embody modularity; that is, software is divided into separately named and addressable components, sometimes called modules that are integrated to satisfy problem requirements. It is the compartmentalization of data and function. It is easier to solve a complex problem when you break it into manageable pieces. ―Divide-and-conquer‖. Don‘t over-modularize. The simplicity of each small module will be overshadowed by the complexity of integration ―Cost‖.
Information Hiding • Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary to achieve software function. • The use of Information Hiding as a design criterion for modular systems provides the greatest benefits when modifications are required during testing and later, during software maintenance. • Because most data and procedures are hidden from other parts of the software, inadvertent errors introduced during modifications are less likely to propagate to other location within the software.
Abstraction • At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At lower levels of abstraction, a more detailed description of the solution is provided. As we move through different levels of abstraction, we work to create procedural and data abstractions. • A procedural abstraction refers to a sequence of instructions that have a specific and limited function. An example of a procedural abstraction would be the word open for a door. A data abstraction is a named collection of data that describes a data object. • In the context of the procedural abstraction open, we can define a data abstraction called door. Like any data object, the data abstraction for door would encompass a set of attributes that describe the door (e.g. door type, swing direction, weight).
Data Flow Diagram (DFD) 1) Data Flow Diagram (DFD) is also called as Bubble chart‘. This is a graphical technique that represents information flow, and transformer those are applied when data moves from input to output. 2) DFD represents system requirements those becomes program in design. 3) DFD may be further partitioned into different levels to show detailed information flow e.g. level 0, level 1, level 2 etc.
4) DFD focuses on the fact ̳what data flow‘ rather how data is processed 5) DFD is used to represent information flow, and the transformers those are applied when data moves from input to output. 6) To show the data flow with more details the DFD is further extended to level 1, level 2, level 3 etc. as per the requirement. 7) The typical value for the DFD is seven. Any system can be well represented with details up to seventh levels.
Level 0 First level of DFD is known as Context level or Level 0 which gives overall working of System. Level 1 gives modularize representation of system containing primary modules of system. From Level 2 onwards a designer starts revisiting each and every module to go in depth analysis of system which contains smaller functions to be performed by every module.
level 0 and level 1 Dataflow diagram for “Online examination. Win17 of form filling on MSBTE website”.
