You are on page 1of 15

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase

The analysis phase of the project includes the initial conception, investigation of alternatives, planning, and specification of requirements. 1. The Activities of the Analysis phase The activities occurred in this phase are: 1. 2. 3. 4. 5. 6. 7. 8. Define a Plan that includes descriptions of the schedule, resources, and budget. Creates an Investigation Report that specifies the motivation, alternatives, and business needs. Define the requirements and produce a Requirements Specification, which contains a formal statement of the requirements. Create a Glossary. The Glossary is a dictionary of terms (concept names such as use-cases, classes, attributes, and so on) and associated information such as constraints and rules. Define Use-Cases and create Use-Case Diagrams. Use-Cases are descriptions of the system usage. Use-Case Diagrams are illustrations of use-cases and their relationships. Define the conceptual model by creating class diagrams. Define Sequence Models which shows the sequence of messages between classes. Define Operation Contracts which describes each operation in detail (name, input, output, class belongs to, etc.)

Order of the Activities in the Analysis Phase Although the listing of the activities above suggest a linear order of performing the activities and creating the models, that is not strictly the case. Some artifacts may be made in parallel such as in the case of creating the conceptual model, glossary, use-case, and use-case diagrams. While the use-cases are explored, the other models such as the conceptual model can be developed to reflect the information in the use-cases. Create the conceptual model and the glossary in parallel.

Choosing When to Create Models Certain models such as the Use-Case Model and the Conceptual Model may be created during the early stage of the analysis phase. Modeling Systems A large software system is usually overwhelmingly complex, so it is necessary to decompose it into understandable parts in order to manage the complexity. These parts may be represented as models, which describe and abstract essential aspects of the system. A useful step in building a software system is to first create models which organize and communicate the important details of the real world problem that is related to and of the system to be built. These models should contain consistent and strongly related elements. UML stands for Unified Modeling Language because it is a language intended to describe models of systems based on object concepts. There different types of models categorized by the phase the occurred in: Analysis Models are related to an investigation of the domain and problem space, but not of the solution. Design Models are related to the logical solution.

Lamya Aljasmi Handout #8

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase


2. Case Study (1) Library System 2.1 Understanding the Requirements Requirements are description of needs for a product. The primary goal of the requirements phase is to identify and document what is really needed, in a form that clearly communicates to the client and to development team members. The challenge is to define the requirements unambiguously, so that the risks are identified and there are no surprises when the product is finally delivered. The following documents are important in the requirements phase: Statement of the problem: this document is prepared by the customer of the system, possibly with the help of the developer, states the requirements of the system as perceived at the time of conception. It is difficulty to anticipate all needs and it is possible that some features are missing or wrong. These deficiencies may not be revealed until the system is delivered. One way of overcoming this problem is to build a prototype, assuming that this can be done cheaper and quicker than the final system. One approach is to produce a description of the real world in which the system is to operate. This helps to ensure that all important aspects are taken into consideration. Key words are underlined Requirements Specification

2.2 Statement of the Problem Safe Marina Rentals (SMR) is a small business that rents diving equipment and boats. The customers have been extremely pleased with their diving equipment and boats. However, the business has not been able to handle the growth. The manager realizes that new business procedures and controls have to be established. He thinks a computer system is probably needed so he decided to ask a consulting firm to help him develop one. The consultants suggest using object-oriented development focusing on the rental operations. The customers can rent diving equipment and boats from SMR. Each renting item has an Id, name, description, and rental price. Diving equipments have manufacturing date and expiry date. SMR needs to know about each customer his name, address, and phone. In addition, customer should have diving license. The diving license includes id, name of the holder and the date. When the customers have seen what is available and made a decision about what to rent, a rental agreement is produced and signed. The system supports the rental operations on diving equipment and boats. These operations include: Display available items, Rent an item, Return an item, Add new renting item, and Discard a damaged or old renting item. The rental desk manager is responsible for communicating with the customers to complete the renting and returning operations. For making any rental agreement for renting equipment, its important to specify the agreement date, number of days and the rent. The rent will be calculated by multiplying the equipment rent price with number of days rented. The customer should pay the rent in advance using cash or credit card. During the return of a rented item, if there is any damage in the rented item, the rental desk manger update the system with this information and ask the customer to pay a fine fee. The service manager is responsible for generating and sending reminder letters to all customers with over due items, adding new equipment or discarded damaged ones.

2.3 Key Words are Underlined Safe Marina Rentals (SMR) is a small business that rents diving equipment and boats. The customers have been extremely pleased with their diving equipment and boats. However, the business has not been able to handle the growth. The manager realizes that new business procedures and controls have to be established. He thinks a computer system is probably needed so he decided to ask a consulting firm to help him develop one. The consultants suggest using object-oriented development focusing on the rental operations. The customers can rent diving equipment and boats from SMR. Each renting item has an Id, name, description, and rental price. Diving equipments have manufacturing date and expiry date. SMR needs to know about each customer his name, address, and phone. In addition, customer should have diving license. The diving license includes id, name of the holder and the date. When the customers have seen what is available and made a decision about what to rent, a rental agreement is produced and signed. The system supports the Lamya Aljasmi Handout #8 2

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase


rental operations on diving equipment and boats. These operations include: Display available items, Rent an item, Return an item, Add new renting item, and Discard a damaged or old renting item. The rental desk manager is responsible for communicating with the customers to complete the renting and returning operations. For making any rental agreement for renting equipment, its important to specify the agreement date, number of days and the rent. The rent will be calculated by multiplying the equipment rent price with number of days rented. The customer should pay the rent in advance using cash or credit card. During the return of a rented item, if there is any damage in the rented item, the rental desk manger update the system with this information and ask the customer to pay a fine fee. The service manager is responsible for adding new equipment or discarded damaged ones. 3. Requirements Specification Includes purpose, customers, goals, and the system functions. There are three categories of the system functions: Evident : should perform and the user should know that it is performed. Hidden : should perform but not visible to the users. This is true of many underlying technical services, such as save information in a persistent storage mechanism. Requirement Specification of the Marina Rentals System Purpose: Develop a model of a software system to manage the Marina's operations of renting diving equipment and boats. Customers: Safe Marina Rentals Company. Goal: Develop a computerized system that will automate the renting and return operations. It should also handle the growth and reliability of the business by establishing new procedures and controls. System Functions 1. Check the availability of an item to be rented. 2. Allow customers to rent diving equipment and boats if available. 3. Produce a rental agreement for each renting operation. 4. Store the equipment, boats, rental agreements and customers information. 5. Allow customers to return their rentals. 6. Calculate the renting fees by multiplying the equipment rent price with the number of days rented. 7. Handle rent payments. 8. Check for late fees and calculate it if customer exceeds the rental period. 9. Check for any damage in the rented items and calculate the fine fee. 10. The service manger starts up the system. 11. The service manager should be able to add new equipment and discard damaged ones using this system. 12. The desk manager interacts with the system to finish renting, returning and paying operations.

4. Use-Cases: Describing Processes 4.1 Use-Cases A use case is a narrative document that describes the sequence of events of an actor (an external agent or user) using a system to complete a process. Use-cases illustrate the requirements and functions of the system. Figure 1 shows the UML icon for a use-case. Example of a Use-Case : Rent Rent items Figure 1 The UML Icon for a Use-Case Use-case: Rent an item Actors: Customer, deskManager Description: Customer will ask a desk manager to rent an Item. Before going on in the renting process, the desk manger will check the availability of the requested item. If the item is available the disk manger Lamya Aljasmi Handout #8 3

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase


will enter customer name and will check for late fees. If there is no late fees, he will enter number of days and cost of renting will be calculated. Those data will be included in a rental agreement produced by the system. Each renting process will produce an agreement for all rented items at the time since the customer can rent many items, but each item can have different renting price. After producing the rental agreement, the customer must pay in advance. Cross References:

Example of a Use-Case : Return

Return items Figure 2 The UML Icon for a Use-Case

Use-Case: Return Rented items Actors: Customer, DeskManager Description: Customer will ask a desk manager to return a rented item. Then, the desk manger will ask for customers name and will check the due date. If due date is not exceeded, item will be returned and will be available for renting where customer information and item information will be updated. Otherwise, he will inform the customer with the late fees. Cross References: 4.2 Actors An actor is an entity external to the system who participates in the story of the use case. An actor stimulates the system with input events, or receives something from it. Actors are represented by the role they play in the use case, such as Aircraft, Control Tower.

Customer Figure 3 The UML Icon for a Use-Case Actor For a use-case, there is one initiator actor who generates the starting stimulus, and possibly several other participating actors; it may be useful to indicate who the initiator is. Actors are usually the roles that humans play, but be any kind of system, such as an external computerized system. Kinds of actors include: Roles that people play Computer systems Electrical or mechanical devices. A Common Mistake with Use Cases A common error in identifying use cases is to represent individual steps, operations, or transactions as use-cases. For example in the ATC system one might inappropriately define a use-case called "check the take-off queue" when it is only a step in much larger use-case take-off. Identifying Use-Cases Each of the following steps for identifying use cases involves brainstorming and reviewing existing requirement specification documents. One method used to identify use-cases is actor-based: 1. 2. Identify the actors related to a system or organization. For each actor, identify the processes they initiate or participate in.

Lamya Aljasmi Handout #8

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase


A second method to identify use-cases is event-based: 1. Identify the external events that a system must respond to. 2. Relate the events to actors and use cases.

Use-Cases, Requirement Statement, and Traceability The system functions identified during the prior requirements specifications should be allocated to use-cases. It should be possible to via the cross references section of the use case to verify that all functions have been allocated. This provides an important link in terms of traceability between models. The system functions and use cases should be traceable through to implementation and testing. 5. Use-Case Diagrams A Use-Case Diagram illustrates a set of use cases for a system, the actors, and relations between the actors and use cases. The purpose of the diagram is to quickly understand the external actors of a system and the way in which it is used. Rent items

Return items DeskManager Customer

Figure 4 The Renting Use-Case Model

addNewItem

discardItem

startUp

ServiceManager

Figure 5 The Service Manager Use-Case Model

6. Conceptual Model A Conceptual Model illustrates meaningful concepts in the problem domain. It is developed from the requirement specifications and the use-cases by finding the concepts in the problem domain and the relations between them. In the UML a conceptual model is illustrated with a set of Class Diagrams in which no operations are defined. It shows: Classes which represents the concepts. Attributes of classes. 5

Lamya Aljasmi Handout #8

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase


Relationships between classes, which are association, inheritance, and aggregation. Cardinalities and the roles within the relationships.

Benefits of the Conceptual Model A critical quality about a conceptual model is that it is a representation of real-world things, not of software components. Decompose the problem domain into manageable units (concepts or classes) to reduce the complexity of the software development. Creating a conceptual model aids in clarifying the terminology or vocabulary of the problem domain.

The Conceptual Model are not Models of Software Designs A conceptual model is a description of things in real world problem domain, not of software design, such as Java or C++ class. Therefore, the following elements are not suitable in a conceptual model: No software components such as a window or database, unless the domain being modeled is of software concepts, such as a model of graphical user interface. No methods When to Create the Conceptual Model? The conceptual model is a representation of concepts or objects in the problem domain, such as Book and Library. The amount of effort applied to the creation of a draft conceptual model during the analysis phase needs to be tempered. The goal is to obtain a basic understanding of the vocabulary and concepts used in the requirements. Therefore, a fine grained investigation is not called for, and runs the very real risk of front loading the investigation of too much that is complexity overload. In large problem domains, such as a system of air-line reservations, a through conceptual model is overwhelmingly complex. The Middle-Ground Strategy The recommended middle-ground strategy is to quickly create a rough conceptual model where the emphasis is on finding obvious concepts expressed in the requirements while deferring a deep investigation. Later within each development cycle, the conceptual model in incrementally refined and extended for the requirements under consideration within that cycle.

A Strategy to Find Concepts in the Problem Domain A useful guideline in identifying concepts: it is better to over-specify a conceptual model with lots of fine-grained concepts than to under-specify it. A strategy for identifying the concepts is:

Finding Concepts with Noun Phrase Identification Identify the noun and noun phrases in textual descriptions such as the statement of the problem and consider them as candidate concepts or attributes. Care must be applied; a mechanical noun-to-concept mapping is not possible, and words in natural languages are ambiguous. Then record them in a Concept Category List. A Concept Category List The following Concept Category List shows the Candidate Concepts for the Air Traffic Control System. Concept Category Staff Class Customer Class Item Class id Attribute of item and customer available Attribute of Item

Lamya Aljasmi Handout #8

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase


address Boat DivingEquipment Agreement BoatSpecification DivingEquipSpec ItemList price RentDate RentDuration Return Date Attribute of Customer Class Class Class Class Class Class Attribute of ItemSpecific Attribute of Agreement Attribute of Agreement Attribute of Agreement

How to Make a Conceptual Model? Apply the following steps to create a conceptual model. 1. List the candidate concepts using the Noun Phrase Identification and the concept category list related to the current requirements under consideration. 2. Draw them in class diagrams. 3. Add attributes necessary to fulfill the information requirements. 4. Add relationships such as associations, aggregations, and inheritance. 5. Add Cardinalities and the roles within the relationships. Guides On Naming and Modeling Things Use the existing names in the problem domain. Exclude irrelevant features. Do not add things that are not there.

1. Adding Classes A Common Mistake in Identifying Classes The most common mistake when creating a conceptual model is to represent something as an attribute when it should be a class. A rule to help in preventing this mistake is: If we do not think of some concept X as a number or text in the real world, X is probably a class, not an attribute. If in doubt, make it a separate concept. Example Consider the domain of the ATC system. Should destination be attribute of Flight or a separate concept Airport?
Flight destination Flight Airport name

Or?

Figure 6 Do not use Concepts as attributes 2. Adding Attributes Consider the following while adding attributes: Keep attributes simple or pure data values: very common simple attribute types include: boolean, number, string, date, time, address, color, geometrics (point, rectangle, ..), phone number. No attributes as Foreign keys: attributes should not be used to relate concepts in the conceptual model. The most common violation of this principle is to add a kind of foreign key attribute, as it is done in relational database design. 7

Lamya Aljasmi Handout #8

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase


3. Adding Associations Consider the following while adding associations in a conceptual model: Focus on those associations for which knowledge of the relationship needs to be preserved for some duration ("need-to-know" associations). Avoid showing redundant or derivable associations. 4. Adding Aggregations Here are aggregations that are useful to be included in the conceptual model: A is a physical or logical part of B. A is physically or logically contained in/on B. 5. Adding Inheritance 6. Recording Terms in the Glossary Glossary or data dictionary is a simple document that defines all the terms that require clarification in order to improve communication and reduce the risk of misunderstanding. There is no official format of a glossary. Here is a sample: Term Rent Items Item Customer rents Category Use-Case Class Class Association relationship Comments Description of the rent operation done by a customer

Between Customer and Item

7. Specification or Description Concept Assume the following: An Item instance represents a physical item in a store, it may even have a serial number. An item has a description, price, and UPC which are not recorded anywhere else. Every time a real physical item is sold, a corresponding software instance of Item is deleted from software land. With these assumptions, what happen in the following scenario? There is strong demand for the popular new chocolate bar ObjectChocolateBar. The store sells out, implying that all Item instances of ObjectChocolateBar are deleted from computer memory. Now: here is the heart of the problem: if someone asks, How much do ObjectChocolateBar cost?, no one can answer, because the memory of their price was attached to inventoried instances, which were deleted as they were sold. In addition, the current model, if implemented in software as described, has duplicate data and is space inefficient, because the description, price, and UPC are duplicated for every Item instance of the same product.

The Need for Specifications The preceding problem illustrates the need for a concept of objects that are specifications or descriptions of other things. To solve the Item problem, what is needed is a ProductSpecification or ItemSpecification or ItemDescription concept that records information about items. A ProductSpecification does not represent an Item, it represents a description of information about items. Note that even if all inventoried items are sold and their corresponding Item software instances are deleted, the ProductSpecification still remain. Description or specification objects are strongly related to the things they describe. In a conceptual model, it is common to state that an Xspecification Describes an X.

Lamya Aljasmi Handout #8

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase


Instead of Item description price serial number UPC Use ProductSpecification description price serial number UPC 1 describes * Item serial number

When are Specification Concepts Required? The following guideline suggests when to use specifications. Add a specification or description concept when: Deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, due to the incorrect association of information with the deleted thing. It reduces redundant or duplicated information.

Figure 7 Item Class Diagram

Lamya Aljasmi Handout #8

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase

Figure 8 SMR Diagram

Lamya Aljasmi Handout #8

10

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase

System Behaviour
System behaviour is a description of what a system does, without explaining how it does it. This description can be done by developing system sequence diagrams and contracts. 8. System Sequence Diagrams A System Sequence Diagram illustrates events from actors to systems. The creation of system sequence diagrams occurs during the analysis phase of a development cycle. Their creation is dependent on the prior development of the use cases. A system sequence diagram shows for a particular course of events occurred within a use-case, the external actors that interact directly with the system, the system, and the system events that the actors generate. Time proceeds downwards, and the ordering of events should follow their order in the use-case. System events may include parameters.

Figure 9

Borrow System Sequence Diagram

A system event is an external input event generated by an actor to a system. An event initiates a responding operation. A system operation is an operation of the system that executes in response to a system event. How to make a sequence diagram To make sequence diagram for the typical course of events for a use-case: 1. Draw a line representing the system as a black box. 2. Identify each actor that directly operates on the system. Draw a line for each such actor. 3. From the use-case, identify the system events that each actor generates. Illustrate them on the diagram.

Lamya Aljasmi Handout #8

11

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase

Figure 10

Return System Sequence Diagram

Figure 11

Add new Item System Sequence Diagram

Lamya Aljasmi Handout #8

12

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase


9. Contracts A Contract is a document that describes what an operation commits to achieve. Its creation is dependent on the prior development of the conceptual models and sequence diagrams. A contract can be written for an individual system operation. It describes the changes in the state of the overall system when a system operation is invoked. Contract Sections A description of each section in a contract is shown in the following schema. Not all sections are necessary, although the Responsibilities and Post-conditions sections are recommended. Contract Name: Name of operation, and parameters Responsibilities: Type: Cross References: Notes: Exceptions: Output: Pre-conditions: Post-conditions: An informal description of the responsibilities this operation must fulfill. Name of type(class, interface) Requirement Specification number, use-case, class, etc. Design notes, algorithms, and so on. Exceptional cases messages or records that are sent outside of the system Assumptions about the state of the system before execution of the operation. The state of the system after completion of the operation. Discussed in detail in a subsequent section.

How to Make a Contract Apply the following advice to create contracts: To make contracts for each use-case: 1. Identify the system operation from the system sequence diagrams. 2. For each system operation, construct a contract. 3. Start by writing the Responsibilities section, informally describing the purpose of the operation. 4. Then complete the other sections. 5. To describe the post-conditions, use the following categories: Instance creation or deletion., Attribute modification, Association formed and broken. Post-conditions are Related to the Conceptual Model The post-conditions are expressed in the context of the conceptual model. What instances can be created? Those from the conceptual model. What associations can be formed? Those in the conceptual model. It is common during the creation of the contracts that you will discover the need to record new concepts, attributes, or associations in the conceptual model. Do not be limited to the prior definition of the conceptual model; enhance it as you make new discoveries while thinking through the operation contracts.

RentItem Contract Name: Responsibilities: Type: Cross References:


Lamya Aljasmi Handout #8

rentItem() it will create renting object to enable renting SMR System Rent Sequence Diagram, Rent use-case
13

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase Notes: Exception: Output: Pre-conditions: Post-conditions: create(itemL, CustL, agrL), rent()

Create Contract Name: Responsibilities: Type: Cross References: create(itemL, CustL, agrL, cat) Create an object of type rent Renting Rent Sequence Diagram, Rent use-case, RentItem Contract Notes: Exception: Output: Pre-conditions: Post-conditions: -

Lamya Aljasmi Handout #8

14

ITCS 341: Object Oriented Systems 2007-2008 I The Analysis Phase Rent Contract Name: Responsibilities: Type: Cross References: Notes: Exception: Output: Pre-conditions: Post-conditions: rent() rent an item Renting Rent Sequence Diagram, Rent use-case, RentItem Contract produce rent agreement The item to be rented must be available getItem(), getItemSp (type), itemAvailable(itemsp), getCustomer(name), checkLateFees(), pay(),geRentaltPrice(),createAgreement(item, cust, price, no-days), addAgreement(agr), doRent(), addItemToRentedList(item).

Lamya Aljasmi Handout #8

15

You might also like