Cmpt371 Lecture Notes copyright Edward Boyno Jan 2003 Outline 0. Introduction and Terminology 1. Requirements Analysis 2. Design 3. Implementation // Steps 3 and 4 will be examined in more detail in 4. Testing // Cmpt 372 In a couple of weeks, we will discussing at length, an example from the Book...The Interbank Consortium Example on p 113. Sometime between now and then you must read this example. There will be a quiz...be alert...I am going to ask you something about what the system is supposed to do. 0. Introduction and terminology. Defn.( p vxiii ) A process defines who is doing what, when and how in order to reach a certain goal. Systems Analysis and Design, is the study of techniques used to develop complex projects. These projects are often large pieces of software as it will be in this course, but the techniques can apply to other projects as well. People have been studying SA&D for dozens of years, but the arrival of computers thirty years or so ago has really brought an explosion of interest in the subject. Designing large, complex systems is VERY hard for a lot of reasons and because its so hard people have tried to develop idiot-proof processes to guide developers. In general these techniques can divided into three basic types: Top-Down, Structured Design also known as Algorithmic Design. Years ago this was the only technique that was used ( and taught ) for Software design. The idea was ( is ) to break a problem down into a set of smaller projects, then to break these smaller projects into smaller ones etc. It is relatively easy to learn and implement: Example and class discussion: Design a registration system for a mid-sized university. What's wrong with this approach: 1. Products lack flexibility. If the requirements on the system change either during the development of the software ( as happens often ) or if the requirements change after the software has been in use for sometime ( as happens 100% of the time ) major portions of the application will have to be rewritten and the application will have to be rebuilt. Example: An unnamed medium sized public university in the Northeast, decided to record student grades using plus and minus grades...it cost $100,000 to rewrite the part of the software which recorded grades and calculated gpa's. More recently this same unnamed medium sized public university in the Northeast decided to convert to a block schedule...the software had to be rewritten again! 2. Don't lend themselves to re-use. Products written with this approach are always "hand made" for a particular situation. Attempts to provide a commercial software package that fits every possible situation, winds up being the union of all things that every individual client wants. Even then some places require some very specific details that can be very expensive to program. Example: How many people here use all of the features provided by MS Word. How many people still finds that MS word still doesn't do some things that would be helpful. Example: The classic bad example is the SIS Plus system in use at Montclair. 3. Don't scale well. A program may work fine when applied to the relatively small application for which it was designed but if the size of the problem grows or if you attempt to move the application to a larger situation, it completely bogs down. Example: If you were planning your wedding, how would you construct the invitation list? What if you were planning the presidents inaugural balls ? Example: The program might actually work for someplace like Seton Hall with 6000 students but would be completely useless at a place like Michigan State with 30,000. Example: Games on the Apple II computer. Data-Driven Design. The structure of a system is derived by mapping system inputs to system outputs. More explicitly, every system is subject to some stimulus, perhaps an order from a customer or a request from a student to schedule a course. Similarly, the system produces a response to that stimulus, perhaps an invoice, a debit to a customer account and an order to a warehouse to ship an item. Systems designed using this technique don't worry about anything else except making sure that all the appropriate responses happen to any stimulus. This technique works well in simple business applications but again doesn't scale well and is pretty inflexible. Example: I wrote the program that the VP for Academic affairs used to use to keep track of faculty. The program had to keep track of each faculty's tenure status and produce a set of reports. There were certain pieces of information that I simply had to know in order to be able to produce the reports and that's how I wrote the program! Class discussion: try to think how a registration system could be built this way. What responses must the system have when a student requests a course? What documents must be created? Object Oriented Design. Employs the basic concepts of object-orientation: Hierarchy, Encapsulation and Modularity. Each of these techniques produces a model or set of models for the system. By "model" we mean an abstraction of the system. A given system will yield multiple models, each of which represents a different point of view or purpose. ASIDE ON MODELS. Every has some experience in building models. A seating chart for a party or wedding, a blue print, a map or a diagram of how to insert a node in a linked list are all models. A model that just about every uses is an address book. What info do you keep about your friends, cousins and tradesmen? Your model of every person probably varies a little bit...for some people you have an email address, for some a street address for some you have both. Each entry contains exactly enough information for you to identify someone and contact them. Making data models is verrry tricky...different people even within the same organization, can have different models of the same thing. END ASIDE A model will always provide a self-contained view of system which is sufficient for the purpose of the model. By self-contained we mean that the user of a model doesn't information from other sources or other models in order to understand the model. Later, we'll take about the various kinds models that we'll need to produce...these models can and often are in fact related to each other and we will also want to keep track of these relationships. These relationships are called trace dependencies or just traces. Examples later. More examples of models. Example: A blueprint contains enough information to allow a building to be built. Example: Setting up the seating plan for a wedding reception. Example: In MSU's phone registration system, your "model" of the system does not include anything dealing with the actual hardware or software for the system. The university's model of the system does include those but does not include any details of how a student chooses a particular class. In class exercise. Make a data model of your best friend...i.e. describe him or her. We are going to concentrate on an object-oriented technique called the "Unified Process" which is composite of three earlier techniques developed independently by the three authors. This process has three principles, they are: Use case driven; Architecture-centric, and Incremental. Definition. A use-case is "a particular form, pattern or exemplar of usage; a scenario that begins with some user of the system initiating some transaction or sequence of interrelated events" ( Jacobson ). Each use-case captures some function of the system. Example: In an ATM, when a user inserts their plastic card, the system reads the card, asks the users some questions and then acts according the answers. Example: In a word processor, if the user presses ^[end], the program must move to the end of the text, format and display the last 20 lines in the window. Example: The registrar reads a students transcript and decides if the student is eligible to graduate. Example: A patron borrows a library book. Example: A bank must restore its database to a consistent state after a power failure. The collection of all use cases for a system, forms what is called the use-case model. Everything that we do in this course will be centered around a use-case model that we will develop. At every stage in the process we will either be developing use cases or designing some part of the system to allow it to satisfy some use-case. Use-cases can be created at various levels of our model, beginning with some purely English language descriptions about what the system needs to be able to do and continuing all the way very technical, very specific descriptions of how the system needs to function. So we say that our technique is use-case driven. Example: In the ATM system, when a customer makes a request to withdraw money, we would expect the system to be able to check and see if the customer's balance is larger than the request....this is a high level use-case. At a second level, the designers of this system might decide that it was appropriate for the system to contain a communications module that would handle the request from the main transaction for balance information, communicate with the central bank database and the then report the data back to the transaction. At a third level, a Java program would have to communicate with the central database via ODBC ( Object Database Connectivity ) and tcp/ip in order to retrieve the desired balance data. All of these are use-cases of some sort and it will be our job to develop them. The architecture of a system is a collection of modules which interact to make a system work. If use-cases show us what has to be done, the architecture of a system describes how to do it. In general there are many ways to accomplish a specific task and the more complicated the task, the more ways there are to do it. The architecture of any system provides a framework for the whole project. Example. Any organization has several tasks that have to be done. Some have a president, vice- president, treasurer recording secretary, corresponding secretary etc.; some have only one secretary etc. Example: Some cars have the motor in front, some in the back. Some cars are front wheel drive, some are rear wheel, some are four wheel. ASIDE: Think of how the transmission of a particular car are dictated by the "architecture" of the car. END ASIDE Example: Fasteners on a dress can be zippers, buttons or even velcro. The fastener can go in back, in front or on the side. The decision of what kind of fastener to use and where to put has a large effect on how the dress will fit, hang and look. Examples: The architectures of Ingres and Oracle. These are both relational databases, but they handle common RDBMS tasks very differently. Both Ingres and Oracle keep data about their data ( called a database-database or dbdb) , Both provide security in the form of requiring users to have permission to access the data, and Both allow multiple databases to be run on the same machine. Having said that, they do all of these things differently. Ingres separates the database "engines" from the databases allowing one database to use multiple "engines" and visa- versa.. Further, Ingres uses one dbdb per computer. Oracle on the other hand provides one "engine" and one dbdb per "instance" or database. Ingres uses the computer's user list as part of its security system while Oracle uses only its own list. All modern DBMS' have facilities to recover a database in case of system failure. Ingres and Oracle accomplish this task in such different ways that it is nearly impossible to compare them. One simple way that they can be compared however, is in the way that they log transactions against the database. Ingres uses ( used?) a single "circular" log file while Oracle uses two files that are used alternately. /* Show the Ingres Process slide */ It should be clear that when designing a system, architectural decisions will play a large part in deciding how the system will work. The reverse is also true. Some requirements of the system may well dictate architectural features. In the example above, both Ingres and Oracle provide functionality that would be impossible if they didn't use what's called a client-server architecture. NOTE: When designing a system architecture, one needs to consider at least: the platform, the operating system and the required user interfaces. Example: It doesn't make sense to mount a multi-user system on Windows 98. Example: It doesn't make sense to plan to use a GUI on VMS Example: It doesn't make sense to any MicroSoft product Finally, when designing a system, the questions of what a system is supposed to do and how it will do it are intricately intertwined. So our technique must also be architecture-centric. Good systems do not spring full blown into existence. They are the result of multiple, controlled, incremental developments. In each increment, developers identify a set of use-cases, beginning with the most essential ones and moving towards the more tangential ones. Using the chosen architecture, they implement the design, and test. If the iteration satisfies the use-cases, they move to the next iteration. Our process will employ this incremental approach. This incremental approach is a VERY GOOD way to tackle large projects...ask yourself what things absolutely have to get done and get done right! Do them first! One should also look for "critical"portions of the project: are there particular parts of the project which may be very difficult or perhaps can't be done at all. These areas should also be attempted early on...the design of the project may have to modified in order to accommodate these critical regions. ASIDE: The "Star Wars" defense initiative has many "critical" regions. In this case, the critical regions are technological problems for which no solutions yet exist. You can judge for yourselves the wisdom of spending billions of dollars on a project that may never work. There is a technical name for people who want to spend billions of dollars on a project that will never work. LIFE HINT: Figure out what absolutely has to be done first and do them first. Do the critical regions early in the process. Example: If we were designing a registration system for MSU, the most important things to get done are registering students and keeping track of student records so we can tell if someone can graduate. Other desirable features like prerequisite checking, phone registration and on-line registration can come later. Some really nice features like on-line curricular advice are even more tangential and may wait well into the development cycle. Cmpt 371, 372 Project: Write a Transaction Manager Prologue: A transaction is, loosely speaking, a change made to a data file. There are three kinds of transactions: Insertions, deletions and updates. In an ideal world, every transaction would satisfy each of the following conditions ( known by their acronym: ACID): Atomicity. Transaction may not be allowed to partially complete; either the entire Tx must complete successfully, or the net effect must be that it never happened at all. Consistency. The Tx must move the data file from one consistent state to another. Isolation. A Tx must be isolated or protected from the effects of other possibly concurrent transactions Durability. Once a Tx has completed, its effect must be permanent, i.e. its effects cannot be lost in the event of a system failure or disk crash. At any given moment a Tx can be in one of 5 states: Active: Started but not completed Partially committed: finished but not yet permanent Committed: finished and written to the data file on disk Aborted: Ended irregularly, i.e. started but not committed Terminated: Committed or aborted. Project: The recovery manager in any data processing system is responsible for enforcing atomicity and durability of transactions. Our recovery manager will use the so-called ARIES algorithm. This algorithm has three main principles: 1. Any change made to a data object is first recorded in a "write-ahead" log. That record must be written to permanent storage before the change to the data object is written to disk. 2.After a failure, when the system restarts, the recovery manager retraces all of the Tx's before the crash; brings the data file back to the exact state it was in at the time of the crash and then undoes any changes made by Tx's that were active at the time of the crash. 3. Logs changes made to the data file during phase two to make sure that any changes made during part 2 are not repeated in the event that a failure occurs during recovery. Every log record is given a unique id called its log sequence number ( LSN). Log records are of the following type: Update Records contain the id of the Tx that made the update, a description of the data item that was updated and the before and after values of that data item Commit records also contain the id of the Tx that wrote it. The presence of a commit record in the log guarantees that the Tx has completed and that the changes made by the Tx have been made permanent Abort records indicate that the identified Tx has aborted. Aborted Tx's must be undone. End records indicate that any post- processing to a committed or aborted Tx has been finished. Compensation Log records contain information generated when an update record is undone. There are two other important recovery-related structures: The Transaction table contains an entry for each active Tx which has ( among other things a field called LastLSN which is the LSN of the last log record for this Tx The Dirty Page table which contains an entry for each dirty page in the buffer. During normal operation these structures are maintained by the Transaction Manager and Buffer Manager respectively. During recovery, they are used by the recovery manager. Schedule for the class project. Part One Requirements Analysis...Chapter 6 List Candidate Requirements Entire Class Individually - Understand System Requirements ( Domain Model ) Class list ( Wirfs-Brock method ) First Group Project - Class Diagram ( Rational Rose ) Second Group Project - Part Two Use Cases..Chapter 7 Capture Functional Requirements I ( Finding Actors) Capture Functional Requirements II ( Identify Use Cases )Third Group Project - Capture Functional Requirements III ( State Diagrams1)Fourth Group Project - Capture Functional Requirement IV (Interaction Diagrams 1) Part Three. Analysis...Chapter 8 Part Four. Design...Chapter 9 Design classes and use-cases Fifth Group Project - Part Five Implementation...Chapter 10 Par Six. Testing...Chapter 11 Class Discussion..What are the most essential parts of our recovery manager? Here begins the course... Defn: An artifact is a tangible piece of information. It may be a graphical model, source code, an executable image natural language text or something else. At the end of every phase of our process we will produce a set of artifacts. The Life Cycle: Any project goes through multiple cycles, each of which results in a product release. These cycles begin with the very first version of the product and do not end until the software is no longer usable ( something that doesn't happen to too many products these days...even COBOL is still alive ) A product release contains source code divided into modules or components that can be compiled and executed as well as associated items like manuals and training. The picture on p 11 is very good... Each cycle passes through 4 phases: inception, elaboration, construction and transition. In more detail: The "inception" is that phase in which the original idea reaches the point at which it is well developed enough to permit continuation. In this phase the designers must answer the following questions: What is the system primarily going to do for its major users? What could an architecture look like? What is the plan for developing the product and how much will it cost? The most important risks must be identified and prioritized during this phase. There are several kinds of risks involved. a. Developing some functionality might require the development of some previously unrealized process...the cost of developing the process might turn out to be VERY expensive.. Classic Bad example: SDI aka "Star Wars" defense intiative. b. Some system functionality might open the system to other kinds of error: Classic Bad Example....in the development of Microsoft Word, somebody should have realized that the introduction of the "macro" facility could be exploited by viruses... Another Classic Bad Example...wireless devices can be "overheard" and wireless internet connections can be tapped by unauthorized users. Yet Another Classic Bad Example...VMS provides a debugging facility called the Digital Debugging Tool ( DDT ). BUT it turns out that DDT is a highly privileged process that among other things has enough privileges to modify system files! Class discussion: are there any risks of this sort in our recovery system? The "elaboration" is that phase in which the architecture for the project is defined and most of the use cases are specified in detail. these two developments are not separated but really kind of work off each other to provide what the book calls an "architectural baseline". Other factors which contribute to this architectural baseline are: Which system software such as Operating Systems or DBMSs we want to use. Which middle-ware products such as ODBC we need to use. What if any legacy systems must be included in our product. Which standards and or policies we want to satisfy. We might want to adhere to the Object Management Group's Interface Definition Language, for instance. General non-functional requirements such as the need for 24/7/365 availability. Distribution needs...how will the pieces of the system be distributed among multiple possible nodes. Will we adopt a client-server architecture. Combining all these ingredients will provide for us early versions of most of the models that will eventually comprise our finished product. The book refers to this as a "skinny" version of the system and it is the principle result of the elaboration phase. Analogy: When you are writing a paper, you first construct an outline. By the time this phase is finished the project manager should be able to accurately plan the rest of the project, estimate its cost and have the risks until control. All of which should allow him or her to commit the organization to proceeding. The "construction" is that phase in which the software is developed to the point at which it is ready for distribution to the users. In the books terminology, the muscle is placed on the skeleton. At the end of the phase all of the use cases that were decided upon have been implemented. The product will not in general yet be free of defects. Defects will continue to be discovered through this phase and the next, but the product will be sufficiently advanced to show to customers. The "transition" is that phase in which the software is distributed to some experienced and knowledgeable users. This release is usually called a "beta" release and it's purpose is uncover errors and catalogue suggestions for improvements. Developers will divide these user comments into two general categories: those that should be addressed in this release and those that should pushed back into later releases. The comments that are to addressed will be and the changes put into a product that is release to the general user community. Finally, in this phase other things that must be accomplished include manufacturing and user support both in terms of writing manuals, providing training and of direct help. Each phase will normally contain several "iterations" as the idea ( architecture, code etc ) develops. The product of each cycle will contain not only executable code but other artifacts as well which enable to developers to move into the next cycle. Among the most important of these are a set of models. Those models include: A use case model containing all the use cases and their relationship to users. The architecture of the use case model consists merely of the major actors and scenarios. An analysis model which provides more detail for the use cases and makes an initial mapping of system behavior to the set of objects which will accomplish that behavior. The architecture of the analysis model is simply a description of the architecturally significant analysis artifacts. A design model that defines the subsystems, classes and interfaces as well the collaborations that are required from these artifacts in order to implement the use cases. The architecture of the design model looks more like what we call an architecture in common usage: a graph showing the main parts of the software and a flow of data. A component ( or implementation ) model which specifies the actual code components and maps the classes to the components. ASIDE: There is good analogy in Java here. The design model would contain the classes that you need while the component model would contain a list of the packages you've used. A deployment model which defines the physical nodes in the system and maps the components to these nodes. Example: My personal email system uses a server together with a client like Eudora on my PC. Further it allows me to store my unread message locally on my PC or on the network, similarly, I can let my folders either reside on the server or locally or both. A test model which describes the test cases used to verify the use cases ASIDE: Development of test models a very big deal..several MSU graduates are making a good living it. As noted earlier, these models will often have trace dependencies. These traces represent a "process or historical" relationship between two objects that represent the same concept ( in different models ). Example: One should always be able to trace elements of an analysis model to the appropriate elements of a use case. For a specific example, see p 44 of the book. The project is an ATM system and figure 3.4 shows a "trace" from an analysis model diagram to a use case....The icon for the "dispenser" represents a "boundary" class, the icon for "withdrawal" is that for a "control" class basically used to specify a transaction and the "account" icon is that of an "entity" i.e. something that represents information. Note: "Traces" go both ways. They are essential to understanding the models an often for change propagation. The final model is a representation of the architecture. As noted, within a phase, multiple iterations may take place. Each iteration itself consists of a blend of a familiar set of activities ( called the core workflows ): Requirements specification, Analysis, Design, Implementation and Testing. Some of the core work flows are more important during some of the phases. Requirements Analysis takes place predominantly during the Inception and elaboration phases and non-existent during the transition. Making the true picture of the activities like the picture on p11: < EXTENDED ASIDE > The four P's of SA&D: People, Projects, Products, Process and Tools. People: The leader of any project must always be aware of the people involved in it. "They finance it, schedule it, develop it, manage it, test it use it and benefit from it". The following are key to keeping all the people happy. Project feasibility. Nobody wants to work on a project that can't succeed. It's a career killer. Risk management. You can't avoid risk, but you can analyze it and control it. Team Structure. People work better in groups of six to eight Project Schedule. Unrealistic schedules make people doubt their ability to complete the project and make the project management look like they don't know what they're doing. Project Understandability. People work better when they understand what their role in the project is. Success. There is no better confidence / morale builder than success. Defn. A worker is a person or group of persons who have the responsibility to perform certain tasks and / or produce certain artifacts.. A worker-type denotes the part that worker might play in the process. We might ordinarily use the word "role" for this idea.. Example: One "worker" on almost any application would be a user-interface designer. In general this will not actually be just one person, although one person might have to overall leadership and reporting responsibility. Project: The organizational structure through which the development of a product is managed. By this we mean the sequence of iterations and changes that lead to a finished product. The idea of a project also involves a collection of people who are assigned to execute the project within the usual set of constraints: time, cost, quality. Product. The complete set of artifacts that are produced during the project. This includes the source code and executables of course but other things such as UML diagrams ( below ), descriptive text, test plans etc. There are two basic kinds of artifacts: "engineering" and "managerial". We concentrate on the engineering kind but you should be aware of the managerial kind as well. They include a development plan, a plan for allocation of personnel, specification of process automation software, hardware as well as perhaps a repository for the engineering artifacts. The engineering artifacts include a collection of the kinds of models we've been talking about. ( Use case model, analysis model etc. ) It is fair to say that building a system is the process of building a collection of models. Process. A process is essentially a template for a project...it is the definition of a set of activities not their execution. This course, as well as the text book is about process. One good way to describe process is as a set of "workflows": Definition. A workflow is simply a set of activities. The authors describe a process as a set of workflows that are organized according to the workers that perform them. See Figure 2.6 . The horizontal divisions of the diagram are called "swim lanes" In UML a workflow is called a "stereotype of collaboration" and is pictured in Figure 2.7 Why use a process. ( i.e. what good is this course ) Every one understands what they have to do. Developers can understand what other developers are doing... At different stages of the same project In similar projects of the same enterprise In similar projects at different companies Non-technical personnel can still understand what's going on Personnel can transfer between projects without having to re-learn a system Training can be standardized - Don't under value THIS! The process is repeatable so that cost and time estimates can be more accurate. IMPORTANT NOTE: The workers on a project are, of course, made up of actual people and these people may change during the course of a project. They may move from one worker to another, join or leave a worker in mid stream and may be working on more than one project at the same time. It becomes VERY important that 1. People understand the process and their part in it, and 2. There is a central repository of artifacts so that every person/worker has complete information about the state of every project. There is commercially available software development tool that provides not only such a central repository but also provides us with a widely used modeling tool developed over the years by two of our authors Booch and Rumbaugh. The tool is called the Unified Modeling Language ( UML ). UML which is rapidly becoming the standard modeling tool, is graphical and is actually a collection of tools used to construct various kinds of models. The commercial software is called "rational rose" provided by a company called the Rational Corp ( which is now owned by IBM ). You can download a copy of "rose" from www.rational.com. We own a license for a full copy of Rational Rose, it is accessed on the pegasus system by typing % rsds // Don't do this yet! There are numerous book available on UML many of which include a working copy of a UML modeling program. The one that I use is: Eriksson & Penker UML Toolkit, John Wiley ( includes CD-Rom ) A complete project will also contain a collection of relationships between models. UML calls these trace dependencies just like we do...the idea being that you should be able to "trace" some aspect of the design back to earlier models such as the analysis model. Tools. Software used to support all of the above. These tools provide consistency across the life cycle by providing a repository in which all models can be stored and compared. A tool should be able to provide _ Requirements management...i.e. store, review, browse, track and annotate the requirements of a system. Further, a tool might allow us to associate a requirement to other artifacts in the life cycle. _Visual modeling. _Consistency among various models _Programming Tools _Quality Assurance. A way to record and execute test cases _Version Control. _ Configuration Management _Defect Tracking _Documentation _Process Automation Rational Rose provides tools for the first 4 of those requirements. < ASIDE TO THE ASIDE> UML is far from the only system that can be used to describe and record system development. Some others that you may run across are Entity-Relationship Diagrams, The Semantic Data Model and Data Flow Diagrams. < END OF THE ASIDE TO THE ASIDE > < END ASIDE > 1.1 Requirements Analysis. This is by far the hardest part of the process. Conventional wisdom holds that you can find out what the system ought to do by asking the users....NOT. Most users only know what they themselves do, they can't describe what the entire system should AND even if you rely on users to describe only their part of the system they still can't do that adequately. Example and Object lesson: Take ten minutes and write down how to make your favorite ( simple ) meal. Example and homework: Either Explain the rules of your favorite sport, or Explain the rules of your favorite game, or What your duties are at your job. The purpose of this workflow is to describe the system requirements well enough so that an agreement can be reached between the client and the system developers on what the system should and should not do. We are going to accomplish this in 4 steps. These steps are not necessarily sequential and are certainly not independent! i. List candidate requirements ii. Understand system context iii. Capture Functional Requirements ( producing a use case model ) iv. Capture Non-Functional Requirements.( Like the need to maintain software licenses ) Extended example.. i. List candidate requirements. This is essentially a brain storming list. Users, customers, testers, developers, and others are always coming up with ideas for the system. Some of these brain storms are pure pie-in-the-sky, but other may describe real system requirements, so the first step in the process is to make a list of all these "features". Our "feature list" will actually be a table containing the following columns: Feature Name char(10); Brief Explanation char(50); Status { proposed, approved, incorporated, rejected }; Estimated Cost Money and /or Man hours; //necessary to implement Priority { Critical, Important, Ordinary, Low}; Risk Level { Critical, Significant, Ordinary }; // Why use a "feature name"? At each iteration, some feature or features will be implemented based on the values of these variables. For example, you probably leave to last ( if at all ) a feature that is Low priority but which carries critical risk NOTE: This is the first part of your project. ii. Understand System Context. In this step developers will create what is called a "domain model". A domain model describes the important concepts relating to the context of the system. This description takes the form as a collection of objects or classes and links between them. These object or classes represent the things that exist within a system or the events that transpire in the environment in which the system works. How to do it . ( Adapted from Wirfs-Brock ) Gather all documentation including user interviews. Make a list containing all the nouns and noun phrases found in the documentation and user interviews. Each of these is a potential object/class of the system. Go through the list including or excluding noun phrases based on the following rules: Include any noun phrase that represents a physical object in the system. E.g. Passenger, invoice... Include any noun phrase that represents an abstraction that is meaningful to the system. E.g. Flight, Order. Exclude any noun phrase that is merely a synonym of another noun phrase on the list. Choose the synonym that is most descriptive. Exclude any noun phrase that are too abstract. E.g. Time. Exclude any noun phrase that represents things outside of the system. E.g.Developers. Exclude any noun phrase that represents an attribute of another noun phrase. E.g. Transaction Date Be careful of adjectives. They may or may not be describing different things than the noun they modify. E.g. Cash Withdrawal is not really different from Withdrawal, but Talking Book and Book are very different things. ASIDE: The Book has a slightly different approach to understanding system context. It recommends identifying classes. Accept 1. Business objects such as orders, accounts and contracts 2. Real world objects and concepts such as enemy aircraft, missiles and trajectories. 3. Events that may have already taken place such as aircraft arrival or departure and alunch break. I like the Wirfs- Brock list better, but you should ultimately get the same list of classes either way. NOTE: It is highly unlikely that this list will be the final one. I will be a very unusual situation if you didn't later drop some of the classes you list in this step and equally unusual if you didn't add classes later. NOTE: It is important to understand that at this stage of the process we are just trying to understand the general parts of a system. It very tempting to begin thinking in terms of how the system will eventually work, but THAT IS NOT THE POINT OF THIS STEP....we are just in the information gathering phase and have to remember that. Example: Interbank. p119 Extended example: ( Adapted from Lewis and Lofton. ) Class exercise. The program will act as a Mortgage calculator. Users will enter a mortgage amount, the interest rate for the mortgage and the duration of the mortgage measured in months. The calculator program will the display the total amount that the user will pay over the life of the mortgage and how much the user would have to pay each month in order to pay off the mortgage in full. The second element of the domain model makes explicit the relationships between classes. The domain model is captured in UML by a class diagram. UML recognizes four types of relationships: ISA represents a class/subclass relationship Example: A Student ISA Person Example: A Withdrawal ISA Transaction HASA ( or "is part of" ) represents the aggregation hierarchy. Example: A Student is part of a Class. Example: A Class HASA student Example: An ATM HASA Card-Stripe Reader Note that we are NOT talking about attributes...It would not be correct to ascribe this property to attributes. non-Example: We would not say that a Mortgage HASA interest rate. USES represents the client/server relationship. This means that one class ( the client ) relies on another class ( the server ) to perform some action for it. In UML the USES relationship is called a dependency, as in the client depends on the server. Example: An ATM USES an Network to communicate with the central bank. Example: A Convoy USES its Escort to keep the bad guys away. Example. A Faculty Member USES a Student to fund a Retirement Account. . Association. Any other relationship that doesn't fit it the previous categories. Example. A Student consults with his/her Faculty advisor. One last thing to be discussed is called the navigability of the association. An association is called uni-directional if only one of the objects in the association can reach ( or even knows about the other ) and bi-directional if both partners can traverse it. Example: The relationship between parts of a system and things like a system clock are usually uni-directional, the system will always originate a request to the clock for information. Example: The relationship between an instructor and a class would be bi-directional since the instructor knows the class and vica-versa. UML Tutorial I. Class Diagrams Class Graphical Depiction: A class icon is drawn as a 3-part box, with the class name in the top part, a list of attributes (with optional types and values) in the middle part, and a list of methods (with optional argument lists and return types) in the bottom part. Either the attribute or methods sections of the class box can be suppressed to reduce detail in an overview. Suppressing a section makes no statement about the absence of attributes or operations, but drawing an empty section explicitly states that there are no elements in that part. Each class must have a name which must appear in the first box, in bold face print. You can further refine a class using the following adornments Abstract //Defines the class as a base class with no instances. Persistency //Class is not extinguished when the program terminates. both of theses are denoted by a parenthesized tag in the name component of the class icon Some Other stuff is specific to C++ A Parameterized class is adorned with an overlying box on the upper left hand corner of the class box containing the class or type of the parameter. Example: Too much trouble to draw In Rational Rose all class icons with the same name represent the same class in the model, regardless of the diagram in which they appear. Each appearance of a class's icon in a diagram displays a subset of the model's information about the class; all of this model information can be viewed in the class's specification. Relationship Icon Generalization An arrow from the subclass(es) to the superclass ( ISA ) Aggregation A line with an open diamond on the end next to the Aggregate ( HASA ) Composition A line with a filled in diamond on the end next to the Composite ( HASA ) USES An arrow with a dashed line from the client to the server Association A simple line ( otherwise unspecified semantic association ) Relationship adornments: Cardinality A number or the symbol * which indicates the number of times an instance of the class ( object ) participates in the relationship Role This is a purely textual adornment which specifies the role an object plays in the relationship. The amount of detail that gets into the diagram depends on the part of the process that we're in. During the requirements phase we wouldn't necessarily be too concerned about the actual attributes of a class, but would add them as it becomes necessary. Example: Interbank p 120 Understanding System Context Using a Business Model. This is very similar to domain modeling, except that instead of viewing the system from the point of view of domain experts, we view it terms of commonly understood business processes. Said another way, it examines a system from the point of view of what it does for "customers". NOTE: Don't be mislead by th use of the term "business"...anything can be thought of as having a business and some common business practices. Definition: ( p. 123 ) A business entity represents something which workers access, inspect, manipulate, produce or use in a business use case. Example: an invoice Definition: ( p. 123) A work unit is a set of business entities that forms a recognizable whole to an end user. Definition: An actor represents a party, outside of the system, which interacts with the system. An actor may be a person, a set of persons or it may be some other external thing like a clock. Developing a Business model 1. Identify the actors and the business use cases that the actors use. 2. Develop a business object model consisting of workers, business entities and work units that together realize the business use case. These business entities are the analogy of the domain classes...although in a given instance they may not be exactly the same. There are ( or should be ) many similarities between a domain model and a business model. The domain model only models the things that are part of the system context, while the business model also identifies some of the workers that are necessary to work with them. Interbank p 119, p 122 and p124. iii. Capturing the functional requirements as use cases. Definition: When discussing use-cases, an actor represents a party, outside of the system, which interacts with the system. An actor may be a person, a set of persons or it may be some other external thing like a clock. Actors may participate in multiple use-cases. They will play a different role in each use case in which they interact with the system. One use-case will in general involve multiple actors. Example p 135. A person ( the actor ) withdraws money from an ATM ( the system ). This is the use case. Each time a particular person uses a particular pin to withdraw a sum of money, we count that as a separate "use case instance". Each use case has operations and attributes. In the example, one of the actions might be to "prompt for PIN"; the attributes would be things like the PIN and the amount withdrawn. There are several tools in UML which can be used to represent use-cases: State Diagrams and Sequence Diagrams are the most useful. State diagrams show the general flow of a use case including branches and loops; Sequence diagrams are more specific and can be used to represent a particular path through a sequence diagram. ( later ) Finding Actors and Use Cases Finding the actors is pretty straight forward. 1. Identify users and organize them into categories that represent actors. Example: In the ATM application, you would group a whole bunch of users into a category that you might identify as the actor "People who make withdrawals". 2. Identify external systems that interact with the system. Example: In the ATM application, the system may require the user to supply his/her PIN within 60 seconds. The clock is an actor. 3. The system may require several "standard" system-actors which perform basic system services like start up or shut down. 4. Each actor should be given an appropriate name. Guidelines: 1. It should be possible to find at least one actual person or thing that represents every actor. I call these actor-instances. 2. The actions of two actors should not have a lot of overlap. If there is, you should consider merging the actors...in the ATM example, the actors "People who make withdrawals" and "People who make account inquiries" both have to insert their card, supply their PIN, answer the same questions ( Checking or Savings ) etc. They might actually be only one actor, "Customer" or perhaps ATM user. Class exercise: What are the actors in the recovery system? Finding use-cases. There are several places in which you may uncover use-cases: Interviews with users and customers. Review of existing documentation. Just as the nouns in the documentation are potential classes, so are verbs potential actions. In my experience, the second is often better ( easier and more accurate ) than the former. Use-cases should be named...usually with verb phrases like "Withdrawing cash" and should be accompanied by a brief description. Potential use-cases can be discussed with actor instances. They can provide insight into what processing is needed. They may also point to other actors which are needed to complete a use case. E.g. a time stamp Use-cases can get very complicated very quickly....it may be that a large use-case could be decomposed into a sequence of smaller, more manageable ( and easier to test ) use-cases and not every potential use-case needs to be or should be modeled especially in the first iteration of the software. Example: Recovery systems all have a mechanism for dealing with instances in which the log file gets too full. This is very complicated stuff and we probably don't want to get involved with it now. The conventional wisdom is that a use-case should "...deliver an observable result that is of value to a particular actor". Each successfully executed use-case provides value in the sense that an actor achieves some goal. If there are multiple actors, the test should be applied to the initiating actor. Use-cases themselves can be organized into "use-case clusters" to create higher level use case- models. These are called "use-case" diagrams in UML. The art here is deciding which use cases to include in the clusters. There are two basic rules either one of which can be used or both: Cluster use-cases to describe a general business situation...for e.g. the set of use cases that describe what the system has to do to dispense cash at an ATM. Cluster use-cases to display all the operations dealing with a single actor...for example, cluster all the use cases dealing with an external customer. It may be desirable to generalize individual use cases into more general ones, see books example p 167 to 170 < ASIDE > A general rule of design is to attempt to decompose complex use-cases into a sequence of simpler "atomic" use-cases....this really does simplify design and greatly increases re-usability. Example: The use case "User Makes A Withdrawal" can easily be broken down in several smaller use cases like "User Inserts Card", "System Requests User PIN", and "System Verifies PIN". This last might itself be broken down into "User Enters PIN", "Keyboard Read PIN" and " System Retrieves PIN From Card"...this last can further be seen to include "System Reads Card Stripe"..which is clearly reusable. < END ASIDE > The final activity of this part is the prioritization of the use cases so that the most essential of them can be developed in the early iterations. Class exercise: what are the three most important use cases for the recovery system? UML tutorial II: State Diagrams, Sequence Diagrams and use-case Diagrams. State Diagrams. Are kind of like flow charts. Each "state"represents some possible configuration or state of the system.. In the ATM example, possible "states" might be "ready", "paused", "communicating" or perhaps "stopped". The system moves from state to state according to a stimulus or action on the part of some actor. In the same example, the action of a customer inserting his/her card into the machine might cause it to move from "ready" to "communicating" etc. Example: There are some pretty clear "states" in our application. Most of these apply to material, what are they? _There are two icons that should always be present, a filled in circle which represents the initial or start state and a "bull's eye" representing the terminal or final state. _The state icon is a rounded rectangle. It should have a name. _Transitions are represented by an arrow that points from the old state to the new one. _Each transition must be accompanied by a piece of text describing the stimulus which causes the transition. It may also accompanied by an operation which should occur during the transition. _Individual state may have some internal transitions which are denoted by text inside the diagram. Class Activity: Draw a state diagram to describe the use case: Verify PIN. Start with the ATM in Communication state after the card has been read. Interaction Diagrams: Describe essentially the same things that state diagrams to but with a different emphasize. Icons in these diagrams are columns, headed by a rectangle representing an object ( actor ). Flow of control is represented by arrows moving from column to column. These arrows are transitions exactly as in the state diagrams, and similarly may have labels showing what action caused the transition and/or the operations that are performed during the transition. The columns are additionally adorned by rectangles which show which object/actor is in control of the current operation. Note that in interaction diagrams, time flows from top to bottom, so that the actual sequence of events is automatically displayed. Also note that you can represent only a single thread of action, unlike the state diagrams which can have branches and loops. Class Exercise: Redo the state diagram of the previous exercise using an interaction diagram. Use-case diagrams are very simple. See Fig. 7.12 Actors are represented by stick figures and individual use-cases by ovals. iv. Capturing non-functional requirements. Non-functional requirements come in several different types and must be handled in different ways. Performance constraints are such things as speed ( generally the average time required to complete a transaction ), throughput ( the number of completed transactions in a fixed time period), response time ( how long a user waits for the system to begin processing )and memory usage may be attached to relevant use cases as text placed in an addendum. NOTE: Speed and throughput are not the same thing. Consider a system in which two Tx's arrive at the same time. One will require 10 seconds, the other will require 50 seconds. The question is the order in which the Tx's will be processed. Either way, the throughput will be 2 Tx's per minute but if the shorter Tx goes first, the average Tx time will be 35 seconds ( 10 + 60 ) / 2. If the longer Tx goes first, the average Tx time will be 55 seconds ( 50 + 60 )/ 2 . ASIDE to the NOTE: It seems obvious that we always ought to allow shorter Tx's to go first but you can always concoct a scenario in which this strategy can cause a lot of problems. Others constraints that are very important are things like 1.reliability ( There are two generally used measures of reliability: availability - what percentage of the time is the system available and mean time between failure - how long will the system run before failure is likely), 2. maintainability, the ability to changes and updates to the system, 3. extensibility, the ability to extend the system to new areas or to new clients, and 4. platform dependencies. Platform dependencies are a different kind of constraint that mere states that the system can only be installed on a particular platform or platforms. These dependencies are too general to be attached to any specific part of the analysis and must be included as a list of "supplementary requirements". 1.2 The Analysis model is the second of our major models. It acts as bridge from the requirements phase to the design phase. It 1. Gives a more precise description of the requirements. 2. Uses more technical language ( as opposed to the language of the problem domain ) As a result of the Analysis phase, the system should become easier for developers to understand, maintain, change, etc. It is a first pass at the development phase. In some sense, the Analysis model is orthogonal to the previous models. By this I mean that this model doesn't really add any new information to the Requirements model, but just adds more detail. Example: In the ATM example, a use case in the Requirements model might just say "connect to host", in the Analysis model we'd specify the separate actions needed to connect. In the forthcoming Design phase, we'd specify what objects need to exist and what actions they must take in order to complete the use case. The analysis class artifacts are: Analysis Classes The Use-Case Realization - This Analysis Phase The Flow of Events Analysis Phase The Special Requirements Analysis Phase 1. Analysis classes a. Focus on handling functional requirements versus non-functional ones. b. Don't provide details at the level of class signatures but specifies behavior in terms of responsibilities. c. Do provide attributes but at a level and with terminology that can be found in the problem domain. d. Do specify relationships between analysis classes but again at a higher more conceptual level that subsequent models. You may specify relationships among analysis classes that may not be possible in the implementation. Example: You specify a generalization relationship between analysis classes even if the implementation language will be C, a language that does not directly support this relationship. e. All of three types ( stereotypes actually ): Boundary classes, control classes and entities. Boundary classes are used to model the interaction between the system and its actors... the "boundary" of the system if you will. They contain ( abstract ) representations of user and communications interfaces. The icon is a circle with a "T" on the left side. See the bottom of p182. Each boundary class should be associated to some actor and visa-versa. See the top of p 184. Entity Classes model information that is maintained/used by the system. These often mirror class found in the domain model, but where the domain model focuses on objects that are part of the problem domain, the entity classes focus on objects that are actually part of the system. Books example ( p 185) is good. In a business domain, we'd probably model an "invoice", an invoice class would also be part of our system and at the level of the analysis model, we'd begin to think about what attributes it might have and what behavior it might have. Entity classes are often persistent meaning that they should be kept in a database, not just by a program. The icon for a Entity class is a circle with an "underline". Note also that an entity class is often associated to a boundary class as in the books example. Control classes represent coordination, sequencing, transactions and control of other objects. They encapsulate changes to control, coordination, sequencing, transactions and perhaps other business logic. A better example than the books is a transaction manager. ASIDE: When a change is made to some part of a database, care must be taken that 1. The transaction is not lost in the event of some failure of the system, and 2. That multiple transactions on the same data set don't interfere with each other. The software module that does this is usually called the "Transaction Manager". There are several techniques that deal with of these problems. Most of these require the use of some sort of transaction log into which all the changes that are made to a data item are written ( before the change is actually made). If a failure happens the transaction system can consult the log in order to restore the system. There is an interesting architectural aspect of transaction processing here as well. If a system is to be distributed, one must make a decision about to whether or not to give each node each own log or to place the log in on central location. END ASIDE. The icon for a control class is a circle with an embedded arrow. Finally arrows indicate flow of control in an analysis use case and these arrows may be labeled. Example: The payment Scheduler Control Class: p 185 NOTE: Divorcing Analysis classes from the implementation language allows much more clarity and simplicity in the design, because you are not bound to any particular syntax. RHETORICAL QUESTION: How many people like the syntax of Java for class defintions: class LinkedList implements List // before you've specified a single thing. The Use-Case Realization - This Analysis Phase Artifact is a re-iteration of the use cases of the requirement phase in terms of the analysis model. It may also use class diagrams and interaction diagrams made more specific. It may also make use of collaboration diagrams ( p187 ) The Flow of Events Analysis is a text artifact to further explain the above diagrams. Class Exercise: Make a collaboration diagram for "Verify PIN" Class Exercise ..Make an Analysis Class Diagram and a collaboration for the Use-Case Tx writes a data item The Special Requirements Analysis is another text artifact used to specify all non-functional requirements. The Analysis Package is an artifact that organizes the other artifacts. It can contain analysis classes, use-case realizations, Flow of events and special requirements analyses as well as other analysis packages. They are use to capture major subsystems of the system. These decompositions of the main system should be characterized by cohesiveness...the pieces of the package should be strongly related, and loosely coupled...the relationships between packages should be minimized. In the ATM example, one could conceive of a package dealing entirely with user interaction and another dealing with managing all the back end transactions. In our recovery system? Systems must also provide some basic services to its member objects. In the ATM example, the Transaction manager, among other things, may need to connect to its remote host. Thus it needs some classes whose job it is to make the connection: a dialer, login manager, etc...We may specify such service packages in the analysis model. Java users should be especially comfortable using such packages because Java is really designed to use them. A service package: _contains a set of functionally related classes ( the Math package ) _is indivisible...you either get the entire package or none of it _may participate with other service packages to satisfy a use case _rarely interacts with other service packages directly _is used only by specific actors _are often add-ons to a system ( spell checker ) _may be parallel to other service packages (British vs American spell chequer ) _are an essential part of the subsequent design. Service packages are really separate from the main system and can and should be re-usable. Finally, the analysis model, especially the analysis packages, provides a basic framework for the system architecture. Read sections 8.6 and 8.7 to learn more about the analysis model. This analysis step is very appropriate to really large projects. In our little project, and many others, its duties can be distributed between the Requirements and Design Phases. 2. The Design Phase. In this phase, the analysis phase is mapped to real computing tools. The purpose of this phase is to create a abstract framework for the project. A successful design allows implementers to merely fill in the details. In order to do this, the design phase must be able to view the analysis in terms of constraints like: Programming languages Operating systems Database management systems User interface tools Distributed processing Multi-user environment and concurrency control Transaction management tools Internet interface and other "non-functional" requirements such as component re-use Other activities in this phase include _capturing the requirements ( i.e. the signatures ) on individual subsystems, interfaces and classes; This is again a look ahead to the implementation phase and provides a starting point _decomposition of the project into pieces that can be assigned ( when possible ) to ( possibly concurrent ) development teams.; _creation of inter-system interfaces. Artifacts of this phase include: the design model; design classes; the use case realization design phase; the design subsystem; interfaces ( in the general sense not in the sense of Java ); an architectural description of the design model; a deployment model. 1. The Design Model is an abstraction of the system's implementation. It "..describes the physical realization of the use cases..." showing "..how the functional and non-functional requirements and other constraints.." can be implemented. It is a aggregate of several design subsystems: design classes; the use case realization design phase; the design subsystem; interfaces; ( see p 218 ) A Design Class is a an abstraction of a construct in the systems eventual implementation. It will be expressed in terminology that is consistent with the eventual implementation language...so ( if we were to write in Java or C++ ) we would use that syntax to specify data types; parameters and visibility ( public, private, or protected ). Some relationships have a direct mapping from the analysis to the design. In particular, _generalization ( ISA ) in the analysis model is inheritance in C++ or Java, _aggregation in the analysis phase is often expressed by instance variables in C++ or Java Example: In the book's Interbank example, there is an entity class called invoice ( p. 185 ). In the design phase we would discover that we do in fact require an Invoice class and an Account class. We would further be interested in assigning instance variables to this class and uncovering associations. Since every invoice must be associated to an account, we would specify that association by giving Invoice an association to an object of class Account. ( p 220 ). If the implementation language was in fact Java we might go further and express this relationship by including an instance variable in class Invoice which is of class Account. Example: I know at least one language ( Objectivitydb DDL ) allow the specification of many to many associations, in Java or C++, you must often use a dummy class ( called an association class). Consider the relationship between a Student and a Class. This would have to be modeled in Java by the creation of a class probably called Enrollment... Methods may or may not be specified in this model. If they are they usually expressed in natural language or pseudocode with the actual code delayed until implementation. It may be appropriate to provide the model with some specific constructs from the language. Example: In C++ it may be appropriate to use parameterized classes. In Java you would almost certainly use "interfaces". Example: In VB or when using a language that provides "instant constructs" like Java you might declare a class to represent a "window" or a "text box" Similarly, it may be desirable to include interfaces, not in the sense of Java, if the underlying language does. It may be appropriate to postpone some requirements of a design class if they are heavily implementation dependent. Apropos of this, a designer may include a textural adornment containing implementation details. Example: one that comes to mind right away is the back end file handling that an application may require. These details cannot be decided in the design phase since the implementation will be heavily dependent on the operating system ( Unix, Windows XP, IBM ). Design classes may be active or not. The distinction is important because an active class ( one with its own thread of control that runs independently of other classes ) may in fact be better classified as a process....in this technique most design classes are not active. The Use-case realization - Design phase describes how a use-case is realized using the Design classes. It is a direct descendent of the use-case realization analysis phase. ( i.e. has a direct trace ) which is direct descendant of an actual use case. In a small project we might skip the analysis phase in which case the trace would refer back to the actual use-cases. Further, even when use- case analysis phase is used, it may not be carried forward to the end, being subsumed by the use- case realization Design. For this phase we use the following tools: 1. Class diagrams which contain the actual design classes perhaps with a restricted set of member variables so that the focus remains on a particular use-case. Example: Consider again the example above regarding a Student's enrollment in a Class. In the previous use cases, the flow would go directly from the Student class to the Class class. In the design phase, we know that there is an association class, Enrollment which must now be part of the use case. 2. Interaction ( sequence ) diagrams to describe the sequence of events when an actor invokes the use-case. It will contain the design classes and, possibly, the subsystems necessary to implement the use case. In some instances it is helpful to depict the interfaces provided by the subsystems. Example: in the ATM example, we'd have an interaction diagram to describe what happens when a PIN is correct and another to describe when it is wrong...both of these are needed to describe the use case that is initiated when a customer begins a transaction. 3. Flow of events - design phase is simply a textural add-on to the interaction diagrams to make them simpler to read and/or to amplify the diagrams. Flow of events text may also be used to show how multiple interaction diagrams are related.. Example: in the example above you might annotate both of the interaction diagrams to make that the user knows that it one of a pair. 4. Implementation requirements are again textural descriptions that capture any non- functional requirements of the use - case. Example: In the ATM example or the enrollment example, it might be appropriate for a designer to note that it some point, it will be necessary to apply standard transaction management techniques. The Design subsystem is merely an organization of the other pieces ( and perhaps other design subsytems ) into manageable parts which can then be separately implemented. Each subsystem should be internally cohesive, that is the classes, interfaces etc which comprise the subsystem should be closely related to each other. The relationship between classes should be loose ( jargon phrase: they should be loosely coupled) meaning that their dependency on each other should be minimal. Example:. In the ATM example, the "user interface subsystem" contains a whole bunch of classes that are closely related: The CardReader class, the KeypadReader class etc. This subsystem has very little to do with the "transaction management subsystem." Organizing the various classes in this way is an example of "loose coupling". It would make a lot of sense to develop them separately, perhaps with different development teams. Class discussion: Can you divide the classes in our library system into design subsystems? Other characteristics of design subsystems: _separation of design concerns Example: The user interface vs Transaction management again _large subsystems may map directly to analysis artifacts _subsystems can represent "large-grained" components of the systems implementation.. Example: a user interface subsystem would "hide" device drivers etc... _subsystems can represent reused components. This allows developers to think about how to integrate these components into the current system. Example: The Corel suite of products, WordPerfect, Quattro and Paradox all use essentially the same set of menu button and icons, designers of current and future Corel products can include these buttons and icons in any design as the appropriately named subsystem.. _subsystems can similarly be used to "wrap" legacy systems and show how they can fit with the other components. Example: Most databases these days are what are called "relational databases" and many systems that need a database to function would be designed to use a relational DBMS and especially the relational query language SQL. If your organization has a non-relational legacy system ( as many do ) a "wrapper" system could be written so that the legacy database could interface with the total system as if it were relational. ASIDE: Nearly every non-relational DBMS system comes with an SQL wrapper. Many other "data processing" languages like FOCUS also provide SQL wrappers.... ASIDE: Make sure that knowledge of SQL appears on your resume. Special cases of the design subsystem are the so called "service subsystems" which generally describe lower level services. These subsystems are different from their analysis phase analogs in that they _need to provide their services in terms of design interfaces _use design classes -often lead directly to executable code. Example: an ATM card reader service. Note from the book...if a service is to be distributed across nodes, it might have to further decomposed in a subsystem for each participating node. Example: If there were a Transaction subsystem distributed among multiple nodes, each node would have to have its own log file. The Interface . Interfaces are used to specify the operations provided from design classes and subsystems. This is essentially the OO concept of encapsulation...separation of functionality from implementation. It is useful to have these interfaces in place and stable early in the design process. Finally, these interfaces effect the architecture since they specify how and with whom the various pieces of the system interact. Note: The importance of specifying interfaces can be seen in examples for the design subsystems. Concentrate on the wrapping of legacy systems...the whole idea of wrapping these systems IS to provide an interface. Example: Look again at the picture of the Ingres Processes. Note that the architecture effects the signature of the Log File and vice-versa. Three processes can access the Log File, one writes, one reads and one can read and write. Ancillary artifacts of the Design Model: the architectural view of the design model. The architectural view of the system consists of the subsystems, their interfaces and the relationships between them ( In fact this could be used to describe what the architecture is ). Example: The Ingres Architecture again. Some classes, especially active classes, may be architecturally significant. Sometimes aggregations of subsystems may be significant. Example: Recovery from failure ( generally referred to as the Logging sub-system ) and Concurrency Control ( generally referred to as the Locking subsystem ) together form the Transaction Management sub-system the deployment model This model describes the physical distribution of the elements of the system. It must describe: the nodes ( processors ) in the system the means of communication between nodes ( internet, intranet...) the components deployed on each node ( i.e. what processes occur there ) the architectural view of the deployment model is its "topology" Workflows.and workers The workflow is seen in Fig 9.16 on p 231 The architect-worker produces the architecture models ( major subsystems and deployment model ). The use-case-worker realizes each use case in terms of the design classes. These use- cases realizations specify the behavioral requirements which allow the component-engineer- worker to specify design classes and subsystems. More specifically The architect...see fig 9.17 is responsible for _configuring nodes and networks. The most common of the possible configurations is the so-called three tier architecture in which clients are distributed around one tier, database functionality ( i.e. transaction processing ) on another and applications on a third. In the classic two-tier or client server architecture, there is no separate applications tier, the applications are distributed among the first of two tiers. Once the nodes are set up, this worker must 1. Provide for the establishment of connections among them, 2. Provide communications protocols, and 3. Provide for nitty-gritty stuff like back-ups and network redundancy . Insure that all the pieces of the design system are compatible with the system architecture and each other. Most major subsystems appear during the analysis phase, others may materialize during the design phase however and as noted, some subsystems are realized by reused software or by wrapping legacy applications. Further, analysis systems may not be an appropriate division of work according to the architecture and/or may not fit the deployment model. and middleware may be required to join the application pieces to the underlying system software. The architect worker is also responsible for making sure that all such is compatible with the chosen architecture. Finally, this worker may construct a dependencies graph to show how all the pieces fit together. The Interbank Software System. Interbank will install its system on 3 server nodes and some number of client nodes. One node for the buyer, one for the seller and one for the bank itself...users connect to the system through client nodes of the Buyer. The nodes communicate through the internet and through TCP/IP see fig 9.18 p234. Many of the subsystems were first identified during the analysis phase, but developers realized that instead of implementing an "Invoice payment subsystem" the system might be more flexible if they developed a generalized "Payment subsystem". The Buyer's Invoice Management subsystem is to be distributed among three nodes and will be decomposed into three subsubsystems: Buyer's User Interface; Payment Request Management and Invoice Management...these modules will be deployed onto a Buyer Client node, the Buyer Server and the Seller server respectively. Several elements of the system may have to function on more that one Operating System ( Win2000 and UNIX ) so they chose to use Java's Abstract Windowing Toolkit and its Remote Message Invocation middleware..the dependencies in the system are shown on p241 and explains everything. 9.5.2 Activity: Creating Design Phase Use Cases The purposes of this activity are to 1. Identify the design classes and/or subsystems which are needed to perform the use- case flow of events 2. Distribute the behavior of the use-case among the design classes or subsystems 3. Define requirements on the operations of the design classes and subsystems 4. Capture implementation requirements for the use case. Specifically: 1.Identifying the Participating Design classes Use the analysis classes that participate in the corresponding use-case analysis phase to identify the classes needed Identify any special requirements for these cases as found by the architect Assign the class to a component engineer If some design class is missing, notify the architect and assign a component engineer. 2. Describing Design Object Interactions. Once we have a collection of design objects it is necessary to specify how these objects interact. This is done by using sequence diagrams containing actors, design classes and message transmissions, the use-case worker describes how the elements interact. The following guidelines apply: Use cases that have more than one flow of control path will probably require more than one sequence diagram. Each use case is invoked by a message from an actor instance to a design object Each design class involved in step 1 above should have at least one design object participating in some sequence diagram. Messages between object ( lifelines ) in a sequence diagram may be given a temporary name which may be used later as the name of an operation. More specialized use case sequence diagrams may have to be embedded in the use case sequence diagram which it specializes. It is possible that the designer will uncover new exceptions as the use-cases unfold. Such things that may have to considered at this level are errors caused network failure, human error or an exception thrown by a piece of middleware. Interbank p252 for the Pay Invoice Use Case 3 Identifying the Participating Subsystems and Interfaces. 4 Describing subsystem Interactions. These steps are not a lot different than paragraphs 1 and 2 , except that the elements are not design classes but subsystems whose actual specification is being delayed for some reason. This might happen if perhaps the details of the user interface were not yet decided. 9.5.3 Activity: Creating Design Phase classes. The component engineer must create a class that fulfills its role in all use-cases in which it participates. The type of information needed to successfully specify a class depends a lot of the role the class will play: Boundary classes are largely dependent on the specific interface technology: VB, Java...Active X etc Persistent classes depend on the procedural model of the database chosen ( object vs relational ) and may depend on the database vendor as well. Control classes may also have to take into account: Distribution issues...does a particular control function need to be realized as separate design classes on different nodes Performance issues. It might be more efficient to incorporate some control functions within boundary classes and/or other classes Transaction issues. Such a class might incorporate existing transaction management technology such as that provided by a DBMS. The worker is responsible for correctly defining the following: 1. The class' operations. The operations must be specified within the syntax and philosophy of the language in use. Information needed to discover a classes' operations include: _The responsibilities of this class in previous models ( e.g. the analysis model ). If inputs and outputs are described, they can form the basis for the formal parameters and result values _Special requirements of this class in previous models ( e.g. the analysis model ). Example: if a class must be persistent it needs to interact with a DBMS. _The interface the class must provide _ The use-cases in which the class must participate. See the continuing example on p258 2. The class' attributes The attribute must be specified within the syntax and philosophy of the language in use. Guideline for discovering a classes attributes ( instance variables ) include _Pay attention to attributes of this class in previous models (e.g. the analysis model). _Try to standardize and reuse attribute types; decide once and for what a data datatype is and use this type in all classes Example: What is the datatype of currency, dates? _If a single attribute instance is shared by many classes, consider putting in a class all of its own. Example: Many classes might have the following attribute definition char * student_id; In this case there probably should be a Student class and all of the attributes of that type would become Student id; _If a design class has LOTS of attributes consider regrouping the attributes to make multiple classes. 3. The class' relationships. Communication between classes often requires that associations between classes be "hardwired". Guidelines for specifying associations: _Associations found in previous models (e.g. the analysis model) will probably be expressed in the design model. _Association constraints ( cardinality, existence dependencies etc. ) have to expressed in the programming language chosen. Some options for this include: Class - Subclass definition to capture generalization Using attributes to capture aggregation or other associations Friend classes Class methods Association Classes The navigability of associations must be considered...one directional messages have to coded differently from bi-directional associations ASIDE: There is a subtle problem with bi-directional associations: inverses. If you have such an association, say from class A < > class B. If you follow the association from object a of class A to object b of class b, and then follow the reverse association out of b, you should wind up at the original a, but this is difficult to insure. Example. There is no intrinsic reason why one Faculty Boyno's advisee's is Student Chen but that Chen's advisor is listed as Faculty Deremer. 4. The class' methods Generally speaking, methods are not finalized in this step, but the designer might provide an desirable algorithm or perhaps high level pseudocode to specify some methods. NOTE: Much like do when write programs, it is desirable to know the names and signatures of the methods...since you should know every classes interface this should be doable. 5. The class' imposed states The action of some classes may be state dependent. That is, its behavior to a particular input might depend on the state that its in when the input arrives. Example: There's a good example from general Transaction processing techniques. A transaction can be in any of several states: active, failed, aborted, committed, ended etc. If the Transaction receives an abort command from the user, if the Tx is finished it merely exits, if , however, its active when the abort is received it has to rollback any changes that it has made before it can exit. A state transition diagram might be helpful in documenting these cases 6. Special Requirements. There a number of other concerns that aren't addressed in the previous steps. _A class may have to be distributed _There may be some additional functional requirements Example: from the book p262, an object of the class PaymentRequestProcessing may be required to handle at least 10 requests simultaneously with degradation of service. 9.5.4 Designing Subsystems Designer must keep in mind: 1. Subsystems should be as independent as possible from other subsystems and their interfaces 2. Subsystems must have the correct interface 3. The subsystem must fulfill its purpose. Further, if, contrary to 1 above, associations exist between the classes that form different subsystems, then some sort of association should exist between the subsystems. If many such associations exist then the subsystem design is probably wrong...redistribute the duties into new subsystems. Example: Imagine in the ATM example, that the designers had created a "Physical Devices" subsystem and a "User Interaction" subsystem. One would find the CardReader class in the "Physical Devices" subsystem and probably, at least some of the classes in the "User Interaction" subsystem would require the services of that class. The subsystems are probably not organized correctly. If "uses" dependencies exist between one subsystem and another which has an interface class, view the dependency as if it were to the interface... that way you could change the subsystem and leave the interface ( and therefore the dependency ) unchanged Example: Again in the ATM, assume that two of the subsystems are: Input Devices and Identity Verification. Clearly Identity Verification uses Input Devices to obtain the users PIN. The interface is really to the class Keypad which is part of Input Devices, so construct the interface correspondingly. Clearly you could modify other classes in Input Devices without effecting this interface. Designers may have to modify both the subsystem interface and contents from the architects original design as the use cases evolve. At all times, there should be a class or subsystem for each of the subsystems interfaces. Finally, you can tell whether or not each class or subsystem is actually needed by documenting how they collaborate. ASIDE: You may find that a class or subsystem is rarely or never used. If that's the case you might just be able to discard it. 3. Implementation The purpose of this step is 1. To plan the incremental implementation of the design in a series of small, manageable steps. 2. To distribute the executables among the component nodes as found in the deployment model 3. To actually implement the classes and subsystems as found in the Design model 4. To test the individual components by compiling and linking them into individual executables. ASIDE: Life lesson. If you break a problem down into small, individual components, you should be able to test each part of the solution as it becomes available. This allows to isolate problems in the exact place where they occur, rather than building a whole application, and trying to find out where an error occurs. The artifacts produced by this step are An implementation model. A set of components An implementation subsystem Interfaces An architectural view of the Implementation model An integration build plan The implementation model "..describes how elements in the design model, such as design classes, are implemented in terms of components such as source code files, executables, and so on. The implementation model also describes how the components are organized according to the structuring and modularization mechanisms available in the implementation environment and programming languages in use, and how the components depend on each other." Specifically Components. A component is a physical realization of some design element. Some common components are: <> ie a program that will run on the node it is assigned to. <> ie source code or data <> a user or vendor supplied set of special purpose programs <> a database table or "file" <> Components clearly must be traced to design elements One component may implement multiple design elements subject to the programming environment and programming language. A component must provide the same interface as the design element it implements There will usually be compilation dependencies among components. ASIDE: "make" is a unix utility that is designed to aid in this process. The idea is to create a file, called a "make file" ( whose default name is "makefile" ) which contains what are called dependencies that say that one file depends on another AND instructions for making the first out of the second. Example ( Java) Library.class : Library.java javac Library.java Example ( C++ ) Library : Library.cxx Library.h cpp Library.cxx -o Library The idea is that if some change occurs to a file on the right side of a dependency, the make utility executes the instruction necessary to "make" the file on the left side up-to-date. The component engineer may provide "stubs" to aid in testing. A stub is a special purpose application whose only purpose to pretend to be some other element. Example: In the library system, one component will probably deal with the assessment of fines and penalties. A stub would be a little program that would the kind of data that would cause this subsystem to come to life and produce the appropriate output. An implementation subsystem is similar to a design subsystem but this time for the purpose of organizing implementation artifacts. It can consist of components, interfaces and other subsystems. The implementation of a such a subsystem depends heavily on the application environment. A "package" in Java, A "module" in C++ and a "component view package" in Rational Rose. Important aspects of implementation subsystems. If dependencies exist among design subsystems, corresponding dependencies must be built into the implementation subsystems. Implementation subsystems should provide the same interfaces as the corresponding design subsystem. Implementation subsystems should provide classes to subsubsystems to provide interfaces Interfaces See above The architectural view of the Implementation model describes the archtecturally significant artifacts of this model. They include: The decomposition of this model into subsystems, their interfaces and their dependencies The architecturally significant components that trace to architecturally significant design elements. An integration build plan Each incremental step in the process is called a "build". Each "build" will be tested and since any particular build may fail, we will implement some method of version control so that unsuccessful builds can be rolled back to previous successful builds. ASIDE on version control: A version control scheme is usually a direct graph whose nodes are labeled. If a particular build fails it MAY have to be necessary to roll back more than one node. End Aside Each integration build plan describes the following for each build: 1. The functionality that is expected to be implemented in each build. This is a list of use cases or supplemental requirements 2. A list of the parts of the implementation model effected by the build. The architect is in overall charge of making sure that the product, as implemented, is correct, ie Does it correctly implement the required functionality, both principle and supplementary and only this functionality? Does the architecture of the implementation match the overall architectural model..ie is the architectural view of the implementation correct? Are the executable components correctly mapped to the network topology? The component engineer defines and maintains the source code for one or more of the file components and/or the implementation of one or more subsystems. He/she must also be sure that all interfaces and dependencies are correct. This worker is also responsible for testing the artifacts that they create and maintain. The System integrator is charged with responsibilities that go the scope of other workers, such as planning the sequence of builds and creating an "integration build plan" Workflows. 1. Identifying architecturally significant components: Identifying Executable Components and mapping them onto nodes. One component should be created for each active class ( authors call this a "heavyweight class". ) This component should also include any other file or library components that might be needed for the successful compiling or execution of this class. If there are any other active other objects that are in this component, that are already mapped to a node, map the rest of this component, then the entire component should be there as well. In the end each component must be assigned to some node. 2, System integration. Planning a sequence of builds. Each successive must add functionality to the previous build by implementing new use cases or refining old ones. Each new build should not include too many new components or refinements, to do this would make it harder to test. Obviously each new build should be based on the previous successful build. The sequence of builds should proceed "upwards" from basis, low level element ( system level stuff or middleware) towards more refined elements. Identifying the use requirements for the use cases to be implemented in the next build: Identify the design of the use case from its design model Identify the classes and subsystems that participate in the use case design Be careful of the impact that subsequent builds have on previous ones. If the new elements interfere with low level system level stuff...and might be better in a later build. The results of all these steps should become part of the "integration build plan" and communicated to the components engineers Integrating a build. Is straightforward...assemble all the components, compile them in the correct sequence. Perform integration and system tests. 3. Implement a subsystem. Ensuring that a system fulfills its role in the build. Maintaining the subsystem contents. "..the requirements to be implemented in the current build and those that affect the subsystem.." must be "..correctly implemented by components within the subsystem". Specifically i. "Each class in the corresponding design subsystem that is required in the current build should be implemented by components in the implementation subsystem" ii."Each interface provided by the corresponding design subsystem that is required for the current build should also be provided by the implementation subsystem.." 4. Implement a class. Has four basic activities i. Outlining file components that will contain source code ii Generating source code from the design classes and their relationships. iii. Implementing class operation using class methods iv. Making sure that the class interfaces are the same as the design class interface. i. Outlining the file components...fairly straightforward, we must decide which classes will go in which component..depends to some degree on the language in use. ii. Generating source code. The structure of a class ought to be an immediate consequence of the design class ( since it was created using the constructs of the actual language ). We must, of course, still implement the operations. There is one place where the design class might not lead directly to an implementation...a classes associations. ASIDE on representing associations in C++. There are two basic ways to do this: 1. As an instance variable: i. A reference to another object ( pointer ) ii A "value" attribute Example: i. To express the relationship between a college class and its instructor, we would include in the "class" class an attribute which is a pointer to a faculty object. A faculty object would probably contain an attribute which is an array of pointers to the classes that the instructor teaches. Example ii. A salesman might require an object called a "schedule". In this case, the salesman class would probably just contain an attribute of type schedule. The choice of these methods largely depends on whether or not the associated object can exist outside of the association. In the example a particular salesman's schedule doesn't continue to exist if that salesman is fired. 2. As an association class. The idea is that the association itself becomes a class. Example. There is an association between students and college classes. You could express this using method 1.i above or you could create a separate class ( called perhaps roster ) an include pointers to this roster object in both student objects and class objects. ASIDE TO THE ASIDE: Using this method you can enforce reciprocity. END INSIDE ASIDE END ASIDE iii. Implementing operations. This requires choosing suitable algorithms ( unless they have already been specified in the design phase ) and appropriate data structures. If a design class has been specified with multiple states, then the implementation must reflect this because the behavior of an object might depend on its states. iv. Providing the class' interface. This simply must be exactly the same as the design class specification. 5. Perform Unit tests. Two kinds of testing: Specification testing ( aka Black Box Testing ). The idea is to test an objects behavior without regard to how it works. Ideally all combinations of possible inputs, object states and outputs would be tested. In real life this is impractical, there are simply too many combinations. ( ATM example: There a theoretically unlimited number of possible states for a customer's account, i.e. the amount of a customer's balance ). A solution to this problem is to use "equivalence classes", i.e. inputs which ought to behave similarly. See books example on p 290...Of all the possible values for a customer's balance, we can find three clear equivalence classes: negative balance ( overdrawn ), zero and positive balance. Similarly, the output from this class can be divided into two equivalence classes: nothing withdrawn and something withdrawn. Performance Structure Tests.( aka White box Testing ). In this type of test component engineer must make sure that the code functions as intended. This includes: i. Make sure that every line executes at least once. ii. Test the most interesting paths through the code: frequently executed paths important paths peculiar cases of algorithms high risk paths. 5. The Test phase. This phase has three purposes: Plan the tests required for each iteration, including both integration tests ( making the iteration work with other components ) and system tests ( making sure that the system can be installed and made to work on the clients platform etc ) Design and implement the tests by creating test cases that specify what to test, test procedures that specify how to perform the tests and creating executable test components to automate the testing. Perform the tests and deal with the results Some test planning may occur early in the process, but the bulk of the testing will take place during elaboration and especially during construction. During transition, we focus on fixing known defects and making sure that all the old parts still work correctly as new parts are added ( regression testing ). The amount of regression testing increases as you approach the end of the software cycle. It clearly makes sense to maintain the test model throughout the entire cycle removing obsolete test cases ( procedures and components ); refining existing test cases so that they can later be used for regression testing and creating new test cases for the next build. Artifacts: 1. The Test Model consists of some number of test cases, test procedures and/or test procedures. 2. A test case specifies a particular way to test the system, including what part of the system to test with what input, and under what conditions. Common kinds of test cases are: a. testing a use case or a scenario that is part of the use case. This kind of test checks out the interactions between actors and the system; that pre- and post-conditions are satified and that the sequence of actions specified by the use case is followed....it is essentially a black-box test. b. testing a use-case realization ( design ) or some scenario of the use case.. This kind of test verifies the interaction of the components that implement the use case....this is essentially white box testing. < See example p 298 > NOTE: a collection of test cases may differ in only a single input or result value. It may be useful to create a "matrix format" i.e. table to organize the results. Some kinds of tests on the system: a. installation tests verify that the system can be installed on the users platform and operates correctly when installed. b. configuration tests verify that the system works correctly in different configurations...single user, client server... c. negative tests which attempt crash the system...this can take the form of improper input, improper network configuration, system overload and insufficient hardware. d. stress tests...test the system when it has insufficient resources ( temp disk space e.g.) or when it must compete for system resources. 3. A test procedure "specifies how to perform one or several test cases or parts of them." It is essentially an algorithm that tells a user how to either manually perform a test case or how to create a test component. Multiple test procedures may be assigned to a single test case and visa-versa, one test procedure may be used for multiple test cases. < See example p300 > Note that in many instances, many test cases may contain repetitive routine operations like "Match Invoice Number to Order Number". Test designers may suggest a general test procedure perhaps called "Validate Business Objects". Test procedures may then activate an object to perform such a general test and report the results 4. A test component "automates one or several test procedures" via a high level language or scripting language. They are sometimes called "test drivers" or "test scripts". 5. The test plan outlines the overall testing strategy including what kinds of tests to perform for each iteration; the objectives of each test; the level and amount of code to be tested and the percentage of tests that should execute with a specific result ( what does success mean ). // Ex. p306 // 75% of tests automated // Each use case will be tested for its normal flow and 3 exceptional cases // Success means that 90% of the test cases will pass and that no defects found in any medium to high // priority use cases will remain unresolved 6. The word "defect" is not used with its usual English meaning. In this context, it means a method of recording events that do not go exactly as expected. A defect may indicate a problem with the system that needs to be tracked and resolved ( either fix the problem or make the defect go away somehow ). 7. A Test Evaluation measures the results of the testing. What percentage of test cases were performed, what percentage of the code was tested and what is the status of the defects. Workers: Test Designer..are in overall charge of the whole process. They Plan the tests Select and describe the test cases and corresponding test procedures Decide on appropriate test goals Make a test Schedule Evaluate the tests after execution. Component Engineer..create the test components that automate those test procedures that can be automated.... Integration Tester performs the tests required for each build...they test to make sure that the components introduced during the build operate correctly with previously built components. They issue any defects found. System Tester performs they system tests required after each build. Again they issue any defects that are found. Work Flows: Test Planning. That is, describe a testing strategy; estimate the system and human resources needed for the testing schedule the tests. Test Design. identify and describe the test cases for each build identify and design the test procedures to be used. More on designing integration test cases. The idea is to design a set of test cases that accomplish the goals of this test phase with a minimum of effort. This usually means starting with the use-cases realizations of the design phase that have been included in this build, and then planning paths through the scenario which illuminate its workings. To the greatest degree possible, test cases should avoid overlap. < Example p307 > More on designing system test cases. The idea here is to test the overall functioning of the system under a variety of conditions like the number of simultaneous transactions and/or different hardware and software configuration. Test designers must pay close attention to use cases that may interfere with each other if performed simultaneously and use cases that involve multiple processes. Further, use cases that make extensive use of system resources like databases or communications software should be examined More on regression testing. Some but not all previously testes are suitable for regression testing. Those tests that are flexible enough to compensate for changes in the system are the best candidates. Often new test cases will have to be developed. Identifying and Structuring Test Processes. As always, everything starts with the use cases. Each use case should produce at least one test case. The art is to design test procedures that are flexible enough that they can be reused in multiple instances. The goal is to produce a small, non-redundant set of test cases. One use case may involve several subsystems. Ideally each test case would test only one of them so such a use case would involve multiple test cases Activities: 1. Implement a test. Starting with a test procedure, we will either produce some sort of test script or actual program to implement the test. It is often helpful to record the results in a spreadsheet especially if the test involves large amounts of input and/or output data. 2. Perform integration test. Done in the following sequence a. Perform the test relevant to this build use an implementation as in step 1. b. Compare the test results to the expected results and investigate any anomalous results c. Report any defects to i. The component engineer whose component is most likely to contain the defect ii. The test designer who will evaluate the overall test. 3. Evaluate the test. Test engineers prepares metrics ( measurements ) that examine i. testing completeness...what percentage have the test cases have been executed and what percentage of the code has been tested. ii. reliability..this requires the testers to analyze trends in defects discovered and in the tests that execute as expected As a result of the evaluation, they may ...if the system reliability is low perform additional tests trying to locate more defects ...if the goals were set so high that the current iteration can't possibly meet, relax the criteria ...if some parts performed well and others did not, isolate the successful components and deliver them as the result of this iteration and attempt to fix the other in the next iteration.