Student Project Thesis How to specify a Simulation Configuration
1 Student Project Thesis How to specify a Simulation Configuration with the help of Modern Requirement Analysis in a Re-Engineering Process by Carsten Schmitt 28th Feb. 2005 2 ABSTRACT The topic of this student research project is specification and design of an abstract configuration mechanism for the ComNets Simulation Framework which is part of the WINNER-Project. The project aim is to be fulfilled by using modern software development methodologies like the process of requirement management and UML. Possible solutions will be discussed and compared. KURZFASSUNG Das Thema dieser Studienarbeit ist die Spezifikation und das Design eines abstrakten Konfigurationsmechanismus für das ComNets Simulation Framework. Dieses Projekt ist ein Teilprojekt des WINNER-Projekts. Das Ziel dieser Studienarbeit soll unter Verwendung moderner Methoden der Softwareentwicklung wie der UML und dem verwalten von Anforderungen erreicht werden. Mögliche Lösungen werden diskutiert und miteinander verglichen. CONTENTS Abstract 3 Kurzfassung 4 1 Introduction 1.1 Introduction into Methodologies . . . . . . . . . . . . . . . . . . . . 1.1.1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3 The Rational Unified Process - A Reference Process Model 1.2 Introduction into the Analysis Object . . . . . . . . . . . . . . . . 1.2.1 Short Description of ComNets . . . . . . . . . . . . . . . . . 1.2.2 The ComNets Simulation Framework . . . . . . . . . . . . . 1.2.3 Problems which Motivate this Student Project Thesis . . . 1.2.4 Aim of this Student Project Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 . 7 . 7 . 7 . 8 . 9 . 9 . 9 . 10 . 10 2 Requirement Management 2.1 Requirement Management Overview . . . . . . . . . . . . . . . . . . . 2.1.1 The Problem Domain . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 The Solution Domain . . . . . . . . . . . . . . . . . . . . . . . 2.1.2.1 Feature of the System . . . . . . . . . . . . . . . . . . 2.1.2.2 Software Requirements . . . . . . . . . . . . . . . . . 2.1.3 Justification of the Requirement Management Approach . . . . 2.2 Problem Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 The 5 Steps of Problem Analysis . . . . . . . . . . . . . . . . . Gain Agreement on the Problem Definition . . . . . . . Identifying the Root Causes . . . . . . . . . . . . . . . . Identify the Stakeholders and the Users . . . . . . . . . . Define the Solution System Boundary . . . . . . . . . . . Identify the Constraints to be Imposed on the Solution . 2.2.1.1 User Interview . . . . . . . . . . . . . . . . . . . . . . 2.2.1.2 Results of the Interview . . . . . . . . . . . . . . . . . User needs . . . . . . . . . . . . . . . . . . . . . . . . . . Developer needs . . . . . . . . . . . . . . . . . . . . . . . 2.3 Solution Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1.1 From Stakeholder Needs to Features . . . . . . . . . . User Features . . . . . . . . . . . . . . . . . . . . . . . . Developer Features . . . . . . . . . . . . . . . . . . . . . 2.3.1.2 Feature Prioritization . . . . . . . . . . . . . . . . . . 2.3.2 Software Requirements . . . . . . . . . . . . . . . . . . . . . . . 2.3.2.1 A Further Characterization of Software Requirements 2.3.2.2 Functional Software Requirements and Use Cases . . . Definition of the Term Use Case . . . . . . . . . . . . . . Purpose of Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 13 14 14 14 14 14 16 16 16 16 18 19 20 20 21 21 21 22 22 22 23 23 23 24 25 25 26 27 6 Contents Use Cases for the ComNets Simulation Framework ration System . . . . . . . . . . . . . . 2.3.2.3 Non-Functional Software Requirements . . . . . 2.3.2.4 Design Constraints . . . . . . . . . . . . . . . . . Configu. . . . . . 28 . . . . . . 32 . . . . . . 32 3 Designing the Right System 3.1 Analysis of the actual Configuration Mechanism . . . . . . . . . . . . . . . . 3.2 Making a New Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Introduction to Collaborations . . . . . . . . . . . . . . . . . . . . . 3.2.1.1 Structural and Behavioral Aspects of Collaborations . . . . 3.2.1.2 Using Collaborations to Realize Sets of Individual Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Usage of Collaborations on the Configuration Problem . . . . . . . . 33 33 33 33 33 4 Presentation of a Potential Implementation 4.1 XML as a Possible Implementation . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Introduction to the Extensible Markup Language (XML) . . . . . . . 4.1.1.1 A Word on XML Schemas (XSD) . . . . . . . . . . . . . . 4.1.2 Conceptual Mapping from UML to XML . . . . . . . . . . . . . . . . 4.1.3 Type Based Example Configuration for ComNets Simulation Framework in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.4 Implementation of a Prototype . . . . . . . . . . . . . . . . . . . . . 4.1.5 Review and Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 39 39 39 39 41 List of Figures 47 List of Tables 49 Glossary 51 List of Abbreviations 53 Bibliography 55 34 34 41 44 45 CHAPTER 1 Introduction 1.1 1.1.1 Introduction into Methodologies Abstract A big part of the ComNets activities in the WINNER-Project is to build up a simulation environment capable to fulfill a lot of very different simulation needs in the WINNERProject. One essential constraint is to reuse already existing software modules. Because every module has its own history and developing methodology a common abstraction level for describing these modules is missing. This must be realized in a re-engineering process. This student project thesis is concerned with the aspect of configuration simulations. The necessary steps to achieve an abstract configuration mechanism will be motivated an related to modern methodologies. 1.1.2 Preliminaries The development of complex software involves a lot of persons with quite different expertise and interests. Models are the means to represent what should be developed. In order to prevent misunderstandings the representation form of models must be unique for every stake holders in a project. Process models like the RUP (Rational Unified Process) define phases of the development process and related abstraction levels a representation forms. All phases cover the whole path from the problem specification to the software solution. The application of such a process model ensures that the system under development has valid representations and allows checks that the correct system will correctly developed. Re-engineering is the inverse development process. It starts from existing software (code) and aims to acquire the knowledge about the existing software. This should help to make correct decisions for the ongoing in a project. Therefore the knowledge must be represented uniquely and correctly for every stake holder. The UML (Unified Modeling Language) has the potential to support these aims. However, it incorporates object oriented thinking. Like a poet, who uses well chosen terms to express the spirit of a situation, an UMLModeler differentiates situations with the help of classes and relations between classes to express the essential ideas or concepts of the aspect actually to be modeled. The modeler of system visions is confronted with the fundamental problem that new semantics must be associated to terms preloaded with legacy semantics. For example, the term simulation configuration has a meaning which is well defined with respect to every module. In the context of the extended simulation environment this term has a new meaning. In order to express the differences one needs terms which specify the difference. But these terms itself are loaded with legacy meaning. Because this is not really a simple problem it is as specification dilemma characterized. 8 1. Introduction 1.1.3 The Rational Unified Process - A Reference Process Model According to [1] processes are used because people are uncertain. They are uncertain that • • • • • • the project will produce the wrong result. the project will produce a result of inferior quality. the project will be late. they will have to work 80 hour weeks to meet deadlines. they will have to break commitments. they will not be having a good working atmosphere. These fears motivate to describe a process which constrains the activities and demands certain outputs without destroying creativity. People draw these constraints and outputs from past experience, choosing things that appear to work well in previous projects. The hope is that these processes will work again and again, and take their uncertainness away. Over the years, they have come to recognize that many successful processes, though they differ in their particulars, seem to have a common shape. It provides a framework within which to build a process that may put their fears to rest. That framework is called the Rational Unified Process (RUP). Figure 1.1 visualizes the different phases of the RUP. Figure 1.1: The Phases and Iteration of RUP Figure 1.2 classifies the Rational Unified Process into three different levels of abstraction. The highest level of abstraction is the Meta Meta Layer which contains Theory and Standards. This layer provides different application views which depend on the current situation. 1.2. Introduction into the Analysis Object 9 Figure 1.2: The Phases and Iteration of RUP with its superior meta layers The second layer - the Meta Layer - is the Modelling Layer. This layer contains the different methods which might be used. This depends on the current application view which has been chosen in the upper layer. For example the Use Case Approach might be used in a functional view. The lowest level of abstraction is the Object Layer. This layer is divided into several sub layers which describe the different actions inside of the Rational Unified Process, itself. 1.2 1.2.1 Introduction into the Analysis Object Short Description of ComNets ComNets, a chair of Aachen University, is one of the largest university departments in Germany working on Mobile Communications. Research projects are mainly funded by third parties like national and European boards and communication industries. The main field of research is traffic performance analysis which consists of event driven stochastic simulation based on emulated protocol stacks and traffic theory. 1.2.2 The ComNets Simulation Framework The application of the ComNets Simulation Framework is an embedded process in traffic performance analysis of mobile radio networks. This process is realized by application software, tools and documentation. For example a scenario might consist of four symmetrically placed tower blocks. Each of these tower blocks might hold a base station. Moreover, each mobile station in the system owns a movement model which describes the movement behaviour (e.g. placing a call in a driving car). In addition each station owns a load model which describes the network traffic (e.g. ftp and http load). Beside, the protocol stack of 10 1. Introduction each station can be assembled individually. Figure 1.3: Closed Loop of Finding the Ideal Solution Figure 1.3 visualizes the closed loop of finding the ideal solution to a given problem. This is iterative process is a common approach - simulate, spectate and modify. 1.2.3 Problems which Motivate this Student Project Thesis Complex systems often need complex configurations. The simulation framework consists of more than one complex subsystems. Every subsystem has its own configuration file with a size up to 400 kByte, and there is no superior configuration file which contains global settings like the number of mobile stations to be simulated. Additionally, these huge configuration files depend on each other. This often leads to inconsistent configuration files which produces unforseenable program errors or results. Another problem is the different implementation of object containers in the different modules. This produced a mapping workaround which might be another source of errors. Moreover, it is quite copious to perform simulation series. Up to now it is necessary to make twenty copies of all configuration files to perform twenty simulations. Then the parameters inside the huge configuration files have to be modified manually. All these problems are surely controllable by developers itself. But the project will go open source in near future and then these circumstances become unacceptable. These problems motivate the this student project thesis. 1.2.4 Aim of this Student Project Thesis One core point of this student project thesis is to determine the requirements of a possible solution for the configuration problem. Another point is to propose possible solutions based on the resulting requirements. 1.2. Introduction into the Analysis Object 11 In this student thesis the used methods are shortly described. Then the described methods are adopted to the specific problem. The reader of this document should learn something about the method itself and then see the concrete usage of the method on the problem. The used process is described in the book [2]. 12 1. Introduction CHAPTER 2 Requirement Management 2.1 Requirement Management Overview A general problem is the communication between a customer and a project team. These two parties live in two different worlds and speak two different languages. This makes it quite hard for the project team to build the system which does what his buyer wants it to do. This is where Requirement Management comes into the play. According to [2] Requirement Management is a systematic approach to eliciting, organizing, and documenting the requirements of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system. This definition sounds as if this process solves all problems. In the following the different steps of this process will be explained and then used to solve the Configuration Problem of the ComNets Simulation Framework. The following section gives a short overview about the Requirement Management Process Figure 2.1: Overview of the problem domain and the solution domain. 14 2. Requirement Management 2.1.1 The Problem Domain The problem domain is the space a customer normally moves in. He has a problem and wants it to be solved. The problem is that the customer is often unable to decide between a problem and a possible solution. So the project team needs some time to understand the problem behind the problem and to identify the root cause. Just after the problem is understood,the project team is able to specify the customer’s real needs - the stakeholder needs. This is not the time to spend much time on thinking about how to solve the problems or how to meet the needs! This will be part of the next section - the solution domain. 2.1.2 The Solution Domain Defining a solution for the user’s problem is the focus of this section. It is divided into two parts: Defining the features of the system and finding the adequate software requirements. 2.1.2.1 Feature of the System This section proposes solutions the the specified problems on a high level of abstraction. These features are simple descriptions in the user’s language. Simple features might be: • The car will have two independent breaking systems • The program will allow automatic backups • An automatic step-and-repeat weld cycle is required To increase understandability and lower ambiguity it is important to provide an exact definition of the feature term: A feature is a service provided by the system that fulfills one or more stakeholder needs. Graphically, the feature is represented as a base for the previous needs pyramid in figure 2.1. 2.1.2.2 Software Requirements When all features are specified the Software Requirements can be specified. If the project team builds a system that conforms to those requirements one can be sure that the system will deliver the features the customer requested. There are an amount of methods which might be used to come from the given features to the software requirements. One of those methods is the Use Case Approach which will be explained later on in this document. 2.1.3 Justification of the Requirement Management Approach According to [2] requirements errors cause high costs. The following figure comes from studies performed at companies including GTE, TRW, IBM and HP. Figure 2.2 illustrates, that if a unit cost of one is assigned to the effort required to detect and repair an error during the coding stage, then the cost to detect and repair and error during the requirements stage is between five to ten times less. Furthermore, the cost to detect and repair an error during the maintenance stage is twenty times more. The factors in figure 2.2 reach from 0.1 to 20. The factor one of the coding level expresses the effort of repairing requirements errors to the programmer. This is because nearly every developer has a rough idea of coding and its effort. For example the effort of fixing a design error which was realized during the Acceptance Test Phase is multiplied by 10 (0.5 multiplied by 10 is 5). The ComNets Simulation Framework is currently located between the Coding- and Unit Test Phase. 2.1. Requirement Management Overview To sum up and bring it to the point: 1. Requirements errors are likely to be the most common class of error. 2. Requirements errors are likely to be the most expensive errors to fix. Figure 2.2: Relative cost to repair a defect at different life cycle phases. 15 16 2. Requirement Management 2.2 2.2.1 Problem Domain The 5 Steps of Problem Analysis According to [2] problem analysis can be defined as the process of understanding real-world problems and user needs and proposing solutions to meet those needs. Moreover a definition of the problem term is necessary: A problem can be defined as the difference between things as perceived and things as desired. The goal of problem analysis is to gain a better understanding of the problem being solved before development begins. Reference [2] propose a 5 step approach: 1. 2. 3. 4. 5. Gain agreement on the problem definition. Understand the root causes - the problem behind the problem. Identify the stakeholders and the users. Define the solution system boundary. Identify the constraints to be imposed on the solution. According to this method problems will be written down in tables like 2.1 to gain agreement on the problem. Table 2.1: Problem Statement Format Element The problem of... Affects... And results in... Benefits of a solution... Description Describe the problem Identify stakeholders affected by the problem Describe the impact of this problem on stakeholders and business activities Indicate the proposed solution and list a few key benefits Gain Agreement on the Problem Definition To get a first idea of the fundamental problems and possible solutions, a first conversation with the product manager took place. This meeting highlighted the following problems: • The problem of redundancy when configuring a simulation • The problem of huge configuration files • The problem of entity-mapping between different layers The identified problems will be explained in the following: Identifying the Root Causes Now is the time to identify the root causes. This means to identify the problem behind the problem (if any). To do so the method in [2] is used - Fishbone Diagrams: This lead to the following conclusion: The two main problems of redundancy and huge configuration files exist because no smart configuration mechanism exists. This is illustrated by figure 2.3 and figure 2.4. The reason lays in the rather low priority of such a 2.2. Problem Domain 17 Table 2.2: Problem 1: Specification of configuration redundancy problem Element The problem of... Affects... And results in... Benefits of a solution... Description Redundancy when configuring a simulation. User, Developer Up to now there is a configuration file for every subsystem. To perform a simulation with more than one subsystem the different configurations must match in some points. For example the count of simulated mobiles must be equal in every configuration file. This is a big source for wrong configurations which are unacceptable for an average user. This makes high level expertise in configuration necessary. Ignoring this problem would make the whole project fail. There might be a hierarchy in the configuration. For example some files might contain the scenario information and other files just contain the technical parameters which are necessary for the component itself. Table 2.3: Problem 2: The problem of huge configuration files Element The problem of... Affects... And results in... Benefits of a solution... Description The configuration files are huge and complex. User, Developer An average user would hardly get an overview about what to configure and what not. This makes high level expertise in configuration necessary. Ignoring this problem might cause the whole project to fail. This problem might be exterminate by introducing a type concept which provides different hierarchies of configuration. Moreover it makes sense to preallocate parameters with default values. So it would be possible to perform a simulation within 10-20 lines of configuration code. mechanism. Another root cause for the huge configuration files is the high complexity of the specific modules. This complexity will rather increase than decrease what is another argument for a new configuration mechanism. A new configuration mechanism would solve the problems of redundancy and huge configuration files because of a possible separation between global and local parameters. Anyway, the integration of this new solution into the old system would take some time. Figure 2.5 shows possible root causes for the existing entity-mapping problem. Every developer created his own mechanism when it was needed. This might happened because of a lack of project management. Resolving upon an agreement would have avoided these problems. This problem might be solved with a new configuration mechanism, too. Primary the previous argumentation justifies the development of a new configuration mechanism. 18 2. Requirement Management Table 2.4: Problem 3: The problem of entity-address-mapping between different layers Element The problem of... Affects... And results in... Benefits of a solution... Description Entity-address-mapping between different layers exists because every developer decided to use different IDs and allocation orders for the entities in his subsystem. Developer Dirty workarounds and bugs are probable. There might be an agreement on the ID form and the allocation orders. This problem might be solved by solving the redundancy problem (Problem 2). Figure 2.3: Fishbone diagram 1 demonstrates the root causes of the redundancy problem Identify the Stakeholders and the Users According to [2] a stakeholder is anyone who could be materially affected by the implementation of a new system or application. Understanding the needs of the users and other stakeholders is a key factor in developing an effective solution. Complex problems typically involve a diverse group of stakeholders. An understanding of who these stakeholders are can be obtained by asking the following question: Figure 2.4: Fishbone diagram 2 visualizes the problem of huge configuration files 2.2. Problem Domain 19 Figure 2.5: Fishbone diagram 3 illustrates why the entity-mapping problem exists • • • • • Who are the users of the system? Who is the customer (economic buyer) for the system? Who else will be affected by the outputs the system produces? Who will evaluate and approve the system when it is delivered and deployed? Are there any other internal or external users of the system whose needs must be addressed? • Who will maintain the new system? • Is there anyone else who cares? Define the Solution System Boundary Now is the time to define the solution system boundary. To do so it is necessary to answer at least the following questions: • • • • • • Who will supply, use, or remove information from the system? Who will operate the system? Where will the system be used? Where does the system get its information? Who will perform any system maintenance? What other external systems will interact with the system? Figure 2.6 shows the boundaries from system perspective. The black line distinguishes the system from its environment. It also illustrates, that a part from the New Simulation Framework Configuration System is included into the existing ComNets Simulation Framework. Moreover there are two different stakeholder types: User and Developer. Figure 2.6: System perspective 20 2. Requirement Management Identify the Constraints to be Imposed on the Solution According to [2] a constraint is a restriction on the degree of freedom a product team has in providing a solution. The only constraints which exist regarding to this project are: • The use of C++ to provide a solution • No commercial software can be part of the result 2.2.1.1 User Interview The interview method will help to gather information from different stakeholders. Based on the interviewing results the stakeholder needs will be identified. Reference [2] provides a generic interview template which was modified to its purpose: 1. Part 1: Establish User Profile • What are your key responsibilities ? • Where in the whole framework is your subsystem is located ? 2. Part 2: Assessing the Problem • What are the basic problems according to the configuration ? – Why does this problem exist ? – How do you solve it now ? – How would you like to solve it ? 3. Part 3: Understanding the User Profile • Where / to which subsystems are the basic dependencies ? • Who are the users of the module ? • What are your expectations for usability of this module ? 4. Part 4: Recap for Understanding • List customer-described problems in your own words 5. Part 5: Assessing Your Solution • What if you could: – Perform a simulation within 10-20 lines of code ? – Simply change default settings ? – Extend the configuration model ? 6. Part 6: Other requirements • Are there any standards that must be supported ? • Can you think of any other requirement we should think about ? 7. Part 7: Wrap-up • Would you be willing to participate in a requirements review ? 8. Part 8: The Analyst’s Summary • The three highest-priority needs/problems are: – 1. 2.2. Problem Domain 21 – 2. – 3. 2.2.1.2 Results of the Interview The interview provides a list with stakeholder needs which is listed below. The different stakeholder needs are assigned to the different stakeholders: User needs • Simple, self-explanatory and intuitive configuration concept • Simple performing of simulation series • Simulation parameters and simulation results must be allocatable Developer needs • Simple integration into existing system • Simple extensibility of the whole configuration mechanism when there are new parameters 22 2.3 2. Requirement Management Solution Domain In this section we have to define a solution for the users problem. This we call features a feature is a service provided by the system that fulfills one or more stakeholder needs. Features answer the question What to do in a solution - not How!) 2.3.1 Features Features are high-level expressions of desired system behaviour. Features can be in conflict with each other - this make a prioritization of features necessary. The previous definition of a feature ensures that these features can’t be to far removed from their needs. These features provide a useful and convenient way to describe the functionality of a new system without getting bogged down in too much detail. It is important to notice that features address the issue of what the customer thinks the system must do to address his needs thus how - while needs express exactly what the customer needs. Figure 2.7 visualizes the transformation form Needs to Feature. Figure 2.7: Needs and features are closely related 2.3.1.1 From Stakeholder Needs to Features Going back to the concrete configuration problem, the collected stakeholder needs will be traced to features. These features are listed below. Figure 2.8 visualizes this process. The matrix columns contain the different stakeholder needs while the rows hold the defined features. The arrows show which need is fulfilled by which features. This figure was generated using [4]. 2.3. Solution Domain 23 User Features • • • • • • Simple, redundancy-free administration of existing configuration Configuration must be human readable with a simple text editor Assign comments to parameters for documentation purpose Automation of the whole simulation process (to perform simulation series) Configuration files must support parameter variation Simulation parameters and results must be place together Developer Features • New mechanism is compatible to old INI-file format • New configuration mechanism implements old interface • No modification of the configuration mechanism is required when new parameters arise • Simple to extend configuration model when new parameters arise Figure 2.8: This is a screenshot from a traceability matrix in Rational RequisitePro 2.3.1.2 Feature Prioritization Figure 2.9 visualizes the used questionnaire for feature prioritization. It was given to several potential users and developers. The results of the survey is shown in figure 2.10. Diagram 2.10 shows, the three most wanted features. 1. Simple, redundancy-free administration of existing configuration 24 2. Requirement Management 2. Simple to extend configuration model when new parameters arise 3. No modification of the configuration mechanism itself is required when new parameters arise This leads to the conclusion that it is more important to create a configuration mechanism which allows simple and intuitive configuration than a mechanism which implements old interfaces or formats. The result of this survey justifies a new, clean approach which does not directly depend on the existing mechanism. Of course this approach would increase the integration work according to the ComNets Simulation Framework. Figure 2.9: This is a screenshot of the used questionnaire for the feature prioritization Figure 2.10: This figure shows the results of the feature survey 2.3.2 Software Requirements The software requirements become interesting when the feature set is established. Software requirements are the more specific requirements which are necessary to impose on the solution. 2.3. Solution Domain 2.3.2.1 25 A Further Characterization of Software Requirements To become a little more flexible, it is necessary to differ between software requirements. This will help to understand more about the system to be built. Figure 2.11 visualizes the different types. Figure 2.11: There are three different types of requirements 1. Functional software requirements Functional requirements express how the system behaves - its inputs, its outputs, and the functions it provides to its users. These requirements can usually be captured with use cases. 2. Nonfunctional software requirements The functional software requirements do not describe the system completely. There are still some system properties which have nothing to do with functionality itself. These requirements are called nonfunctional software requirements. Examples for nonfunctional software requirements are: • • • • Performance Supportability Reliability Usability 3. Design constraints Design constraints typically impose limits on the design of the system. According to [2] design constrains are restrictions on the design of a system, or the process by which a system is developed, that do not affect the external behaviour of the system but that must be fulfilled to meet technical, business, or contractual obligations. 2.3.2.2 Functional Software Requirements and Use Cases Use cases carry the majority of the requirements for the system. The development team, with user involvement, writes the use cases in a common standard format. These use cases 26 2. Requirement Management can be used for test case development later on. Definition of the Term Use Case Intuitive a use case is something that happens when a user uses a system. This definition is a bit imprecisely. According to [2] a use case is defined as an accumulation of sequences of actions a system performs that yields in an observable result of value to a particular actor. That does not mean more than use cases describe the interaction with a system. Figure 2.12 shows the common notation. Thus, a use case represents a sequence of actions describing a set of functions, an algorithmic procedure, or any other internal process that produces a result. The actions of an use case must be atomic - that means it is performed either entirely or not at all! A use case must be worth to an user. Therefore, ’the occupant pushes the light button’ is not a valid use case. But ’the occupant pushes the light button an the system turns on the light’ is a meaningful description of a use case. An use case must motivate to interact with the system. The system makes something for the actor. It exhibits the functionality described in the use case and takes its orders from the actor. The actors notation is displayed in figure 2.13. Figure 2.12: Use case Figure 2.13: Actor More information about defining and using use cases can be obtained at [5]. 2.3. Solution Domain 27 Purpose of Use Cases Use cases are just one way to express software requirements. Use cases express the upper features in much more detailed terms! This is the direct relationship between features and software requirements. Primary use cases are used to capture functional software requirements. That means that a big part of features might be mapped to functional software requirements. But there will still be some features left which have no representation on the requirement layer. These features will be mapped to non-functional software requirements (like usability, reliability and performance) or design constraints (that means restrictions on the design of a system). 28 2. Requirement Management Use Cases for the ComNets Simulation Framework Configuration System In this section the basic use cases for the ComNets Simulation Framework Configuration System are described. Table 2.5 describes a schema which is used to describe use cases in a textual form. Table 2.5: Use Case Schema Name: Description Actors: Basic Flow: Use Case Name Describe the use case List the actors • Atomic action 1 • Atomic action 2 • ... Alternative Flows: • Alternative 1 – First alternative - Atomic action 1 – First alternative - Atomic action 2 – ... • Alternative 2 – Second alternative - Atomic action 1 – Second alternative - Atomic action 2 – ... • ... Pre-conditions: • Pre-Condition 1 • Pre-Condition 2 • ... Post-conditions: • Post-Condition 1 • Post-Condition 2 • ... Figure 2.14 gives an overview about the identified use cases. Formulating each of these use cases in textual form would blast the scope of this student project thesis. Thus, just the more important use cases will be described later on. Short Description of the shown Use Cases 1. Add new parameter During development it is always necessary to add new parameters to the parameter space. This includes defining a type and limitations for the new parameter. This is 2.3. Solution Domain 29 Figure 2.14: The Use Cases from Actors Perspective typically done by a developer. 2. Remove existing parameter This use case describes the inverse operation to add new parameter. 3. Create new configuration Creating a new configuration is always necessary when an individual wants perform a simulation. The configuration basically describes the simulation scenario: • How many mobiles • Which protocol stacks • Traffic behaviour • Movement model of mobile stations • Used antennas This scenario will be designed by a user by creating the mentioned configuration. 4. Load configuration Loading a configuration is the first thing to do before getting and setting of parameter values is possible. For example the configuration could be a set of files which have to be translated into an internal memory representation. 5. Save configuration Saving writes the whole configuration back to a persistent medium. 6. Check configuration Before the configuration is usable it must be valid. This use case describes the steps which are necessary to check a configuration and what is to be done if something goes wrong. 7. Get parameter value Parameters can mainly be requested from the ComNets Simulation Framework. Depending on the realization these use cases are not necessary any longer. Table 2.6 30 2. Requirement Management provides a more detailed description of the use case of getting a parameter value from a loaded configuration. Figure 2.15 shows an UML activity diagram which describes the use case in detail to avoid misunderstandings. 8. Set parameter value This is similar to the Get Parameter Value use case. Table 2.6: Use Case - Get Parameter Value Name: Description Actors: Basic Flow: Get parameter value This use case describes the systems behaviour on getting parameter values from the loaded configuration. ComNets Simulation Framework • Get parameter identifier • Find parameter identifier in loaded configuration • Return the parameter value Alternative Flows: • Alternative 1 - User did not overwrite the parameter value – Get parameter identifier – Find parameter with identifier in the default configuration – Return the default value of this parameter • Alternative 2 - Parameter identifier does not exist – Get parameter identifier – Find parameter with identifier in the default configuration – Not found - report failure Pre-conditions: • Configuration must be loaded • Configuration syntax must be valid Post-conditions: • When reading a parameter-value correctly, the system returns into the state it was before because a reading operation does not take any effect on the state. • When an error occurred (e.g. parameter name not found) the system informs the user but returns into the state it was before to handle new parameter requests. 2.3. Solution Domain 31 Figure 2.15: The appropriate UML Activity Diagram to the Get Parameter Value Use Case 32 2. Requirement Management 2.3.2.3 Non-Functional Software Requirements The whole configuration mechanism must be simple to integrate because the ComNets Simulation Framework is a large project and configuring a system is surely not its main purpose. Moreover the configuration mechanism must be simple and intuitive to use by a average user. At this point it is time to define the non-functional software requirements in detail. Doing this for every defined non-functional feature would blast the scope of this student project thesis. So this is just done for the feature: The configuration mechanism must be simple and intuitive to use by a average user. Below is a list with software requirements which should met this highly requested feature. 1. Hierarchically meaningful grouping of information 2. Assign a default value to every attribute 3. A textual description can be bind to the configuration parts, directly 2.3.2.4 Design Constraints As described above there are still some features which could not mapped to functional software requirements: The whole project will go open source, soon. This excludes the use of commercial software in any way. Moreover the basic parts of the project are coded in C++. So it is obvious to write the configuration mechanism in C++, too. CHAPTER 3 Designing the Right System 3.1 Analysis of the actual Configuration Mechanism The actual configuration mechanism works with INI-files. These files provide a static hierarchy of three levels - filename, section parameter name. Every parameter can take exactly one parameter value. Figure 3.1 shows the conceptual coherences. A parameter value can be accessed by passing a filename, a section name and a parameter name. Such a static hierarchy is fairly enough for small and medium configurations but evidently it breaks down when the amount of parameters gets to big. Figure 3.1: The old parameter concept 3.2 Making a New Design 3.2.1 Introduction to Collaborations Use cases are realized via Collaborations. Collaborations are key modeling constructs. They represent the way in which the use case is implemented in the design model. So it is possible to trace from the use case model (which expresses the software requirements) into the design. Figure 3.2 shows such a collaboration. 3.2.1.1 Structural and Behavioral Aspects of Collaborations Collaborations have two aspects: 1. A structural part that specifies the static structure (e.g. classes, interfaces, and subsystems on which the implementation is structured) 2. A behavioral part that specifies the dynamics of how the objects interact to accomplish the result 34 3. Designing the Right System Figure 3.2: A use-case realization in the design model A collaboration is not a physical thing - it is just a description of how elements of the system work together. For example a class diagram (see figure 3.3) can represent the structural aspects of a collaboration. The behavioral aspects might be represented by an interaction diagram (see figure 3.4). Figure 3.3: An Example Class Diagram 3.2.1.2 Using Collaborations to Realize Sets of Individual Requirements It is also possible to model the implementation of any individual requirement or any set of requirements as a collaboration, and apply that technique to achieve requirements-to-design traceability. With this extension it is possible to use requirements of all types to drive design and implementation. Figure 3.5 shows a model of requirements implementation as a collaboration. 3.2.2 Usage of Collaborations on the Configuration Problem Creating a design which meats all use cases and requirements would blast the scope of this student project thesis. So the process of design is described considering as example. As described above the most important feature is simple, redundancy-free administration of existing configurations. As described above this feature will be fulfilled by the following software requirements: 3.2. Making a New Design Figure 3.4: An Example Interaction Diagram Figure 3.5: Model of requirements implementation as a collaboration 35 36 3. Designing the Right System 1. Hierarchically meaningful grouping of information 2. Assign a default value to every attribute 3. A textual description can be binded to the configuration parts, directly This is the starting point for an appropriate design. Figure 3.6 shows the collaboration which interconnects the according software requirement to the design. In this case class diagram 3.7 represents the structural aspects of the collaboration. Figure 3.6: The collaboration which interconnects the software requirement Figure 3.7: The new type concept The collaboration is more intuitive when using modern design tools like [6]. In fact the collaboration contains the class diagram. The textual description in figure 3.6 should symbolize this. Figure 3.7 introduces the type concept. The type concept allows it to construct complex configurations which are still simple to be managed. This is reached by introducing a hierarchy into a configuration. This hierarchy allows a meaningful grouping of information because types carry sematic by itself. These groupings are called types. This is not absolutely exact but it will do for the moment. 3.2. Making a New Design 37 According to 3.7 a type has a name and a description. This description satisfies the software requirement: A textual description can be bind to the configuration parts, directly. Moreover there is a decission between a Simple Type and a Complex Type. These two classes inherit from the Type class. This decission is necessary because the type hierarchy must be terminated. That simply means that every Complex Type consists out of Simple Types at last. According to the definition of classes in object orientated programming a complex type consists of attributes. Attributes are variables which are members of a class of type. To be conform to the definitions of object oriented programming at this point, the attribute term is used here. Attributes have a name, a type and they can have a value. This is the point of recursion because an attribute has a Type and a type can be a Complex Type again. As described above every Complex Type consists of Simple Types. These Simple Types can have default values. This mets the software requirement: Assign a default value to every attribute. This is because every Complex Type consists of Simple Types. If every Simple Type owns a default value, every Complex Type will have default values automatically. Moreover a Simple Type can have Aspects. These Aspects confine the use of a defined type (classifiers). For example defining a date type would confine the month attribute from one to twelve. The software requirement: Hirachically meaningful grouping of information is met by the described type concept automatically. Because of the recursive nature of the described concept, the hierarchical depth of the configuration is user-defined. In this way the displayed design in figure 3.7 mets the requested software requirements. 38 3. Designing the Right System CHAPTER 4 Presentation of a Potential Implementation In this section a possible implementation for the previously described design is proposed. Such an approach should met the basic issues of the design. In this case the three mentioned software requirements should be fulfilled in any way. 4.1 XML as a Possible Implementation XML - the eXtensible Markup Language supports the definition of types. Moreover it is possible to create instances of these types. This is the dispositive criteria which allows XML for a possible implementation. This type concept includes the use of default values, hierarchy and documentation. Moreover the XML format is human readable. 4.1.1 Introduction to the Extensible Markup Language (XML) XML is designed to improve the functionality of the Web by providing more flexible and adaptable information identification. It is called extensible because it is not a fixed format like HTML (a single, predefined markup language). Instead, XML is actually a metalanguage - a language for describing other languages. This enables a potential developer to design his own customized markup languages for limitless different types of documents. It is obvious that XML is more than just a better INI-file format - in fact it is a real language. Figure 4.1 shows an example XML file named note.xml which contains some simple tags. Figure 4.1: A small XML Example 4.1.1.1 A Word on XML Schemas (XSD) XML Schemas express shared vocabularies and allow machines to carry out rules made by people. They provide a means for defining the structure, content and semantics of XML documents. XSD was approved as a W3C recommendation. In context to the previously met design XSD is used to define the Types. Beside, XML Schemas are an alternative to DTDs (Document Type Definitions) - the previous method to define document structures. The following arguments should point out why XML Schemas are better than DTDs: 40 4. Presentation of a Potential Implementation 1. XML Schemas use XML Syntax (a) No new language is to be learnt (b) Simple editing of XML Schemas by using the standard XML editor (c) Use of the standard XML parser to parse Schema files 2. XML Schema has Support for Data Types (a) It is easier to describe permissible document content (b) It is easier to validate the correctness of data (c) It is easier to work with data from a database (d) It is easier to define data facets (restrictions on data) (e) It is easier to define data patterns (data formats) (f) It is easier to convert data between different data types 3. XML Schemas are Extensible (a) Reuse your Schema in other Schemas (b) Create your own data types derived from standard types (c) Reference multiple schemas from the same document Figure ref:XSDExample shows the appropriate XML Schema to the XML example in figure 4.1. Figure 4.2: The appropriate XML Schema Now the task is to map the UML vocabularies, which were used in the previous design section, to equivalent XML vocabularies. This is topic of the following section. Additional information on XML and XSD can be obtained from [7]. 4.1. XML as a Possible Implementation 4.1.2 41 Conceptual Mapping from UML to XML At this point it is necessary to transform the design to the described technology. According to [8] it is possible to analyze XML vocabularies with UML. Figures 4.3 and 4.4 show the conceptual mapping of terms. For example a XSDComplexType in XML can be seen as a Class in UML. This enables a direct mapping from the design to the XML technology: For example the Attribute-class can be implemented by a XSDElement. The defined Simple Type and Complex Type can be directly accepted without any modification. Moreover the previously mentioned Aspects of the Simple Types can be mapped to the so called Facets. These Facets are restrictions on XML elements. The mapping from XML to UML is not always unambiguous. For example XML defines XSDAttribute and XSDElement while UML just uses terms like Class and Attribute. However, this does not cause any problem because it is only necessary to map from UML to XML in this case because the met UML design needs a representation in XML and not contrary. Figure 4.3: Mapping of terms from UML to XML part 1 4.1.3 Type Based Example Configuration for ComNets Simulation Framework in XML The following section illustrates the concept of type based configuration. Figures 4.5 and 4.7 show graphical representations of the XML Schemas. These graphics were created with [9] and show a small part of a possible configuration layout of the ComNets Simulation Framework. The appropriate XML code is shown in figures 4.6 and 4.8. Figure 4.7 for instance shows a type definition for a station. In this example a station can have a name, an id and a position. In fact a station has many more possible attributes but 42 4. Presentation of a Potential Implementation Figure 4.4: Mapping of terms from UML to XML part 2 Figure 4.5: Graphical Representation of an XML Schema which defines a Complex Type - a 2D point 4.1. XML as a Possible Implementation Figure 4.6: XML Code representation of an XML Schema which defines a Complex Type - a 2D point Figure 4.7: Graphical Representation of an XML Schema which defines a Station 43 44 4. Presentation of a Potential Implementation Figure 4.8: XML Code representation of an XML Schema which defines a Station these three should be enough to illustrate the concept. The position attribute is a complex type by itself. Obviously, the station type uses other complex types - in this case a defined position type. The definition of these two complex types takes place in two different XSD files. The station type simply includes the position type definition (like an inclusion of header files in C++). Evidently, it is possible to split type definitions to different files. That fact has a direct effect on the file size. The type definition is similar to a class definition in C++. In both cases an instance of the type and class respectively is needed. Figure 4.9 shows such an instance of a station type. The two attributes ID and Name are overwritten while the position attribute is left. This might cause the configuration mechanism to use the default values which are defined in the position type itself. Moreover the type definition can restrict the range of attribute values. This happens by checking the XSD against the XML input. 4.1.4 Implementation of a Prototype A complete implementation of a prototype would blast the scope of this student project thesis. However, this section makes some proposals which might be useful. An appropriate XML parser which supports the needed functionality (XML Schema, XInclude etc.) can be obtained at [10]. A possible solution might be the encapsulation of the XML mechanism into a Configuration Manager which provides an simple interface to the corresponding modules. 4.1. XML as a Possible Implementation 45 Figure 4.9: XML Instance of a Station Type 4.1.5 Review and Conclusion At last, the enforced process leads to necessarily useful results - the proposition of a solution which will met the stakeholder needs which have been captured at the beginning. These needs have been captured by interviewing the different stakeholders. These stakeholders have been identified by a previous stakeholder analysis. Moreover, an extensive problem analysis helped to identify the problem behind the problem. With this knowledge it was possible to define features which have been refined to real software requirements by using use cases. Additionally, some non-functional software requirement have been identified. On this base it was possible to drive an adequate design. This design was mapped to potential technologies. The next step in the process is the development of a simple prototype which proofs the usability of the selected technology. A solution which fulfills the captured requirements would present a simple to use configuration mechanism to the average user. In the long run the result will be profitable for the developers to, despite the higher development effort. 46 4. Presentation of a Potential Implementation LIST OF FIGURES 1.1 1.2 1.3 The Phases and Iteration of RUP . . . . . . . . . . . . . . . . . . . . . . . . 8 The Phases and Iteration of RUP with its superior meta layers . . . . . . . 9 Closed Loop of Finding the Ideal Solution . . . . . . . . . . . . . . . . . . . 10 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 Overview of the problem domain and the solution domain. . . . . . . . . . . Relative cost to repair a defect at different life cycle phases. . . . . . . . . . Fishbone diagram 1 demonstrates the root causes of the redundancy problem Fishbone diagram 2 visualizes the problem of huge configuration files . . . . Fishbone diagram 3 illustrates why the entity-mapping problem exists . . . System perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Needs and features are closely related . . . . . . . . . . . . . . . . . . . . . . This is a screenshot from a traceability matrix in Rational RequisitePro . . This is a screenshot of the used questionnaire for the feature prioritization . This figure shows the results of the feature survey . . . . . . . . . . . . . . . There are three different types of requirements . . . . . . . . . . . . . . . . Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Use Cases from Actors Perspective . . . . . . . . . . . . . . . . . . . . . The appropriate UML Activity Diagram to the Get Parameter Value Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 15 18 18 19 19 22 23 24 24 25 26 26 29 3.1 3.2 3.3 3.4 3.5 3.6 3.7 The old parameter concept . . . . . . . . . . . . . . . . . . . . A use-case realization in the design model . . . . . . . . . . . . An Example Class Diagram . . . . . . . . . . . . . . . . . . . . An Example Interaction Diagram . . . . . . . . . . . . . . . . . Model of requirements implementation as a collaboration . . . . The collaboration which interconnects the software requirement The new type concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 34 34 35 35 36 36 4.1 4.2 4.3 4.4 4.5 A small XML Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The appropriate XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping of terms from UML to XML part 1 . . . . . . . . . . . . . . . . . . Mapping of terms from UML to XML part 2 . . . . . . . . . . . . . . . . . . Graphical Representation of an XML Schema which defines a Complex Type - a 2D point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XML Code representation of an XML Schema which defines a Complex Type - a 2D point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Graphical Representation of an XML Schema which defines a Station . . . . XML Code representation of an XML Schema which defines a Station . . . XML Instance of a Station Type . . . . . . . . . . . . . . . . . . . . . . . . 39 40 41 42 4.6 4.7 4.8 4.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 42 43 43 44 45 48 List of Figures LIST OF TABLES 2.1 2.2 2.3 2.4 2.5 2.6 Problem Statement Format . . . . . . . . . . . . . . . . . . . . . . . Problem 1: Specification of configuration redundancy problem . . . . Problem 2: The problem of huge configuration files . . . . . . . . . . Problem 3: The problem of entity-address-mapping between different Use Case Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use Case - Get Parameter Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . layers . . . . . . . . 16 17 17 18 28 30 50 List of Tables GLOSSARY Collaboration Collaborations are key modeling constructs. They represent the way in which the use case is implemented in the design model. Configuration In this case a configuration is just a parameter configuration. A parameter configuration is the instance of a parameter space where specific parameter values are assigned to parameters. Feature A feature is a service provided by the system that fulfills one or more stakeholder needs. Parameter space A parameter space is a set of parameters. Each of these parameters has a defined range of values and a type. Requirement A software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation. stakeholder needs A reflection of the business, personal, or operational problem (or opportunity) that must be addressed in order to justify consideration, purchase or use of a new system. Use case A use case is defined as an accumulation of sequences of actions a system performs that yield an observable result of value to a particular actor. Parameter A parameter has a name and a type and takes exactly one parameter-value which must be conform to its type. Attribute An attribute describes a specific characteristic of a class. Subsystem A subsystem is a system which is entirely included into another system. It encapsulates functionality which is provided to the upper system but is still able to run standalone. 52 Glossary LIST OF ABBREVIATIONS XML Extensible Markup Language W3C World Wide Web Consortium XSD XML Schemas DTD Document Type Definition 54 List of Abbreviations BIBLIOGRAPHY [1] http://www.objectmentor.com. Rational unified process versus xtreme programming. http://www.objectmentor.com/resources/articles/RUPvsXP.pdf. [2] D. Leffingwell and Widrig D. Managing software requirements - a use case approach. Addison-Wesley, page 502, 2003. [3] IBM. Rational requisitepro (xde) - software for managing requirements. http://www.ibm.com. [4] B Bittner and I. Spence. Use case modeling. Addison-Wesley, page 347, 2004. [5] IBM. Rational xde. http://www-306.ibm.com/software/rational/. [6] http://www.w3schools.com. http://www.w3schools.com/schema/default.asp. [7] David Carlson. Analysis http://XMLmodeling.com. and design Information of xml [8] Altova. Altova xmlspy 2005. http://www.altova.com. [9] Apache. Xml parser. http://xml.apache.org/xerces-c/. on vocabularies xsd. with uml.
© Copyright 2024