Unit-III Analysis ,Design concept and principle

ANALYSIS MODEL: Analysis model is to provide a description of the required informational,functional and behavioral domains for a computer based system .The model changes dynamically as software engineers learn more about the system to be built.and stakeholders understand about they require.The reason is the analysis model is a instant of requirements at any given time and change it . The analysis model evolves ,certain element become stable providing a foundation for the design tasks.Even so other elements of the model may be more volatile (unstable) ,indicating the customer does not yet fully understand requirements for the system. Analysis Modeling Principles: A large number of developed analysis modeling methods,identified of analysis problems to overcome them vatiety of modeling notations and corresponding sets of heuristics to be used. 1.The information domain of a problem must be represented and understood. 2.The functions that the software performs must be defined. 3.The behavior of the software as a consequence of external events must be represented. 4.The models that depict information function and behavior must be partitiond in a manner that uncovers detail in a layered hierarchy fashion. 5.The analysis task should move from essential information towards implementation detail. Overall Objectives and Philosophy Analysis three primary objectives: 1.To describe what the customer requires. 2.To establish a basis for the creation of a software design. 3.To define a set of requirements that can be validated once the software is built.

System descripition

Analysis model

Design model

The analysis model link the gap between a system-level description that describes overall system functionality as it is achieved by applying software,hardware,data,human and other system elements and a software design model that describes the softwares application architecture,user interface and component level structure. Analysis Rules of Thumb: When creating the analysis model should be follow the Arlow and Neustadt thumb rules:

69

The model should focus on requirements that are visible within the problem or business domain (area) .The level of abstraction should be relatively high that to explain how the system will work. Each element of the analysis model should add to an overall understanding of software requirements and provide within reach into the information domain,function and behavior of the system. Delay consideration of infrastructure(communications) and other non-functional models until design. Example a database may be required ,but the classes necessary to implement it,the functions required to access it and database used the behavior (activities)will be displayed only after problem domain analysis has been completed. Minimize Coupling(combination) throughout the system.It is important to represent relationships between classes and functions.so far if the level of interconnectedness is very high efforts should be made to reduce it. Be certain that the analysis model provides value to all stakeholders.Each stake holders has own use for model Example business stakeholders should use the model to validate requirements ,designers should use the model as a basis for design,Quality assurance people should use the model to help plan acceptance tests. Keep the model as simple as it can be .When no new information provide dont add additional diagrams ,when a simple list will use dont use complete notational (symbol)form. Domain Analysis: Firesmith describes domain analysis in the following way: Software domain analysis is the identification,analysis and specification of common requirements from a specific application domain ,normally for reuse on multiple projects within application domain. Object oriented anlysis is the identification ,analysis and specification of common,reusable capabilities within a specific application domain in terms of common objects,classes,subassemblies and framework. The goal of domain analysis: To find or create those analysis classes and /or common functions and features that are applicable and they may be reused.

Input and output for domain analysis The Input and Output for domain analysis diagram shows that source of domain knowledge are analysised try to identify objects that can be reused across the domain. ANALYSIS MODELING APPROACHES: Structured analysis:

70

The first approach of analysis modeling is structured analysis,which that mapping data and processes that transfom the data as separate entities. o Data objects define their attribute and relationships. o Process manipulate the data object transform as data flow through the system such as ERD,DFD. Object-Oriented analysis: The Second approach of analysis modeling called object oriented analysis is to define all classes and the relationships and behavior associated with them that are relevant to the problem to be solved.UML and Unified process are Object-Oriented. The following of tasks to accomplish the problem: 1.Basic user requirements must be communicated between the customer and the software engineer. 2.Classes must be identified i.e defined attributes and methods. 3.A class hierarchy is defined 4.Object to-object relationships should be represented 5.Object behavior must be modeled. 6.Tasks 1 through 5 are reapplied iteratively until the model is complete. Elements of the analysis model: Analysis model leads to the derivation of each of the modeling elements.The constructs of models as to showup certain critical features of a system, while simultaneously deemphasizing other aspects of the system.

71

Scenario Use-case Use-case Activity Swim la

Class-ba Class dia Analysis CRC mo Collabor

DATA MODELING CONCEPTS: Analysis modeling often begins with data modeling.The software engineer or analyst defines all data objects that are processed within the system,the relationships between the data objects and other information relevant to the relationships. Types of element in Data Modeling Data Objects Data Attributes Relationships Cardinality and Modality Data Objects: A data object is defines a composite information(data item) that is processed by software that is , it incorporate(join together) collection of individual data items(attributes) and gives the collection of the name of the data object. Therefore width is a single value would not be a valid data object,but dimension (height,width and depth) could defined as an object.

72

It encapsulate data only therefore the data object can be represented as a table,the heading (column name)in the table is attributes of the object. Example :object is a car defined in terms of model ,ID numbe,Body type,color and owner.The body of the table represents specific instance of the data object. i.e BMW is an instance of the data object car. Tabular representation of data objects Naming attributes Make Model descriptive Identifier attributes ID# Body type Color Q12A45 Sedon XZ765 coupe Blue white Referential attributes Owner BLF IJL

Ford Tourus BMW 750il Instance

Data Attributes: Data attributes define the properties of a data object . It follows one of three different characteristics: 1)name an instance of the data object 2) describe the instance . 3)make reference to another instance in antoher table. The attribute as an identifier use as key to find an instance of the data object,values for identifiers are unique make reference to the data object. Relationships: Relationships indicate in which data objects are connected to one another . person car

Relationships between data objects The relationships owns and insured to drive define the relevant connections between person and car. The arrown provide information about the directionality of the relationships and reduce ambiguity or misinterpertations. Cardinality and Modality: The data model must be capable of representing the number of occurrences of objects in a given relationships Tillmann define the cardinality of an object or relationship pair in the following manner: 73

Cardinality is the specification of the number of occurrences of one object that can be related to the number of occurrences of another object. Types of Cardinality: 1:1 relationship one object can relate to only one other object. 1:N relationship- one object can relate to many objects. M:N relationship- some number of occurrences of an object can relate to some other nuber of occurrences of another object. It also defines the maximum number of objects that can participate in a relationship. Modality: Data model does not yet provide an indication of whether or not a particular data object must participate in the relationship,to specify information the data model adds modality to the object. The modality of relationship is 0 if there is no explicit(direct) need for the relstionship to occur or the relationship is optional. The modality of relationship is 1 if an occurrence of the relationship is mandatory. SCENARIO-BASED MODELING The success of a computer-based system or product is measured in many ways,user satisfaction resides(be located) at the top of the list. If software engineers understand how end-users and other actor want to interact with a system,the software team will be able to properly characterize requirements and build analysis and design models. Therefore analysis modeling with UML begins with the creation of scenarios in the form of Use-cases,activity diagrams and swimlane diagrams. Writing Use- cases: A use-case are part of analysis modeling for user interfaces the interaction that occur between producers and consumers of information and the system . The concept of a use-case is easy to understand ,describe a specific usage scenario in straightforward language from the point of view of a defined actor not only specific person but the actor is device also. The following questions that must be answered if use-cases are to provide value as an analysis modeling tool. 1.what to write about? 2.how much to write about it? 3.how detailed to make our description? 4.how to organize the description? What to write about it?: The first tasks inception and elicitation provide us the information ,need to begin writing use-cases . Requirements gathering meetings,Quality function deployment(QDF),and other reqirement engineering used to identify stakeholders,define the scope of the problem,specify overall

74

operational goals,outline all known functional requirements and describe the objects that will be manipulated by the system. To begin developing a set of use-cases: *The functions or activites performed by a specific actor are listed. *These may be obtained from a list of required system functions,through conversations with customers or end-users. *An evaluation of activity diagram developed as part of analysis modeling(requirement modeling). Example: The SafeHome home surveillance function(subsystem) discussed in the sidebar identifies the following functions (an abbreviated list) that are performed by the homeowner actor: Access camera surveillance via the internet. Select camera to view Request thumbnails from all cameras Display camera views in aPc window Control pan and zoom for a specific camera Selectivel y record camera output Replay camera output The requirement gathering team develops use-case for each of the functions. First use-cases are written in an informal narrative form.If formal writte is required,the same use-case is rewritten using a structured format similar to proposed and later reproduced as a sidebar. Preliminary use-case diagram: When scenario is complex diagrammatic representation easy to understanding .UML provide use-case diagramming capability. Preliminary use-case diagram for the (e.g)Safehome product ,each use-case is represented by a oval.

Developing an Activity Diagram: The UML diagram supplements the use-case by providing a graphical representation of the flow of interaction within a specific scenario. It is similar to flow chart,an activity diagram notation(symbol) -rounded rectangles to imply a specific system function. -arrows to represent flow through the system . -decision diamonds to indicate a branching decision. -solid horizontal line to indicate that parallel activities are occurring.

75

An activity diagram for the ACS_DCV function( access surveillance display camera view function:)

The activity diagram adds additional detail not directly mentioned by the use-case. For example a user may only attempt to enter userID and password a limited number of times,this is represented by a decision dicmond below prompt for reentry. Swimlane Diagrams: The UML swimlane diagram is a variation of the activity diagram and allows the modeler to represent the flow of activities by the use-case. And at the same time indicate suppose if there multiple actors involved in a specific function in which actor or analysis class has responsibility for the action described by an activity rectangle. Responsibilities are represented as parallel segments that divide the diagram vertically ,like the lanes in a swimmingpool. A UML swimlane diagram for access surveillance display camera view function:

76

The activity diagram is rearranged ,that activities associated with a particular analysis class inside the swimlane for the class. Example: The Interface class represents the user interface as seen by the homeowner. The responsibility of the interface is two prompt ,prompt for reentry and prompt for another view. These prompts and the dscision associated with them fall within the Interrface swimlane but arrows from that swimlane back to the Homeowner swimlane ,where homeowner actions occur. FLOW-ORIENTED MODELING: Data flow-oriented modeling is one of the most used analysis notations is a core modeling activity in structured analysis. Elements of flow-oriented modeling: *Creating a Data flow model *Processing narratives 77

*Creating a Control flow model * The Control Specification *The Process Specification Creating a Data Flow Model: The data flow diagram enables the software engineer at the same time to develop models of the information domain and functional domain. DFD is refined into greater level of detail,the analyst performs an implicit (indirect) functional decomposition of the system. DFD refinement result corresponding refinement data implied in through process in the application. DFD takes an input process-output view of a system that is data objects flow into the software are transformed by processing selements and resultant data objects flow out of the software. Data objects represented by labeled arrow and transformations are represented by circles also called bubbles. DFD is presented in hierarchical manner. The first data flow model called a level 0 DFD or context diagram represent the system as a whole.Subsequent data flow diagram providing increase detail with each subsequent level refine context diagram. The guidelines can aid immeasurably during derivation of a DFD: 1.The level 0 data flow diagram should describe the software/system as a single bubble. 2.primary input and output should be carefully noted 3.refinement should begin by isolating candidate processes,data objects and data stores to be represented at the next level 4.all arrows and bubbles should be labeled with meaning ful names. 5.information flow continuity must be maintained from level to level. 6.one bubble at a time should be refined. Context level DFD (level 0 DFD): The primary external entities (boxes) produce information for use by the system and consume information generated by the system. The labeled arrows represent data objects or in hierarchies. Example: Context level(level 0) DFD for the security Safe home function:

78

User command and data encompasses all configuration commands,all activation/deactivation commands ,all miscellaneous interactions and all data that are entered to expand a command. Processing narrative: It is similar to the use-case in style but different in purpose ,it provides an overall description of the function to be developed .It is not a scenario written from one actors point of view. The level 0 DFD expanded into a level 1 data flow model to proceed .A simple ,even so effective approach is to perform a grammatical parse on the processing narrative that describes the context level bubble. The following processing narrative text with the first occurance of all nouns underlined and the first occurrence of all verbs italicized Example : Safehome processing narrative: The Safehome security function enables the homeowner to configure the security system when it is installed,monitors all sensors connected to the security and interacts with the homeowner through the Internet a PC or a control panel. Level 1 DFD for Safehome processes: Referring to the grammatical parse ,verbs are represented as bubbles in a subsequent DFD. Nouns are either external entities (boxes),data or control objects (arrows) or data stored(double lines) ,that nouns and verbs can be associsated with one another. For example each sensor is assigned a number and type are attributes of the data object sensor.Therefore by performing a grammatical parse on the processing narrative for a bubble at any DFD level.

Level 2 DFD :

79

The processes represented at DFD level 1 can be further refined into lower levels.The information flow continuity has been mainted between levels 0 and 1. Example: The process monitor sensors can be refined into a level 2 DFD.

The refinement of DFDs continues until each bubble performs a simple function that would be easily implemented as a program component. Creating A Control Flow Model: Control flow modeling used for a large class of applications are driven by events rather than data ,produce control information rather than reports or displays and process information with heavy concern for time and performance. Already noted that an event or control item is implemented as a Boolean value i.e true or false,1 or 0 or a discrete list of conditions. The following guidelines to select potential(possible) candidate events:List all sensors that are read by the software. List all interrupt conditions. List all switches that are actuated by an operator. List all data conditions Recalling the noun/verb parse that was applied to the processing narrative,review all control items as possible for control flow inputs/outputs. o Describe the behavior of a system by identifying its states,identify how each state is reached and define the transitions between states. o Focus on possible omissions a very common error in specifying control;for example ask Is there any other way I can get this state or exit from it?. The Control Specification: The control specification (CSPEC) represents the behavior of the system in two different ways: 1. State diagram o o o o o

80

2. Program activation State diagram:It is a sequential specification of behavior. Program activation:It also contain a program activation table is a combinatorial specification of behavior. The CSPEC describes the behavior of the system ,but it gives us no information about the inner working of the process that are activated as aresult of this behavior. Example: The state diagram indicates that the transitions from the idle state can occur Two transitions occur out of the Monitoring system status state(1)when the system is deactivated a transition occurs back to the idle state,(2) when a sensor is triggered a transition to the Acting Alarm state occurs .During the review consider all transition and the content of all states . The Process Specification: The process specification (PSPEC) is used to describe all flow model processes that appear at the final level of refinement. The content of the process specification can include narrative text,a program design language(PDL) description of the algorithm,mathematical equations ,tables,diagrams or charts. The PSPEC is a mini specificationfor each transform at the lowest refined level of a DFD that as a guide for design of the software component that will implement the process. Example: The password transform represented in the flow model for Safehome the function is perform by PSPEC . If the password matches an entry within the table [valid id message=true] is passed to the message and status display function.If there is no matah [valid id message=false]is passed to the message and status display function. CLASS-BASED MODELING: Class-based element of an analysis model: Classes and objects Attributes Operations Packages CRC models Collaborations diagram Identifying Analysis Classes: To identify classes by examining the pbolem statement or by performing a grammatical parse the use-cases or processing narratives developed for the system to be built. Classes are determined by underlinining each noun or noun clause and enter it into a simple table. If the class is required to implement a solution then it is part of the solution space other wise ,if a class is necessary only to describe a solution ,it is part of the problem space. The following ways are for Analysis classes to manifest (marked) themselves: External entities that produce or consume information to be used by a computer-based system (e.g.) devices,people. 81

 Things that are part of the information domain for the problem(e.g.) reports ,displays leeters,signals. Occurrences or events that occur within the context of system operation(e.g) aproperty transfer or the completion of a series of robot movements. Roles played by who interact with the system(e.g) manager ,engineer,salesperson. Organizational units that are relevant to an application(e.g)division group,team Places that establish the context of the problem and the overall function of the system. (e.g) manufacturing floor ). Structures that define a class of objects or related classes of objects (e.g) sensors ,fourwheeled vehicles or computer. Budd suggests taxonomy (classification) of classes that includes producers(sources0 and consumers(sinks) of data,data manager,view and helper classes. A class should never have an imperative procedural name(e.g) an object with the name Imageinersion would making mistake so that inversion of the image the inversion() is an operation that applied to the class image. During early stage of modeling analysis class might be defined to the example of Safehome security function performed in a grammatical parse on a processing narrative.Extracting the nouns each entry in the list a potential object. Coad and Yourdon suggest six selection characteristics that should be used as an analyst considers each potential class for inclusion in the analysis model: 1.Retained information:The potential class will be useful during analysis only if information about it must be remembered so that the system can function 2.Needed services:The potential class must have a set of identifiable operations that can change the value of its attributes in some way. 3.Multiple attributes:During requirement analysis the focus should be on major information ; a class with a single attribute be useful during design ,but better to represent ed as an attribute of another class during the analysis activity. 4.Common attributes:A set of attributes can be defined for the potential class and these attributes apply to all instances of the class. 5.Common operations:A set of operation can be defined for the potential class and these operations apply to all instances of the class. 6.Essential requirements :External entities that appear in the problem space and produce and consume information important to the operation of any solution for the system will almost always be defined as classes in the requirements model. Specifying Attributes Attributes are the set of data objects that fully define the class within the context of the problem. Example: System systemID verificationPhonenuber systemStatus delaytime masterpassword program()

82

display() reset() query() modify() The shade portion is list of attributes for the system class. Defining Operations It define the behavior of an object .The types of operations are divided into three categories: (1)operations that manipulate data e.g.ading,deleting,reformatting,selecting (2)operations that perform a computation. (3)operations that inquire about the state of an object. (4)operations that monitor an object for the occurance of a controlling event. These functions are accomplished by operating on attributes and associations. Example: Safehome processing narrative the phrases indicate that a program() operation is encapsulated by the System class. Class-Responsibility-Collaborator(CRC) Modeling: Class-responsibility-collaborator modeling provides simple means for identifying and organizing the classes that are relevant to system or product requirements. Ambler describes CRC modeling in the following way: A CRC model is a collection of standard index cards that represent classes.The cards are divided into three sections DESIGN WITHIN THE CONTEXT OF SOFTWARE ENGINEERING Design Principle: 1.Design should be traceable to the analysis model. 2.Always consider the architecture of the system to be built. 3.Design of data is as important as design of processing functions. 4.Interfaces both internal and external must be designed with care. 5.User interface design should be tuned to the needs of the end-users. 6.Component level design should be functionally independent 7.Components should be loosely coupled to one another and to the environment. 8.Design representation(models) should be easily understandable 9.The design should be developed iteratively.With each iteration ,the designer should stive for greater simplicity. DESIGN PROCESS AND DESIGN QUALITY: Design process Design process is a sequence of steps carried through which the requirements are translated into a system or software model. Any design may be modeled as a direct graph. The graphs are collection of entities with attributes which participate in relationships. The system should be described at several different levels of abstraction. Design takes place in overlapping stages. Various phases of design process are as shown in following 1. In architectural design the subsystem components can be identified. 2. The abstract specification is used to specify the subsystems. 3. The interfaces between the subsystems are designed, which is called inter face design. 4. In component design of subsystems components is done. 83

5. The data structure is designed to hold the data. 6. For perfoming the required functionality, the appropriate algorithm is de signed. Software design is an iterative process through which requirements are translated into a design for constructing the software. The design is represented at a high level of abstraction,a level that can be directly traced to the specific system objective and more detailed data,functional and behavioral requirements. As design iteraton occur, subsequent refinement to design representation at lower levels of abstraction.
McGlaughin suggests three characteristics that serve as a guide for the evaluation of a good design:

Each of these characteristics is a goal of the design process. The design must implement all of the explicit requirements contained in the analysis model and it must accommodate all of the implicit(indirect) requirements desired by the customer. The design must be a readable ,understandable guide for those who generate code and for those who test and subsequently support the software. The design should provide a complete picture of the software ,addressing the data ,functional and behavioral domains from an implementation perspective. Quality guidelines: The following gidelines to evaluate the quality of a design representation 1.A design should display an architecture that (a) That has been created using recognizable architectural styles or patterns. (b)That is composed of components that show good design characteristics (c)That can be implemented in an evolutionary style thereby implementing and testing. 2.A design should be modular that is the software should be logically partitioned into elements or subsystems. 3.A design should contain distinct representation of data,architecture,interfaces and components. 4.A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns 5.A design should lead to components that show independent functional characteristics. 6.A design should lead to interfaces that reduce the complexity of connections between components and with the external environmemt. 7.A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis. 8.A design should be represented using a notation that effectively communicates its meaning. Quality attributes: Hewlett Packard deveopled a set of software quality attributes are given as acronym(short form) FURPS to represent a target(goal) for all software design:

84

 Functionality Usability Reliability Performance Supportability Functionality:It is assessed by evaluating the feature set and capabilities of the program,the generalization of the functions that are deliveredand the security of the overall system. Usability:It is assessed by human factors ,consistency and documentation. Reliability:It is evaluated by measuring the frequency and severity of failure,the accuracy of output results,the mean-time-to-failure(MTTF) ,the ability to recover from failure and predictability(unavoidability) of the program. Performance:It is measured by processing speed,response time,resource consumption ,throughput and efficiency. Supportability:Itcombin the abilitytoxtendtheprogram(extensibility),adaptability, Serviceability,mainability,testability,compatibility,configurability the ability to organize and control elements of the software congfiguration. Design Principles Davis suggested a set of principles for software design as: The design process should not suffer from tunnel vision. The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should minimize the intellectual distance between the software and the problem in the real world. The design should exhibit uniformity and integration. The design should be structured to degrade gently. Design is not coding and coding is not design. The design should be assessed for quality. The design should be reviewed to minimize conceptual errors. Design Concept The software design concept provides a framework for implementing the right software. Following issues are considered while designing the software. 1.Abstraction At each stage of software design process levels of abstractions should be applied to refine the software solution.At the higher level of abstraction, the solution should be stated in broad terms and in the lower level more detailed description of the solution is given. While moving through different levels of abstraction the procedural abstraction and data abstraction is created. In procedural abstraction it gives the named sequence of instruction in the specific function. In data abstracion the collection of data objects is represented. Levels of Abstraction Various levels of abstractions areLevel I - This level represents the solution interms of problem environment. Level II - This level represents the decomposition of terms that are moved from problem environment but still not at implementation stage. 85

Level III - At this level preliminary procedural representation exists. All the terminologies at this level are software oriented and implementation modularity begins at the surface. Level IV and V - The concepts of stepwise refinement and modularity are applied at this level. 2. Modularity
The software is divided into separately named and addressable components that called as modules. Creating such models bring the modularity in siftware. Meyer defines five criteria that enable us to evaluate a design method with respect to its ability to define an effective modular system: Modular decomposability : A design method provides a systematic mechanism for decomposing the problem into sub-problems. This reduces the complexity of the problem and the modularity can be achieved. Modular composability : A design method enables existing design components to be assembled into a new system. Modular understandability : A module can be understood as a standalone unit. Then it will be easier to build and easier to change. Modular continuity : Small changes to the system requirements result in changes to individual modules, rather than system- wide changes. Modular protection : An aberrant condition occurs within a module and its effects are constrained within the module.

3.Refinement Refinement is actually a process of elaboration. Stepwise refinement is a top-down design strategy proposed by Niklaus WIRTH. The architecture of a program is developed by successively refining levels of procedural detail. The process of program refinement is analogues to the process of refinement and partitioning that is used during requirements analysis. Abstraction and refinement are complementary concepts. The major difference is that - in the abstraction low-level details are suppressed. Refinement helps the designer to elaborate low-levels details. Modular Design Modular design reduces complexity and helps in easier implementation. The parallel development of different parts of the system is possible due to modular design. What is the benefit of modular design? Changes made during testing and maintenance becomes manageable and they do not affect other modules. Various quality parameters for effective modular design are 1) Functional independance 2) Cohesion 3) Coupling. Functional Independence The functional independence can be achieved be developing the functional modules with single-minded approach. By using functional independence functions may be compartmentalized and interfaces are simplified. Various types of coupling are : i) Data coupling - The data coupling is possible by parameter passing or data interaction. ii) Control coupling - The modules share related control data in control coupling. iii) Commom coupling - Content coupling occurs when one module makes use of data or control information maintained in another module. Fan-out Fan-out is a measure of the number of immediate subordinates to a moule. The fan-out should be within some limit in the design. If fan-out is very high then it indicates that a single module is controlling many other modules. Preferably limit fan-out to no more than seven.

86

Fan-in Fan-in indicates how many modules directly control a given module. Modules with fanin must have good cohesion. Each interfac to the module must have the same number and types of parameters. Factoring Factoring means separation of function into new modules. By applying factoring the size of module is reduced and thereby the complexity of the problem is reduced. This also provides duplication of functions in more than one module. The effective factoring brings simplification in the implementation of software design. DESIGN HEURISTICS The program structure can be manipulated according the design heuristics as shon below. 1.Evaluate the first iteration of the program structure to reduce the coupling and improve cohesion . The module independency can be achieved in the program structure by exploding or imploding the modules. Exploding the modules means obtaining two or more modules in the final stage and imploding the modules means combining the result of different modules. 2,Attempt to minimize the structure with high fan-out and strive for fan-in as depth increase . At the higher level of program structure the distribution of control should be made. Fan-out means number of immediate subordinates to the module. Fan-in means number of immediate ancestores the module have. 3.Keep scope of the effect of a module within the scope of control of that module. The decisions made in particular module a should not affect the module b which lies outside the scope of module a. 4.Evaluate the module interfaces to reduce complexity and redundancy and improve consistency. Mostly the cause of softwatr errors is module interfaces. The module interfaces should simply pass the information and should be consistent with the module. 5.Define module whose function is predicatable but avoid modules that are too restrictive. The module should be designed with simplified internal processing so that expected data can be produced as a result. The modules should not restrict the size of local data structure, options with control flow or modes of external interfaces. Being module too much restrictive causes large maintenance. 6.Strive for controlled entry modules by avoiding pathological connections. Software interfaces should be constrained and controlled so that it will become manageable. Pathological connection means many references or branches into the middle of a module. Design Model The design model is represented as pyramid. The pyramid is a stable object. Representing design model in this way means that the software design should be stable. The design model has braod foundation of data design, stable mid-region with architectural and interface design and the sharp point to for component level design. Advantages of horizontal partition 1.These are easy to test, maintain and extend. 2.They have fewer side effects in change propagation or error propagation Disadvantages of horizontal partition:

87

More data has to be passed across module interfaces which complicates the overall control of program flow. Vertical partitioning: Vertical partitioning, suggests the control and work should be distributed top-down in program structure. In vertical partitioning Define separate branches of the module hierarchy for each major function. Use control modules to co-ordinate communication between functions. Advantages of vertical partition 1.These are easy to maintain the changes. 2. They reduce the change impact and error propagation.

DATA DESIGN
Data design is basically the model of data that is represented at the high level of abstraction. The data design is then progressively refined to create implementation specific representations. Various elements of data design are: Data object - The data objects are identified and relationship among various data objects can be represented using entity relationship diagrams or data dictionaries. Databases - Using software design model, the data models are translated into data structures and databases at the application level. Data warehouses - At the business level useful information is identified from various databases and the data warehouses are created. For extracting or navigating the useful business information stored in the huge data warehouse then data mining techniques are applied. ARCHITECTURAL DESIGN: Software architecture q The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design. q The output of this design process is a description of the software architecture. Architectural design q An early stage of the system design process. q Represents the link between specification and design processes. q Often carried out in parallel with some specification activities. q It involves identifying major system components and their communications. Architecture and system characteristics q Performance Localise critical operations and minimise communications. Use large rather than finegrain components. q Security Use a layered architecture with critical assets in the inner layers. q Safety Localise safety-critical features in a small number of sub-systems. q Availability Include redundant components and mechanisms for fault tolerance. q Maintainability Use fine-grain, replaceable components.

88

Architectural design decisions q Is there a generic application architecture that can be used? q How will the system be distributed? q What architectural styles are appropriate? q What approach will be used to structure the system? q How will the system be decomposed into modules? q What control strategy should be used? q How will the architectural design be evaluated? q How should the architecture be documented? Architectural styles q The architectural model of a system may conform to a generic architectural model or style. q An awareness of these styles can simplify the problem of defining system architectures. q However, most large systems are heterogeneous and do not follow a single architectural style. Architectural models Used to document an architectural design. Static structural model that shows the major system components. Dynamic process model that shows the process structure of the system. Interface model that defines sub-system interfaces. Relationships model such as a data-flow model that shows sub-system relationships. Distribution model that shows how sub-systems are distributed across computers. Modular decomposition q Another structural level where sub-systems are decomposed into modules. q Two modular decomposition models covered An object model where the system is decomposed into interacting object; A pipeline or data-flow model where the system is decomposed into functional modules which transform inputs to outputs. q If possible, decisions about concurrency should be delayed until modules are implemented. Object models q Structure the system into a set of loosely coupled objects with well-defined interfaces. q Object-oriented decomposition is concerned with identifying object classes, their attributes and operations. q When implemented, objects are created from these classes and some control model used to coordinate object operations. Invoice Processing system

Pipeline model advantages 89

Supports transformation reuse. Intuitive organisation for stakeholder communication. Easy to add new transformations. Relatively simple to implement as either a concurrent or sequential system. However, requires a common format for data transfer along the pipeline and difficult to support event-based interaction.

User interface design The user interface User interfaces should be designed to match the skills, experience and expectations of its anticipated users. System users often judge a system by its interface rather than its functionality. A poorly designed interface can cause a user to make catastrophic errors. Poor user interface design is the reason why so many software systems are never used. User interface Design Principle:

Design principles q User familiarity The interface should be based on user-oriented terms and concepts rather than computer concepts. For example, an office system should use concepts such as letters, documents, folders etc. rather than directories, file identifiers, etc. q Consistency The system should display an appropriate level of consistency. Commands and menus should have the same format, command punctuation should be similar, etc. q Minimal surprise If a command operates in a known way, the user should be able to predict the operation of comparable commands Recoverability The system should provide some resilience to user errors and allow the user to recover from errors. This might include an undo facility, confirmation of destructive actions, 'soft' deletes, etc. User guidance Some user guidance such as help systems, on-line manuals, etc. should be supplied User diversity

90

Interaction facilities for different types of user should be supported. For example, some users have seeing difficulties and so larger text should be available

REAL-TIME SOFTWARE DESIGN

Real-time systems Systems which monitor and control their environment. Inevitably associated with hardware devices Sensors: Collect data from the system environment; Actuators: Change (in some way) the system's environment; Time is critical. Real-time systems must respond within specified times. Definition: A real-time system is a software system where the correct functioning of the system depends on the results produced by the system and the time at which these results are produced. A soft real-time system is a system whose operation is degraded if results are not produced according to the specified timing requirements. A hard real-time system is a system whose operation is incorrect if results are not produced according to the timing specification. Stimulus/Response Systems: Given a stimulus, the system must produce a response within a specified time. Periodic stimuli: Stimuli which occur at predictable time intervals For example, a temperature sensor may be polled 10 times per second. Aperiodic stimuli: Stimuli which occur at unpredictable times For example, a system power failure may trigger an interrupt which must be processed by the system Architectural considerations: Because of the need to respond to timing demands made by different stimuli/responses, the system architecture must allow for fast switching between stimulus handlers. Timing demands of different stimuli are different so a simple sequential loop is not usually adequate. Real-time systems are therefore usually designed as cooperating processes with a real-time executive controlling these processes. A real-time system model
S ns r e o S ns r e o S ns r e o S ns r e o S ns r e o S ns r e o

Re la tim e c ntr o s s m o l y te

A tua to c r

A tua to c r

A tua to c r

A tua to c r

91

Sensor/actuator processes
Sensor Actua tor

Stimulus Sensor contr ol Data processor

Response Actua tor contr l o

System elements Sensor control processes Collect information from sensors. May buffer information collected in response to a sensor stimulus. Data processor Carries out processing of collected information and computes the system response. Actuator control processes Generates control signals for the actuators. Real-time programming Hard-real time systems may have to programmed in assembly language to ensure that deadlines are met. Languages such as C allow efficient programs to be written but do not have constructs to support concurrency or shared resource management. Java as a real-time language Java supports lightweight concurrency (threads and synchronized methods) and can be used for some soft real-time systems. Java 2.0 is not suitable for hard RT programming but real-time versions of Java are now available that address problems such as Not possible to specify thread execution time; Different timing in different virtual machines; Uncontrollable garbage collection; Not possible to discover queue sizes for shared resources; Not possible to access system hardware; Not possible to do space or timing analysis SYSTEM DESIGN Design both the hardware and the software associated with system. Partition functions to either hardware or software. Design decisions should be made on the basis on non-functional system requirements. Hardware delivers better performance but potentially longer development and less scope for change. R-T systems design process Identify the stimuli to be processed and the required responses to these stimuli. For each stimulus and response, identify the timing constraints. Aggregate the stimulus and response processing into concurrent processes. A process may be associated with each class of stimulus and response.

92

 Design algorithms to process each class of stimulus and response. These must meet the given timing requirements. Design a scheduling system which will ensure that processes are started in time to meet their deadlines. Integrate using a real-time operating system. Timing constraints: May require extensive simulation and experiment to ensure that these are met by the system. May mean that certain design strategies such as object-oriented design cannot be used because of the additional overhead involved. May mean that low-level programming language features have to be used for performance reasons. Real-time system modelling: The effect of a stimulus in a real-time system may trigger a transition from one state to another. Finite state machines can be used for modelling real-time systems. However, FSM models lack structure. Even simple systems can have a complex model. The UML includes notations for defining state machine models Petrol pump state model
T eout im Card inser ed t into reader

Reading do: get C C details Card rem oved

Initialising do: initialise display Hose out of holster Card OK Ready Nozzle trigger on Delivering do: deliver fuel update display

Waiting do: display welcom e Validating do: validate credit card

T eout im

Invalid card

Nozzle trigger off Nozzle trigger on

Resetting do: display C C error

Stopped

Paym ent ack.

Paying do: debit CC account Hose in holster

Real-time operating systems(RTOS) Real-time operating systems are specialised operating systems which manage the processes in the RTS. Responsible for process management and resource (processor and memory) allocation.

93

 May be based on a standard kernel which is used unchanged or modified for a particular application. Do not normally include facilities such as file management. Operating system components Real-time clock Provides information for process scheduling. Interrupt handler Manages aperiodic requests for service. Scheduler Chooses the next process to be run. Resource manager Allocates memory and processor resources. Dispatcher Starts process execution. Non-stop system components Configuration manager Responsible for the dynamic reconfiguration of the system software and hardware. Hardware modules may be replaced and software upgraded without stopping the systems. Fault manager Responsible for detecting software and hardware faults and taking appropriate actions (e.g. switching to backup disks) to ensure that the system continues in operation Real-time OS components
Schedulin g inf rm a o tion

Real-time clock

Sch edu ler

In terr upt han dler

Process resource requ ir ents em

Processes a ting wai resources

Resour ce m ana er g Ready processes Rel eased resources

Availa e bl resou rce list

Ready li st

Despatcher

Processor list

Executin g pr ocess

Process priority The processing of some types of stimuli must sometimes take priority. Interrupt level priority. Highest priority which is allocated to processes requiring a very fast response. Clock level priority. Allocated to periodic processes. Within these, further levels of priority may be assigned. Interrupt servicing Control is transferred automatically to a pre-determined memory location.

94

 This location contains an instruction to jump to an interrupt service routine. Further interrupts are disabled, the interrupt serviced and control returned to the interrupted process. Interrupt service routines must be short, simple and fast. Periodic process servicing In most real-time systems, there will be several classes of periodic process, each with different periods (the time between executions), execution times and deadlines (the time by which processing must be completed). The real-time clock ticks periodically and each tick causes an interrupt which schedules the process manager for periodic processes. The process manager selects a process which is ready for execution. Process management Concerned with managing the set of concurrent processes. Periodic processes are executed at pre-specified time intervals. The RTOS uses the real-time clock to determine when to execute a process taking into account: Process period - time between executions. Process deadline - the time by which processing must be complete RTE(Real Time Execution Process) process management
Scheduler Choose pr ocess for execution R esource manager Alloca m em ory te and pr cessor o Despatcher Start e ecution on an x availa pr ble ocessor

Process switching The scheduler chooses the next process to be executed by the processor. This depends on a scheduling strategy which may take the process priority into account. The resource manager allocates memory and a processor for the process to be executed. The dispatcher takes the process from ready list, loads it onto a processor and starts execution. Scheduling strategies Non pre-emptive scheduling Once a process has been scheduled for execution, it runs to completion or until it is blocked for some reason (e.g. waiting for I/O). Pre-emptive scheduling The execution of an executing processes may be stopped if a higher priority process requires service. Scheduling algorithms Round-robin; Rate monotonic; Shortest deadline first. Monitoring and control systems 95

Important class of real-time systems. Continuously check sensors and take actions depending on sensor values. Monitoring systems examine sensors and report their results. Control systems take sensor values and control hardware actuators.

Generic architecture
Testing process S1 P (S1) Mon itoring processes S2 P (S2) Control processes P (A1) A3 P (A2) A2 P (A1) A1

S3

P (S1)

P ( A4) Control panel processes

A4

Burglar alarm system A system is required to monitor sensors on doors and windows to detect the presence of intruders in a building. When a sensor indicates a break-in, the system switches on lights around the area and calls police automatically. The system should include provision for operation without a mains power supply. Sensors o Movement detectors, window sensors, door sensors; o 50 window sensors, 30 door sensors and 200 movement detectors; o Voltage drop sensor. Actions o When an intruder is detected, police are called automatically; o Lights are switched on in rooms with active sensors; o An audible alarm is switched on; The R-T system design process Identify stimuli and associated responses. Define the timing constraints associated with each stimulus and response. Allocate system functions to concurrent processes. Design algorithms for stimulus processing and response generation. Design a scheduling system which ensures that processes will always be scheduled to meet their deadlines. Stimuli to be processed Power failure Generated aperiodically by a circuit monitor. When received, the system must switch to backup power within 50 ms. Intruder alarm

96

Stimulus generated by system sensors. Response is to call the police, switch on building lights and the Power failure Generated aperiodically by a circuit monitor. When received, the system must switch to backup power within 50 ms. Intruder alarm Stimulus generated by system sensors. Response is to call the police, switch on building lights and the audible alarm. audible alarm.

Burglar alarm system processes

400 Hz

60 Hz

100 Hz

Mov ement detector process Detector sta tus 560 Hz

Door sensor process Sensor sta tus

W indo sensor w process Sensor sta tus Alar system m

Building monitor process Power failur e interrupt Building monitor Room num ber

Comm unicaion t process

Power s witch process

Alar system m process Room num ber Alarm system

Alert messa ge

Alarm system

Alarm system

Room number Audib alar le m process Lighting contr ol process V oice synthesisr e process

Building_monitor process 1 class BuildingMonitor extends Thread { BuildingSensor win, door, move ; Siren siren = new Siren () ; Lights lights = new Lights () ; Synthesizer synthesizer = new Synthesizer () ; DoorSensors doors = new DoorSensors (30) ; WindowSensors windows = new WindowSensors (50) ; MovementSensors movements = new MovementSensors (200) ; PowerMonitor pm = new PowerMonitor () ; BuildingMonitor() { // initialise all the sensors and start the processes siren.start () ; lights.start () ; synthesizer.start () ; windows.start () ; doors.start () ; movements.start () ; pm.start () ; }

97

Building monitor process 2 public void run () { int room = 0 ; while (true) { // poll the movement sensors at least twice per second (400 Hz) move = movements.getVal () ; // poll the window sensors at least twice/second (100 Hz) win = windows.getVal () ; // poll the door sensors at least twice per second (60 Hz) door = doors.getVal () ; if (move.sensorVal == 1 | door.sensorVal == 1 | win.sensorVal == 1) { // a sensor has indicated an intruder if (move.sensorVal == 1) room = move.room ; if (door.sensorVal == 1) room = door.room if (win.sensorVal == 1 ) room = win.room ; lights.on (room) ; siren.on () ; synthesizer.on (room) ; break ; } Building_monitor process 3 lights.shutdown () ; siren.shutdown () ; synthesizer.shutdown () ; windows.shutdown () ; doors.shutdown () ; movements.shutdown () ; } // run } //BuildingMonitor Control systems A burglar alarm system is primarily a monitoring system. It collects data from sensors but no real-time actuator control. Control systems are similar but, in response to sensor values, the system sends control signals to actuators. An example of a monitoring and control system is a system that monitors temperature and switches heaters on and off. A temperature control system
500 Hz

Sen sor process

500 Hz

Sensor v ues al

Thermosta t process Switch command R oom num ber Thermosta pr t ocess

500 Hz

Heater contr l o process

Furnace control process

DATA ACQUISITION SYSTEMS Collect data from sensors for subsequent processing and analysis. 98

Data collection processes and processing processes may have different periods and deadlines. Data collection may be faster than processing e.g. collecting information about an explosion. Circular or ring buffers are a mechanism for smoothing speed differences.

The generic Architecture of data acquicition:

S nso (e e rs ach da ta flo is a senso value w r ) s1 s2 s3 S nsor e pro ss ce S enso r identifie and r value S nso e r ide ntifier and value S enso da ta r Pro ss ce buffer data

Displa y

s4 s5 s6 S nsor e pro ss ce

S enso r identifie and r v alue

S nso e r ide ntifier and v alue S nsor data e Pro cess buf fer data

In data acquisition systems,the sensor may be generating data quickly and the key problem is to ensure that a sensor is allocated before sensor value change. The essenitial features of this architecture is each group of sensors has three processes associated with it and convert analogue data to digital values if necessary a buffer process and a process that consumes the data carried out further processing. Two groups sensors s1-s3 and s4-s6 on the right side ,a further procee that diplsys the sensor data. Neutron flux data acquisition:
Neutron flux sensors Sensor identifier and flux alue v A-D conver tor Flux da ta buffer Processed flux le v el Flux processing Operator display

A system collects data from a set of sensors monitoring the neutron flux from a nuclear reactor. Each sensor has a process that converts the analog input flux level into a digita, signal.It passes this flux level ,with sensor identifies to the sensor data buffer the data processing takes the data from this buffer,processes it and pass it to display process for output on an operator display

A ring buffer
Producer process

Consum er process

Mutual exclusion

99

Producer processes collect data and add it to the buffer. Consumer processes take data from the buffer and make elements available. Producer and consumer processes must be mutually excluded from accessing the same element. The buffer must stop producer processes adding information to a full buffer and consumer processes trying to take information from an empty buffer.

100