Escolar Documentos
Profissional Documentos
Cultura Documentos
Lab Manual
1
Introduction and Project Definition
Use-Case Diagram
use-case 1 Actor A use-case 2 Actor B
rep Repository (from Persistence) name : char * = 0 readDoc( ) readFile( ) read( ) open( ) create( ) fillFile( ) File GrpFile
Class Diagram
DocumentList File Mgr add( ) delete( ) Document name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( ) read() fill the code.. fetchDoc( ) sortByName( ) FileList fLis t add( ) delete( ) 1
State Diagram
add fi le [ numbe rOffile==MAX ] / flag OFF Openning close file
ad d file
Wri ting
Closin g
read( )
use-case 3
UI
MFC
Class
DocumentList
Deployment Diagram
- 95 : - NT: - - : - -, - - IBM : -, -
DocumentApp
RogueWave
9: sortByName ( )
Repository
Persistence global
Window95
Windows95 Windows95
mainWnd : MainWnd
1: Doc view request ( ) L
FileManager
- .EXE
- Windows NT
gFile : GrpFile
Package Diagram
GraphicFile
Document
- .EXE
Solaris
-.EXE Windows NT
Alpha UNIX
File
FileList
IBM Mainframe
7: readFile ( ) 5: readDoc ( )
repository : Repository
document : Document
Collaboration Diagram
mainWnd user fileMgr : FileMgr document : Document gFile repository
- . 1: Doc view request ( ) 2: fetchDoc( ) 3: create ( ) 4: create ( ) 5: readDoc ( )
Component Diagram
- - .
6: fillDocument ( )
8: fillFile ( ) - - . 9: sortByName ( )
Sequence Diagram
Executable System
Deliverables
Tool
Plan doc
Configuration management tool (Source safe) Management tool (MS project) Requirement documentation tool (RequisitePro) Requirement and design tool (Rational Rose) Microsoft Word Rational Rose Rational Rose Rational Rose
SRS doc
3. CASE Tools No tools are used for this lab. 4. In-Class Example Some examples of problem definition will be presented in the class. 5. Exercises Form groups of 3 students (with one of them as a leader). Brainstorm and list 5 suitable project titles. Present these to the class. Choose one of the projects from your list. Try to write (a hypothetical) project definition for it. Present it to the instructor/class. 6. Deliverables Form teams of 4 students for the term project. Submit their IDs, names, section by email within this week. 4
2
Software Processes and Visual Source Safe
3.1 How Does It Work? In order for Visual Source Safe to manage your documents, you must first check them in to VSS. When you first check a file in to VSS, the program records the contents of this original version. The document then becomes read-only to prevent you from making changes that VSS cannot track. When you want to edit a document that is under source control, you must check the document out of VSS to get a writable copy. When you are finished editing the document, you save the document and then check it back in to VSS. VSS will then contain two "versions" of the document: the original and the new edit. In reality, VSS does not keep two full copies. It keeps the original document, and a small file describing the differences between the original and the edited version. If you edit the document 100 times over the course of a year, you will have access to all 100 versions in VSS, without having to use all of the disk space that 100 copies of the document would occupy. 3.2 Why Is It Useful? VSS lets you view any version of your document, or check out any version for further editing. It also lets you pick any two versions-- say, draft 6 and draft 31-- and compare them with the Diff utility. This comparison shows the two documents side by side, with the differences highlighted and color-coded. VSS also enables you to attach comments to each revision; these comments may or may not appear in the document itself, depending on how you configure the program. But the comments can be viewed independently of the documents themselves. Another very useful feature of VSS is labeling. Labeling provides a simple way of knowing which versions of which documents belong together in a group. VSS was designed for environments in which multiple users are editing the same documents. It permits only one user at a time to edit each document, thereby guaranteeing that only one authoritative "latest version" of a document exists at any given time. 4. In-Class Demo A demonstration will be given show the basic functions of VSS in order to manage your files. These features include: a. Creating a new project. b. Checking files in and out. c. Labeling files. d. Viewing revision history. e. Using Diff to show differences. f. Using Search to find documents. For more information on software processes and VSS tutorial please refer to Lab 2 slides which contain an overview of software processes and VSS tutorial slides. 5. Exercises Create a project and add some java files to it (at least 3 files). Label the existing files. Check out all the files and modify one of them. Check the edited file back in. View the revision history of the edited file and show the differences between the old and the new versions. 8
Search for any unchecked in files. After you perform all of the previous tasks, create a new project for your term project. If any files of your term project are ready, you need to check them in. You need to manage all your term project files using Source Safe. 6. Deliverables You should successfully demonstrate that all the exercise tasks were implemented. Also your VSS project for your term project should be created and any available files should be checked in.
3
Project Planning and Management
10
Risk planning: draw up plans to avoid or minimize the effects of the risk. Risk monitoring: monitor the risks throughout the project. 3. CASE Tools Microsoft Project is the clear market leader among desktop project management applications. Primavera Project Planner: multi-project, multi-user project, and resource planning and scheduling. SureTrak Project Manager: resource planning and control for small-to-medium sized projects. According to the Gartner Group, it accounts for about two-thirds of all project management software sales. MS Project Jump Start Live Demo 4. In-Class Demo Now you will learn how to apply the above mentioned methods to draw a Gantt chart or Activity chart for the project. Please refer to Lab 3 slides which explain the process in detail with some examples. 5. Exercises Use MS Project 2002 to create a series of tasks leading to completion of a project of your choice. For your project, you need to: Set start or ending dates. Develop a list of tasks that need to be completed. Establish any sub tasks and create links. Create any links between major tasks. Assign a specific amount time for each task. Assign resources for each task. Create task information for each item you put into the list. 6. Deliverables You should submit the solutions for the previous exercises. You should use MS Project to create a plan and time schedule for your term project.
12
4
Software Requirement Specification (SRS)
13
2.2 Writing Requirements Requirements always need to be correct, unambiguous, complete, consistent, and testable. 2.2.1 Recommendations When Writing Requirements Never assume: others do now know what you have in mind. Use meaningful words; avoid words like: process, manage, perform, handle, and support. State requirements not features: o Feature: general, tested only for existence. o Requirement: specific, testable, measurable. Avoid: o Conjunctions: ask yourself whether the requirement should it be split into two requirements. o Conditionals: if, else, but, except, although. o Possibilities: may, might, probably, usually.
2.3 Writing Specifications Specification is a description of operations and attributes of a system. It can be a document, set of documents, a database of design information, a prototype, diagrams or any combination of these things. Specifications are different from requirements: specifications are sufficiently complete not only what stakeholders say they want; usually, they have no conflicts; they describe the system as it will be built and resolve any conflicting requirements. Creating specifications is important. However, you may not create specifications if: You are using a very incremental development process (small changes). You are building research or proof of concept projects. You rebuilding very small projects. It is not cheaper or faster than building the product. 2.4 Software Requirement Specification (SRS) Remember that there is no Perfect SRS. However, SRS should be: Correct: each requirement represents something required by the target system. Unambiguous: every requirement in SRS has only one interpretation Complete: everything the target system should do is included in SRS (no sections are marked TBD-to be determined). Verifiable: there exists some finite process with which a person/machine can check that the actual as-built software product meets the requirements. Consistent in behavior and terms. Understandable by customers. Modifiable: changes can be made easily, completely and consistently. Design independent: doesn't imply specific software architecture or algorithm. Concise: shorter is better. Organized: requirements in SRS are easy to locate; related requirements are together.
15
Traceable: each requirement is able to be referenced for later use (by the using paragraph numbers, one requirement in each paragraph, or by using convention for indication requirements)
16
3. CASE Tools RequisitePro is a powerful, easy-to-use requirements management tool that helps teams manage project requirements comprehensively, promotes communication and collaboration among team members, and reduces project risk. It thereby increases the chances of delivering a product that the client wants and does so in a timely manner. RequisitePro offers the power of a database and Microsoft Word and is integrated with other Rational Suite products. 4. In-Class Demo An overview of the basic features of RequisitePro will be presented. In the exercise section you will practice and apply what you have learned in the tutorial. Please refer to lab 4 slides which contain a tutorial on RequisitePro and an overview of the requirements engineering process, and writing requirements and specifications. 5. Exercises a. Are the following requirements vague? If yes, why? Can you fix them? o The feature is responsible for managing connections. o The feature allows users to perform administrative functions. b. Perform each of the following tasks using RequisitePro: o Create a new project. o Create a new package. o Create and add some requirements within RequisitePro. o Create a requirement document. o Create a new view. 6. Deliverables You should submit the solutions for exercise 5.a. You should show that you have successfully performed all the tasks listed in exercise 5.b. Also during the requirement phase of your term project, you should use RequisitePro to manage your requirements.
17
5
Introduction to UML and Use Case Diagram
18
2.5 Actors Are NOT part of the system they represent anyone or anything that must interact with the system. Only input information to the system. Only receive information from the system. Both input to and receive information from the system. Represented in UML as a stickman. 2.6 Use Case A sequence of transactions performed by a system that yields a measurable result of values for a particular actor A use case typically represents a major piece of functionality that is complete from beginning to end. A use case must deliver something of value to an actor. 2.7 Use Case Relationships Between actor and use case. Association / Communication. Arrow can be in either or both directions; arrow indicates who initiates communication. Between use cases (generalization): Uses Where multiple use cases share pieces of same functionality. Extends Optional behavior. Behavior only runs under certain conditions (such as alarm). Several different flows run based on the users selection. 3. CASE Tools The Rational Rose product family is designed to provide the software developer with a complete set of visual modeling tools for development of robust, efficient solutions to real business needs in the client/server, distributed enterprise and real-time systems environments. Rational Rose products share a common universal standard, making modeling accessible to nonprogrammers wanting to model business processes as well as to programmers modeling applications logic. 4. In-Class Example Now you will learn how to apply the above-mentioned methods to draw use case diagrams from the problem statement. Please refer to Lab 5 slides which explain the process in detail with some examples.
20
5. Exercises Read carefully the following problem statement We are after a system that controls a recycling machine for returnable bottles and cans. The machine will allow a customer to return bottles or cans on the same occasion. When the customer returns an item, the system will check what type has been returned. The system will register how many items each customer returns and, when the customer asks for a receipt, the system will print out what he deposited, the value of the returned items and the total return sum that will be paid to the customer. The system is also be used by an operator. The operator wants to know how many items of each type have been returned during the day. At the end of the day, the operator asks for a printout of the total number of items that have been deposited in the machine on that particular day. The operator should also be able to change information in the system, such as the deposit values of the items. If something is amiss, for example if a can gets stuck or if the receipt roll is finished, the operator will be called by a special alarm signal. After reading the above problem statement, find: 1. Actors 2. Use cases with each actor 3. Find extended or uses use cases (if applicable) 4. Finally : draw the main use case diagram: 6. Deliverables You should submit the solutions for the previous exercises. You should use these techniques to draw use case diagrams for your term project using Rational Rose.
21
6
System Modeling
22
23
2.3.1 Entity Relationship Diagram An entity relationship diagram (ERD) is one means of representing the objects and their relationships in the data model for a software product. Entity Relationship diagram notation: Entity
Relationship
To create an ERD you need to: Define objects by underlining all nouns in the written statement of scope: producers/consumers of data, places where data are stored, and composite data items. Define operations by double underlining all active verbs: processes relevant to the application and data transformations. Consider other services that will be required by the objects. Then you need to define the relationship which indicates connectedness: a "fact" that must be "remembered" by the system and cannot be or is not computed or derived mechanically.
2.3.2 Data Flow Diagram A data flow data diagram is one means of representing the functional model of a software product. DFDs do not represent program logic like flowcharts do. Data flow diagram notation: External entity
Process
Data store
24
To create a DFD you need to: Review ERD to isolate data objects and grammatical parse to determine operations. Determine external entities (producers and consumers of data). Create a level 0 DFD Context Diagram (one single process). Balance the flow to maintain data flow continuity. Develop a level 1 DFD; use a 1:5 (approx.) expansion ratio. Data Flow Diagram Guidelines: All icons must be labeled with meaningful names. Always show external entities at level 0. Always label data flow arrows. Do not represent procedural logic. Each bubble is refined until it does just one thing. 3. CASE Tools You can use MS word to create your ERD and DFD since we do not have a license for a case tool that supports these diagrams. 4. In-Class Example Now you will learn how to create ERD and DFD. Please refer to Lab 6 slides which explain the process of creating ERD and DFD with some examples. 5. Exercises a. Create an ERD for an airline reservation system. b. Create a DFD for: i. Student Registration System. ii. (a + b) * ( c + a * d) 6. Deliverables You should submit the solutions for the previous exercises. You should create ERD and DFD for your term project if needed. You also need to check them into Source Safe.
25
7
Documenting Use Cases and Activity Diagrams
26
A sample completed flow of events document for the Select Courses to Teach use case follows. 1. Flow of Events for the Select Courses to Teach Use Case
1.1 Preconditions Create course offerings sub-flow of the maintain course information use case must execute before this use case begins. 1.2 Main Flow This use case begins when the professor logs onto the registration system and enters his/her password. The system verifies that the password is valid (E-1) and prompts the professor to select the current semester or a future semester (E-2). The professor enters the desired semester. The system prompts the Professor to select the desired activity: ADD, DELETE, REVIEW, PRINT, or QUIT. If the activity selected is ADD, the S-1: add a course offering sub-flow is performed. If the activity selected is DELETE, the S-2: delete a course offering sub-flow is performed. If the activity selected is REVIEW, the S-3: review schedule sub-flow is performed. If the activity selected is PRINT, the S-4: print a schedule sub-flow is performed. If the activity selected is QUIT, the use case ends. 1.3 Sub-flows S-1: Add a Course Offering: The system displays the course screen containing a field for a course name and number. The professor enters the name and number of a course (E-3). The system displays the course offerings for the entered course (E-4). The professor selects a course offering. The system links the professor to the selected course offering (E-5). The use case then begins again. S-2: Delete a Course Offering: The system displays the course offering screen containing a field for a course offering name and number. The professor enters the name and number of a course offering (E6). The system removes the link to the professor (E-7). The use case then begins again. S-3: Review a Schedule: The system retrieves (E-8) and displays the following information for all course offerings for which the professor is assigned: course name, course number, course offering number, days of the week, time, and location. When the professor indicates that he or she is through reviewing, the use case begins again. S-4: Print a Schedule The system prints the professor schedule (E-9). The use case begins again.
28
1.4 Alternative Flows E-1: An invalid professor ID number is entered. The user can re-enter a professor ID number or terminate the use case. E-2: An invalid semester is entered. The user can re-enter the semester or terminate the use case. E-3: An invalid course name/number is entered. The user can re-enter a valid name/number combination or terminate the use case. E-4: Course offerings cannot be displayed. The user is informed that this option is not available at the current time. The use case begins again. E-5: A link between the professor and the course offering cannot be created. The information is saved and the system will create the link at a later time. The use case continues. E-6: An invalid course offering name/number is entered. The user can re-enter a valid course offering name/number combination or terminate the use case. E-7: A link between the professor and the course offering cannot be removed. The information is saved and the system will remove the link at a later time. The use case continues. E-8: The system cannot retrieve schedule information. The use case then begins again. E-9: The schedule cannot be printed. The user is informed that this option is not available at the current time. The use case begins again. Use case flow of events documents are entered and maintained in documents external to Rational Rose. The documents are linked to the use case. 2.4 Activity Diagrams Activity diagrams are flow charts that are used to show the workflow of a system. They also: Represent the dynamics of the system. Show the flow of control from activity to activity in the system. Show what activities can be done in parallel, and any alternate paths through the flow. Activity diagrams may be created to represent the flow across use cases or they may be created to represent the flow within a particular use case. Later in the life cycle, activity diagrams may be created to show the workflow for an operation. 2.5 Activity Diagram Notation Activities- performance of some behavior in the workflow. Transition- passing the flow of control from activity to activity. Decision- show where the flow of control branches based on a decision point: o Guard condition is used to determine which path from the decision point is taken. Synchronization-what activities are done concurrently? What activities must be completed before processing may continue (join). 29
3. CASE Tools Rational Rose (introduced in lab 5). 4. In-Class Example Now you will learn how to apply the above mentioned methods to write flow of events and drawing activity diagrams from the use case(s) flow of events. Please refer to Lab 7 slides which explain the process in detail with some examples. 5. Exercises 1. Take two of the use cases from recycling machine problem (Lab 5) and write flow of events for those. You should work in groups of three to solve this problem. 2. Practice activity diagram from the example in PPT (Lab 7) for course catalog creation. 6. Deliverables You should submit the solutions for the previous exercises. You should use these techniques to write flow of events and draw activity diagrams for your term project.
30
8
Object Oriented Analysis: Discovering Classes
31
32
2.4 Discovering Classes Approaches Methods of discovering classes: 2.4.1 Noun Phrase Approach: Examine the requirements and underline each noun. Each noun is a candidate class; divide the list of candidate classes into: Relevant classes: part of the application domain; occur frequently in requirements. Irrelevant classes: outside of application domain Fuzzy classes: unable to be declared relevant with confidence; require additional analysis Common Class Patterns: Derives candidate classes from the classification theory of objects; candidate classes and objects come from one of the following sources: Tangible things: e.g. buildings, cars. Roles: e.g. teachers, students. Events: things that happen at a given date and time, or as steps in an ordered sequence: e.g. landing, request, interrupt. Interactions: e.g. meeting, discussion. Sources, facilities: e.g. departments. Other systems: external systems with which the application interacts. Concept class: a notion shared by a large community. Organization class: a collection or group within the domain. People class: roles people can play. Places class: a physical location relevant to the system. Use Case Driven Method: The scenarios - use cases that are fundamental to the system operation are enumerated. Going over each scenario leads to the identification of the objects, the responsibilities of each object, and how these objects collaborate with other objects. CRC (Class-Responsibility-Collaboration): Used primarily as a brainstorming tool for analysis and design. CRC identifies classes by analyzing how objects collaborate to perform business functions (use cases). A CRC card contains: name of the class, responsibilities of the class and collaborators of the class. Record name of class at the top; record responsibilities down the left-hand side; record other classes (collaborators) that may be required to fulfill each responsibility on the right-hand side. CRC cards are effective at analyzing scenarios; they force you to be concise and clear; they are cheap, portable and readily available. Mixed Approach: A mix of these approaches can be used, one possible scenario is: Use CRC for brainstorming. Identify the initial classes by domain knowledge. Use common class patterns approach to guide the identification of the classes. Use noun phrase approach to add more classes. Use the use case approach to verify the identified classes. 33
2.4.2
2.4.3
2.4.4
2.4.5
2.5 Class Elicitation Guidelines A class should have a single major role. A class should have defined responsibilities (use CRC cards if needed). Classes should be of a manageable size: if a class has too many attributes or operations, consider splitting it. A class should have a well-defined behavior, preferably by implementing a given requirement or an interface. 3. CASE Tools Rational Rose (introduced in lab 7). 4. In-Class Example Now you will learn how to apply the above mentioned methods of finding classes from the problem statement. Please refer to Lab 8 slides which explain the process of finding classes with some examples. 5. Exercises Consider the following requirements for the Video Store system. Identify the candidate classes: The video store keeps in stock an extensive library of current and popular movie titles. A particular movie may be held on video tape or disk. Video tapes are in either "Beta" or "VHS" format. Video disks are in DVD format. Each movie has a particular rental period (expressed in days), with a rental charge to that period. The video store must be able to immediately answer any inquiries about a movie's stock availability and how many tapes and/or disks are available for rental. The current condition of each tape and disk must be known and recorded. The rental charge differs depending on video medium: tape or disk (but it is the same for the two categories of tapes: Beta and VHS). The system should accommodate future video storage formats in addition to VHS tapes, Beta tapes and DVD disks. The employees frequently use a movie code, instead of movie title, to identify the movie. The same movie title may have more than one release by different directors. You may use any (or mix) of the class elicitation methods to find the candidate classes. 6. Deliverables You should submit the solutions for the previous exercises. Also you should use these class elicitation techniques to identify the classes for your term project.
34
9
Interaction Diagrams: Sequence & Collaboration Diagrams
35
36
Long, narrow rectangles can be placed over the lifeline of objects to show when the object is active. These rectangles are called activation lines.
37
2.4 Collaboration Diagrams They are the same as sequence diagrams but without a time axis: Their message arrows are numbered to show the sequence of message sending. They are less complex and less descriptive than sequence diagrams. These diagrams are very useful during design because you can figure out how objects communicate with each other. 2.5 Notes Always keep your diagrams simple. For IF... then ... else scenarios, you may draw separate sequence diagrams for the different branches of the if statement. You may even hide them, (at least during the analysis phase) and document them by the text description accompanying the sequence diagrams. 3. CASE Tools Rational Rose (introduced in lab 5). 4. In-Class Example Now you will learn how to apply the above mentioned methods of drawing sequence and collaboration diagrams from the problem statement. Please refer to Lab 9 slides which explain the process of finding classes with some examples. 5. Exercises We all have used an elevator. The following steps describe the scenario of what happens at the elevator door from outside. 1. The passenger presses the button of either up or down depending on where he wants to go. 2. Then he will see that the button he pressed is illuminated. 3. The elevator is now moving to his floor. 4. When the elevator reached his floor it stops. 5. Now the button which was illuminated now off. 6. The door opens and the passenger enters. 7. The door closes. The objects: 3. Passenger (he is the actor). 4. Floor button (this is the interface class, the actor interacts with this object). 5. Elevator controller (this the control class, which coordinates the activities of the scenario). 6. Elevator (the entity class, which represents the machine itself which moves up and down). 7. Door (another entity class, which represents the door which opens and closes). Draw a sequence diagram for the above scenario. 6. Deliverables You should submit the solutions for the previous exercises. You should use these techniques to create sequence and collaboration diagrams for your term project. 38
10
Software Design:
Software Architecture and ObjectOriented Design
39
system in isolation, to prepare for extension of the system and to facilitate reuse and reusability. 2.4 Describing an Architecture Using UML All UML diagrams can be useful to describe aspects of the architectural model. Four UML diagrams are particularly suitable for architecture modeling: Package diagrams Subsystem diagrams Component diagrams Deployment diagrams 2.5 Specifying Classes Each class is given a name, and then you need to specify: Attributes: initially those that capture interesting object states. Attributes can be public, protected, private or friendly/package. Operations: can be delayed till later analysis stages or even till design. Operations also can be public, protected, private or friendly/package. Object-Relationships: o Associations: denote relationships between classes. o An aggregation: a special case of association denoting a consists of hierarchy. o Composition: a strong form of aggregation where components cannot exist without the aggregate. o Generalization relationships: denote inheritance between classes. This will build the class diagram, which is a graphical representation of the classes (including their attributes and operations) and their relationship with other classes. 3. CASE Tools Rational Rose (introduced in lab 7). 4. In-Class Example Now you will learn how to specify classes attributes, methods and the relationships between the classes. You will use the same classes identified in the examples of lab 8. Please refer to Lab 10 slides which explain the process of finding classes attributes, methods and the relationships between the classes as well as creating UML class diagrams with some examples. 5. Exercises Refer to Lab 8 exercises; assume that the Video Store needs to know if a video tape is a brand new tape or it was already taped over (this can be captured by an attribute is_taped_over); assume also that the storage capacity of a video disk allows holding multiple versions of the same movie, each in a different language or with different endings. Use the identified classes from Lab 8 and find their attributes, operations and the relationships between the classes (build the UML diagram).
41
6. Deliverables You should submit the solutions for the previous exercises. Also you should use specifying class attributes, methods and the relationship with other classes you learned in your term project.
42
11
State Transition Diagram
State Transition Diagram
43
The operations associated with the state are listed in the lowest compartment of the state box. In the operations part, we usually use one of the following reserved words: o Entry: a specific action performed on the entry to the state. o Do: an ongoing action performed while in the state. o On: a specific action performed while in the state. o Exit: a specific action performed on exiting the state. There are two special states added to the state transition diagram- start state and end state. Notation of start state is a solid black circle and for the end state a bulls eye is used.
2.3 State Transition Details A state transition may have an action and/or guard condition associated with it and it may also trigger an event. An action is the behavior that occurs when the state transition occurs. An event is a message that is sent to another object in the system. A guard condition is a Boolean expression of attribute values that allows a state transition only if the condition is true. Both actions and guards are behaviors of the object and typically become operations. Also they are usually private operations (used by the object itself) Actions that accompany all state transitions into a state may be placed as an entry action within the state. Actions that accompany all state transitions out of a state may be placed as exit actions within the state A behavior that occurs within the state is called an activity. An activity starts when the state is entered and either completes or is interrupted by an outgoing state transition. A behavior may be an action, or it may be an event sent to another object. This behavior is mapped to operations on the object. State transition diagram notation: State [entry:] [do: ] [exit:] Event causing transition Action that occurs New State [entry:] [do: ] [exit:]
45
3. CASE Tools Rational Rose (introduced in Lab 5). 4. In-Class Example Now you will learn how to apply the above mentioned methods of drawing state transition diagrams (STD). Please refer to Lab 11 slides which explain the process of finding dynamic classes and creating STD with some examples. 5. Exercises Here is what happens in a microwave oven: 1. The oven is initially in an idle state with door open, where the light is turned on. 2. When the door is closed it is now in idle with door closed, but the light is turned off. 3. If a button is pressed, then it moves to initial cooking stage, where the timer is set and lights are on, and heating starts 4. At any moment the door may be opened, the cooking is interrupted, the timer is cleared, and heating stops. 5. Also while cooking, another button can be pushed and extended cooking state starts, where the timer gets more minutes. At any moment door can be opened here also. 6. If the time times out, then cooking is complete, heating stops, lights are off, and it sounds a beep. 7. When the door is open, again the oven is in idle state with the door open. Draw a state transition diagram for the microwave oven. 6. Deliverables You should submit the solutions for the previous exercises. You should use these techniques to create state transition diagrams for your term project.
46
12
Implementation Diagrams:
Component & Deployment Diagrams
47
48
2.4.1 Deployment Diagrams: Processor A processor is a hardware component capable of executing programs. A processor is given a name and you should specify the processes that will run on that processor. You can also specify the scheduling of these processes on that processor. Types of scheduling are: o Pre-emptive: a higher priority process may take the process from lower priority one. o Non-preemptive: a process will own the processor until it finishes o Cyclic: control passes from one process to another. o Executive: an algorithm controls the scheduling of the processes o Manual: scheduling buy the user. 2.4.2 Deployment Diagrams: Device A device is a hardware component with no computing power. Each device must have a name. Device names can be generic, such as modem or terminal. 2.4.3 Deployment diagrams: Connection A connection represents some type of hardware coupling between two entities. An entity is either a processor or a device. The hardware coupling can be direct, such as an RS232 cable, or indirect, such as satellite-to-ground communication. Connections are usually bi-directional. 3. CASE Tools Rational Rose (introduced in Lab 5). 4. In-Class Example Now you will learn how to apply the above mentioned methods of creating component and deployment diagrams. Please refer to Lab 12 slides which explain the process of creating implementation diagrams with some examples. 5. Exercises Think about any system and its components and draw deployment and component diagrams. 6. Deliverables You should submit the solutions for the previous exercises. You should use these techniques to create component and deployment diagrams for your term project.
49
13
Software Testing
50
51
3.1 JUnit Terminology A unit test: is a test of a single class. A test case: tests the response of a single method to a particular set of inputs. A test suite: is a collection of test cases. A test runner: is software that runs tests and reports results. A test fixture: sets up the data (both objects and primitives) that are needed to run tests. For example if you are testing code that updates an employee record, you need an employee record to test it on. 3.2 How JUnit Works Define a subclass of TestCase. Override the setUp() & tearDown() methods. Define one or more public testXXX()methods o Exercise the object(s) under test. o Asserts the expected results. Define a static suite() factory method o Create a TestSuite containing all the tests. Optionally define main() to run the TestCase in batch mode. 4. In-Class Demo A tutorial on how to use JUnit with some example will be presented. Please refer to Lab 13 slides for an overview of software testing and JUnit tutorial with some examples. 5. Exercises Write a JUnit test class for testing
public class Exercise { /** Return the minimum of x and y. */ public static int min(int x, int y) { ... } }
6. Deliverables You should submit the solutions for the previous exercise. Also, if you are building your project using Java, you should use JUnit for testing.
52