requirements analysis overview fundamentals of object technology (ooa/d) cmpe 104 lesson 4

Requirements Analysis

Overview FUNDAMENTALS OF OBJECT

TECHNOLOGY (OOA/D)

CmpE 104 Lesson 4

Topics Fundamentals of Object Technology

• Instance object

• Class

• Association

• Aggregation and Composition

• Generalization

• Class Object

Guided Tutorial in Analysis Modeling

(ref. separate set of slides)

Problem Statements for Case Studies

Fundamentals of OT

Object has

• State

• Behavior

• Identity

Objects and natural systems

Underprintings of Requirements Analysis

•The emphasis in this book is on object-oriented software production. This does Not come cheaply as the object-oriented development demands a good understanding of object technology. •There is not a top-down or bottom-up learning approach that we know of. •This chapter aims at gauging the right level of information to provide to the reader before diving into the subject. This chapter covers the prerequisites for requirements analysis in two parallel ways. Firstly, we explain the fundamentals of object technology. Secondly, we ‘teach-by-example’ and provide a guided tutorial in analysis modeling using a familiar application domain – OnLine Shopping via the Internet.

I. Instance object

Class

Instance object

Class object

c1: Course

course_number = COMP227course_name = Requirements Analysis and System Design

•A generic description of a ‘thing’ is called a class. Hence, an object is an instance of a class. But, as we will see in section2.1.6, a class itself may also need to be instantiated – it may be an object. For this reason, we need to distinguish between an instance object and a class object.

•A class is a template for objects with the same attributes and operations, but a class itself can be instantiated as an object

I. Instance Object:How objects collaborate?

•For example, to order products a collaboration may need to be established between a Stock object and a Purchase object.

•System tasks are performed by sets of objects that invoke operations (behavior) on each other. We say that they exchange messages. The messages trigger operations on objects that can result in the change of objects’ states and can invoke other operations.

•The brackets after the message names indicate that a message can take parameters. The object Order requests the object Shipment to ship the order. To do so, Shipment instructs the object Stock to subtract an appropriate quantity of products. The object Stock is then analyzing the new inventory levels and if the stock is low, it requests the object Purchase to record more products.

•Even numbered the messages, in general the flow of messages does not impose a strict temporal order on the activation of objects. For these reasons, we shall abandon the numbering of messages when discussing the object collaboration at the design level (Section 6.2)

How do objects collaborate?

I. Instance Object: How objects identify each other?

OID

OID links

Object longevity

• Persistent object

• Transient object

Object communication via

• Persistent OIDs

• Transient OIDs

•The question is how an object knows the identity of another object to which it wants to send a message.

•The answer is that each object is given an object identifier (OID) when it is created. The OID is an object handle – a unique number that remains with the object for its entire life.

•There are two practical solutions to establishing OID links between objects. The solutions involve:

Persistent OID links; and

Transient OID links.

•They are created by the program and destroyed during the program execution or when the program finishes its execution. Transient objects Other objects outlive the execution of the program – they are sorted in the persistent disk storage when the program finishes and they are available for the next execution of the program. These are persistent objects.

I. Instance Object:Persistent link implementation

c1: Course

course_number = COMP227course_name = Requirements Analysis and System Designteacher: identity = Ref@#$%

Ref&*)(

•A persistent link one object in persistent storage that links that object to another object in persistent storage.

•The OID of object c1 is marked here as Ref*)(. The object contains a link attribute named teacher. The type of this attribute is identity. Its value is a magic number Ref@#$% - the disk address where the object Teacher is persistently stored.

•Figure 2.3 illustrates how persistence links are typically implemented. However, in the UML modeling, the links between objects are drawn as in Figure 2.4. The links are represented as instances of an association between the objects Course and Teacher.

•For example, a message sent by an object Teacher to find the name of an object Course could look like:

Crs_ref.getCourseName(out crs_name)

•In the example, the specific object of class Course that will execute getCourseName is pointed to by the current value of the link variable crs_ref.

mailto:Ref@%23$%25

I. Instance Object:Persistent links in UML

c1: Course

course_number = COMP227course_name = Requirements Analysis and System Design

t1: Teacher

teacher

course

c2: Course

course

teacher

I. Instance Object:Transient link

How does an object know the OID of another

object if there is no persistent link?

• Search on the database

• A “map” object

• Creating a new object

Pointer swizzling

II. Class

Class name

Attributes

Operations()

•A class is the description for a set of objects with the same attributes and operations. It serves as a template for object creation. Each object created from the template contains the attribute values that conform to attribute types defined in the class.

•Three compartments

The top compartment holds the class name. The middle compartment declares all attributes for the class. The bottom compartment contains definitions of operations.

II. Class:Attribute

Order

order_number : Integerorder_date : Dateorder_value : Currency

Course

course_number : Stringcourse_name : String

•An attribute is the type-value pair. Classes define attribute types. Objects contain attribute values

II. Class:Attribute type designating a class

Shipment

shipOrder()

Order

order_number : Integerorder_date : Dateorder_value : Currency the_shipment

the_order

Shipment

the_order : Order

shipOrder()

Order

order_number : Integerorder_date : Dateorder_value : Currencythe_shipment : Shipment

•An attribute type can also designate a class. Particular object of the class, such an attribute contains an object identifier (OID) value pointing to an object of another class. In UML analysis models, attributes with class-based types (rather than primitive types) are not listed in the middle class compartment. Instead, the associations between classes represent them.

•The two names on the association line (the_shipment and the_order) represent so called rolenames. A rolename identifies the meaning for the association end and it is used to navigate to an object of the other class in the association.

II. Class:Attribute visibility

Purchase

purchase_number : Stringpurchase_date : Datepurchase_value : Currency

reorderProducts()

•In a pure object-oriented system most operations are public but most attributes are private. Attribute values are hidden from other classes. Objects of one class can only request the services (operations) published in the public interface of another class. They are not allowed to directly manipulate other objects attributes.

•We say that operations encapsulate attributes. One object cannot hide (encapsulate) anything from another object of the same class.

+ for public visibility;

- for private visibility.

II. Class:Operation

Order Shipment

shipOrder()

Stock

subtractProducts()analyzeStockLevels()

Purchase

reorderProducts()

•An operation (or the method, to be precise) is invoked by a message sent to it. The name of the message and the name of the operation are the same.

Operations support object collaboration

•To accomplish a task many objects may need to collaborate. Objects collaborate by invoking operations in other objects (see Section 2.1.1.2).

Figure 2.10 shows operations in classes necessary to support the object collaboration demonstrated in figure 2.2

Operation visibility and scope

•The visibility of an operation defines whether the operation is visible to objects of classes other than a class that defines the operation. If it is visible then its visibility is public. It is private, otherwise.

III. Association

Shipment

shipment_id : Stringshipment_date : Datecarrier : String

shipOrder()

Order

order_number : Integerorder_date : Dateorder_value : Currency

*

*

+the_shipment

+the_order OrdShip

*

*

•An association is one kind of relationship between classes. Other kinds of relationships include: generalization, aggregation, dependency and a few more.

•The association relationship provides a linkage between objects of given classes. Typically, messages between objects are sent along association relationships.

Figure 2.11 shows the relationship named OrdShip between classes Order and Shipment. The relationship allows for an Order object to be shipped (to be linked to) more than one Shipment object (asterisk *).

III. Association:Association degree

Binary

Unary (singular)

Ternary

Employee 0..1

0..*

+can_be_managed_by

+can_be_manager_of

0..1

0..*

•Association degree defines the number of classes connected by an association. The most frequent association is of degree two. This is called a binary association.

•Association can also be defined on a single class. This is called a unary (or singular) association

III. Association:Association multiplicity

0..0 0..1 0..* 1..1 1..* *

Teacher

CourseOffering

0..*

1..*teaches

0..*

taught_by

1..*

0..*

1..1

is_managed_byis_in_charge_of

0..*

1..1

•The multiplicity states how many objects of a target class (pointed to by the rolename) can associated with a single object of the source class.

•The multiplicity is shown as a range of integers n1….n2. the integer n1 defines the minimum number of connected objects, and n2 – the maximum number(the maximum number can be an asterisk * if we do not know the precise maximum integer value). If we do not want to specify the minimum number, but we know that it could be many connected objects then we do not specify the minimum number at all.The most frequent multiplicities are:

0..1

0..*

1..1

1..*

*

III. Association:Association link and extent

Link – association instance Extent – set of association instances

Order 1

Shipment 1

Shipment 2

Shipment 2 Order 2

Link 1 with

3 references

Link 4

Link 2

Link 3

Link 5

Order 1

Shipment 1

Shipment 2

Shipment 2 Order 2

Link 1 with

3 references

Link 4

Link 2

Link 3

Link 5

•The association link is an instance of the association. The extent is a set of links.

Figure 2.14 is a particular instantiation of the association OrdShip in Figure 2.11. there are five links in Figure2.14. hence the extent of the association is five.

III. Association:Association class

Assessment

mark : List(Number)total_mark : Numbergrade : Byte

CourseOffering

**

Student

•Sometimes an association has attributes (and/or operations) of its own. Such an association must be modeled as a class. Each object of an association class has attribute values and links to the objects of associated classes. Because an associationclass is a class, it can be associated with other classes in the model in the normal way.

Figure 2.15 shows the association class Assessment. An object of the class Assessment stores a list of marks, a total mark and a grade obtained by a Student in a ClassOffering.

IV. Composition and aggregation Composition –

aggregation by value

Aggregation – aggregation by reference

Properties:• Transitivity

• Asymmetry

• Existence dependency

Book

Section

Chapter

*

is_part_of

has*

**

BeerBottle

Crate

**

•Aggregation is a whole-part relationship between a class representing an assembly of components (superset class) and the classes representing the components (subset classes).

•The containment property can be strong (aggregation by value) or weak (aggregation by reference). In UML, the aggregation by value is called composition, and the aggregation by reference is simply called aggregation.

•Composition has an addition property of existence dependency. An object of a subset class cannot exist without being linked to an object of the superset class.

Aggregation and composition

V. Generalization

Person

full_name : Stringdate_of_birth : Date

age()

Employee

date_hired : Datesalary : Moneyleave_entitlement : Integerleave_taken : Integer

remainingLeave()

InheritanceInheritance ReuseReuse

•Generalization is a kind-of relationship between a more generic class (superclass or parent) and a more specialized kind of that class (subclass or child).

•The attributes and operations already defined for a superclass may be reused in a subclass. A subclass is said to inherit the attributes and methods of its parent class.

•The inherited properties are not visibility shown in the subclass box - the generalization relationship forces the inheritance in the background.

•Note that inheritence applies to classes, not to objects. It applies to types, not to values.

V. Generalization:Polymorphism

Employee

date_hired : Datesalary : Moneyleave_entitlement : Integerleave_taken : Integer

remainingLeave() : Integer

Manager

date_appointed : Dateleave_supplement : Integer

remainingLeave() : Integer

The same signature(operation name and the number and type of arguments)

•A method inherited by a subclass is frequently used as is in that subclass. The operation age() works identically for the objects of classes Person and Employee. However, there are times when an operation needs to be overridden (modified ) in a subclass.

•Employee.remainingLeave() is computed by subtracting leave_taken from leave_entitlement. The operation Manager.remainingLeave() would override the operation Employee.reaminingLeave().

•We can now send the message remainingLeave() to an Employee object or to a Manager object and we will get a different method executed. The operation remainingLeave() is polymorphic.

V. Generalization:Multiple inheritance

Person

full_name : Stringdate_of_birth : Date

age()

Teacher Student

Tutor

PostgraduateStudent

•Inheritance permits incremental description of a subclass by reusing and then extending the superclass descriptions.

Multiple classes in an inheritance hierarchy may declare the same operation. Such an operation has many implementations (methods) but the same signature. The polymorphic behavior relies on inheritance.

Multiple inheritance

A subclass can inherit from more than one superclass. Multiple inheritance can lead to inheritance conflicts that have to be explicitly resolved by the programmer.

V. Generalization:Multiple classification

Multiple inheritance• A class may have many

superclasses, but a single class must be defined for each object

Multiple classification• An object is

simultaneously the instance of two or more classes

The problem arises if The problem arises if PersonPerson is specialized in few orthogonal is specialized in few orthogonal hierarchies hierarchies PersonPerson can be can be EmployeeEmployee or or StudentStudent, , MaleMale or or FemaleFemale, , ChildChild or or AdultAdult, etc. , etc.

Without multiple classificationWithout multiple classification need to define classes for each legal combination between need to define classes for each legal combination between

the orthogonal hierarchies the orthogonal hierarchies ChildFemaleStudentChildFemaleStudent etc. etc.

•In most current object-oriented programming environments, an object can belong to only one class.

•Multiple classification is different from multiple inheritance. In multiple classification an object is simultaneously the instance of two or more classes. In multiple inheritance a class may have many superclasses, but a single class must be defined for each object.

The problem arises if Person is specialized in a few orthogonal hierarchies. For example, a Person can be an Employee or Student, Male or Female, Child or Adult, etc. without multiple classification, we would need to define classes for each legal combination between the orthogonal hierarchies to have, for example, a class for a Person object who is a child female student (i.e. the class that could be called

ChildFemaleStudent)

V. Generalization:Dynamic classification

An object does not only belong to multiple classes but it can gain or lose classes over its lifetime

A Person object can be just an employee one day and a manager (and employee) another day

In most current object-oriented programming environments, an object cannot change its class after it has been instantiated (created)

•In most current object-oriented programming environments, an object cannot change its class after it has been instantiated (created). This is another troublesome restriction because in reality objects do change classes dynamically.

•Dynamic classification is a direct consequence of multiple classification. An object does not only belong to multiple classes but it can gain or lose classes over its lifetime.

•Under the dynamic classification schema, a Person object can be just an employee one day and a manager (and employee) another day. Without dynamic classification, the business changes such as promotion of employees are hard (or even impossible) to model declaratively in the class diagram. They would have to be modeled procedurally in state diagrams or similar modeling techniques.

V. Generalization:Abstract class

Parent class that will not have direct instance objects

Abstract class cannot instantiate objects because it has at least one abstract operation

Video

<<abstract>> rentalCharge()

VideoTape VideoDisk

Abstract class is an important modeling concept that follows the notation of inheritance. An abstract class is a parent class that will not have direct instance objects. Only subclasses of the abstract parent class can be instantiated.

In a typical scenario, a class is abstract because at least one of its operations is abstract. An abstract operation has its signature (the name and the list of normal arguments) defined in the abstract parent class, but the implementation of the operation (the method) is deferred to concrete child classes.

• Figure 2.20 shows the abstract class Video (in UML, the name of the abstract class is shown in italics). The class contains the abstract operation rentalCharge(). Understandably, rental charges are calculated differently for video tapes and for video disks. There will be two different implementations of rentalCharge() – in classes VideoTape and VideoDisk.

VI. Class object

Object with • Class-scope attributes and/or • Class-scope operations

Student

student_id : Stringstudent_name : PersonName$ max_courses_per_semester : Integer

<<global>> averageStudentAge() : Real

A class object is an object with class-scope attributes and/or class-scope operations. The class-scope implies here a global attribute or operation that applies to the class itself, not to any instance object. The most common class-scope attributes are attributes that hold default values or aggregation values. The most common class-scope operations are operations to create and destroy instance objects and operations that calculate aggregate values.

Guided tutorial in analysis modeling •This section presents a quick tutorial in UML visual modeling using a simple example. The purpose is to demonstrate various UML diagrams and to show they fit together. Each UML diagram emphasizes a particular view on the system. To understand the system in its entirety, multiple UML diagrams, representing different views, have to be developed and integrated.

•At the most generic level, we can distinguish three kinds of UML models – each with its own set of diagrams and related constructs:

1.The state model, which represents the static view of the system – it models data requirements. The state model represents data structures and their relationships. The main visualization technique for state modeling is the class diagram.

2.The behavior model, which represents the operational view of the system – it models function requirements. The behavior model represents business transactions, operations and algorithms on data. There are several visualization techniques for behavior modeling – use case diagram, sequence diagram, collaboration diagram, and activity diagram.

3.The state change model, which represents the dynamic view of the system – it models object evolution over time. The state change model represents possible changes to object states (where the state is defined by the current values of an object’s attributes and associations with other objects). The main visualization technique for state change modeling is the state chart diagram.

Statements for case studies

University Enrolment

Video Store

Contact Management

Telemarketing

University Enrolment The university offers

• Undergraduate and postgraduate degrees • To full-time and part-time students

The university structure• Divisions containing departments• Single division administers each degree• Degree may include courses from other divisions

University enrolment system• Individually tailored programs of study• Prerequisite courses • Compulsory courses• Restrictions

» Timetable clashes» Maximum class sizes, etc.

University Enrolment (cont) The system is required to

• Assist in pre-enrolment activities • Handle the enrolment procedures

Pre-enrolment activities • Mail-outs of

» Last semester's examination grades to students » Enrolment instructions

During enrolment • Accept students' proposed programs of study • Validate for prerequisites, timetable clashes, class sizes,

special approvals, etc. Resolutions to some of the problems may require

consultation with academic advisers or academics in charge of course offerings

Video Store

The video store

• Rentals of video tapes and disks to customers

• All video tapes and disks bar-coded

• Customer membership also be bar-coded.

Existing customers can place reservations on

videos to be collected at specific date

Answering customer enquiries, including enquiries

about movies that the video store does not stock

(but may order on request)

Contact Management The market research company with established customer

base of organizations that buy market analysis reports The company is constantly on the search for new customers Contact management system

• Prospective customers• Actual customers• Past customers

The new contact management system to be developed internally and be available to all employees in the company, but with varying levels of access• Employees of Customer Services Department will take the

ownership of the system The system to permit flexible scheduling and re-scheduling of

contact-related activities so that the employees can successfully collaborate to win new customers and foster existing relationships

Telemarketing The charitable society sells lottery tickets to raise

funds• Campaigns to support currently important charitable

causes• Past contributors (supporters) targeted through

telemarketing and/or direct mail-outs Rewards (special bonus campaigns)

• For bulk buying• For attracting new contributors

The society does not randomly target potential supporters by using telephone directories or similar means

Telemarketing (cont) Telemarketing application

• To support up to fifty telemarketers working simultaneously

• To schedule the phone calls according to pre-specified priorities and other known constraints To dial up the scheduled phone calls

• To re-schedule unsuccessful connections • To arrange other telephone callbacks to supporters • To records the conversation outcomes, including ticket

orders and any changes to supporter records

Summary Each object has a state, behavior and identity Class defines attributes and operations There are three kinds of relationships – association,

aggregation, generalization Generalization provides the basis for polymorphism and

inheritance Multiple inheritance is likely to be supported Multiple and dynamic classification is still not supported

commercially Abstract classes are important in modeling There are instance objects and class objects The OnLine Shopping guided tutorial (separate Lecture

Notes) Four case studies

Tutorial Guided Tutorial in Analysis Modeling

OnLine Shopping

OnLine Shopping - Tutorial

Topics

Online Shopping – Tutorial Statement

Use Case Modeling

Activity Modeling

Class Modeling

Interaction Modeling

Statechart Modeling

Online Shopping

•Our quick tutorial refers to an online shopping application. We are mostly concerned with the back end of the application – accepting a customer’s online order, the processing and filling of the order, invoicing, and the shipment of goods to a customer.

•The sequence of activities must not be interpreted as the recommended process. In reality, the process is iterative and incremental.

OnLine Shopping – Order Processing

Buying computers via Internet The customer can select a standard configuration

or can build a desired configuration online To place an order, the customer must fill out the

shipment and payment information The customer can check online at any time the

order status The ordered configuration is shipped to the

customer together with the invoice

A computer manufacturer offers the possibility of purchasing computers via the internet. The customer can select a computer on the manufacturer’s web page. The computers are classified into servers, desktops and portables. The customer can select a standard configuration or can build a desired configuration online. The configurable components (such as memory) are presented as picklists of available options. For each new configuration, the system can calculate price.

To place an order, the customer must fill out the shipment and payment information. Acceptable payment methods are credit cards and checks. Once the order has been entered, the system sends a confirmation e-mail message to the customer with details of the order. While waiting for the arrival of the computer, the customer can check the order status online at any time.

The back end order processing consists of the steps needed to verify the customer’s credentials and payment method, request the order configuration from the warehouse, to print an invoice, and to request the warehouse to ship the computer to the customer.

Customer order processing

Use case modeling Use case - outwardly visible and testable system behavior Actor - whoever or whatever (person, machine, etc.) that

interacts with a use case Actor receives a useful result Use case represents a complete unit of functionality of value

to an actor There may be some use cases that do not directly interact

with actors In many instances, a function requirement maps directly to a

use case Use Case Diagram is a visual representation of actors and

use cases together with any additional definitions and specifications

UML diagram is synonymous with UML model

•System behavior is what a system does when responding to external events. A use case performs a business function that is outwardly visible to an actor and that can be separately testable later in the developed process.

•An actor represents whoever or whatever (person, machine, etc.) that interacts with a use case.

•A use case diagram is not just a diagram but also a fully documented model of the system’s intended behavior. The notation of UML diagram is synonymous with UML model.

Actors Consider the requirement:

After customer’s order has been entered into the system, the salesperson sends an electronic request to the warehouse with details of the ordered configuration

Customer Salesperson Warehouse

•Actors and use cases are determined from the analysis of function requirements. It is immaterial whether the business analyst chooses to first identify actors and then use cases or the other way around. In this tutorial, we have chosen first to identify the actors.

•A typical graphical image for an actor is a ‘stick person’. In general, an actor can be shown as a class rectangular symbol. Like a normal class, an actor can have attributes and operations (events that it sends or receives).

Analysis tutorial: Step 1 (Online Shopping)

Refer to the tutorial statement above and consider the following extended requirements to find actors in the OnLine Shopping application:

1. 1. The customer uses the manufacturer’s online shopping web page to view the standard configuration of the chosen server, desktop or portable computer. The price is also shown.

2. 2. The customer chooses to view the details of the configuration, perhaps with the intention of buying it as is or to build a more suitable configuration. The price for each configuration can be computed at the customer’s request.

3. 3. The customer may choose to order the computer online or may request that the salesperson contact him/her to explain order details, negotiate the price, etc. before the order is actually placed.

4. 4. To place the order, the customer must fill out an online form with shipment and invoice address, and with payment details (credit card or check).

5. After the customer’s order has been entered into the system, the salesperson sends an electronic request to the warehouse with details of the ordered configuration.

1. 6. The details of the transaction, including an order number and customer account number, are e-mailed to the customer, so that the customer can check the status of the order online.

7. The warehouse obtains the invoice form the salesperson and ships the computer to the customer.

• Figure 2.22 shows the three actors that are manifestly present in the specifications.

Use cases The customer uses the

manufacturer’s online shopping Web page to view the standard configuration of the chosen server, desktop or portable computer

The customer chooses to view the details of the configuration, perhaps with the intention to buy it as is or to build a more suitable configuration

Display StandardComputer Configuration

Build ComputerConfiguration

Order ConfiguredComputer

Verify and AcceptCustomer Payment

Print InvoiceUpdate Order Status

RequestSalesperson Contact

Inform Warehouseabout Order

•A use case represents a complete unit of functionality of value to an actor. An actor who does not communicate with a case is meaningless, but the converse is not necessarily true (i.e. a use case that does not communicate with an actor is allowed).

•Use cases can be derived from the identification of tasks of the actor. The question to ask is : ‘What are the actor’s responsibilities towards the system and expectations from the system?’ Use cases can also be determined from direct analysis of function requirements. In many instances, a function requirement maps directly to a use case.

Analysis tutorial: Step 2 (OnLine Shopping)

Refer to Step 1 of the tutorial and find use cases in the online shopping application.

•To address this tutorial problem, we can construct a table that assigns the function requirements to the actors and the use cases. Table 2.1 assigns the function requirements listed in Step 1 of the tutorial to the actors and the use cases. A use case is drawn as an ellipse with the name inside the ellipse or below it.

Use Case Diagram

Display StandardComputer Configuration

Build ComputerConfiguration

Verify and AcceptCustomer Payment

Customer

Order ConfiguredComputer

RequestSalesperson Contact

<<extend>>

Inform Warehouseabout Order

Warehouse

Print Invoice

Salesperson

Update Order Status

The <<extend>> relationship - the use case Order Configured Computer can be extended by Customer with the use case Request Salesperson Contact

•The use case diagram assigns use cases to actors. It also allows the user to establish relationships between use cases, if any. The use case diagram is the principal visualization technique for a behavioral model of the system. The diagram elements (use cases and actors) need to be further described to provide a complete use case model (see Section 2.2.2.4)


Refer to previous steps of the tutorial and draw a use case diagram for the online shopping application.

•The meaning of the <<extend>> relationship is that the use case Order Configured Computer can be extended by Customer with the use case Request Salesperson Contact.

Documenting use cases Brief Description Actors involved Preconditions necessary for the use case to start Detailed Description of flow of events that

includes:• Main Flow of events, that can be broken down to show:

» Subflows of events (subflows can be further divided into smaller subflows to improve document readability)

• Alternative Flows to define exceptional situations

Postconditions that define the state of the system after the use case ends

•Each use case has to be described in a flow of events document. This textual document defines what the system has to do when the actor activities a use case. The structure of a use case document can vary, but a typical description would contain

•The use case document evolves with the development progress. In the early stage stage of requirements determination, only a brief description is written. Other parts of the document are written gradually and iteratively. A complete document emerges at the end of the requirements specification phase. At the stage, the prototypes of GUI screens can be added to the document. Later on, the use case document will be used to produce the user documentation for the implemented system.


Refer to the previous tutorial steps and write a use case document for the use case Order Configured Computer. Use your general knowledge of typical order processing tasks to derive details not stated in the requirements.

•The solution to this tutorial step is presented in a tabular form. This is not the usual way of documenting use cases. Use case documents can contain many pages (ten or so on average) and a normal document structure, complete with a table of contents, would be the norm.

Narrative use case specificationUse Case Order Configured Computer

Brief Description

This use case allows a Customer to enter a purchase order. …

Actors Customer

Preconditions The page displays the details of a configured computer together with its price. …

Main Flow The system assigns a unique order number and a customer account number to the purchase order and it stores the order information in the database. …

Alternative Flows

The Customer activates the Purchase function before providing all mandatory information. …

Postconditions If the use case was successful, the purchase order is recorded in the system’s database.

Activity Modeling Activity model

• Can graphically represent the flow of events of a use case• Can be used to understand a business process at a high-

level of abstraction before any use cases are produced Shows the steps of a computation

• Each step is a state of doing something• Execution steps are called activity states• Depicts which steps are executed in sequence and which

can be executed concurrently• Transition – the flow of control from one activity state to

the next Use case descriptions are (usually) written from

an outside actor’s perspective Activity models take an inside system’s viewpoint

•The activity model can graphically represent the flow of events of a use case. The activity models fill a gap between a high-level representation of system behavior in use case models and much lower-level representation of behavior in interaction models (sequence and collaboration diagrams).

•The activity diagram shows the steps of a computation. Each step is a state of doing something. For that reason, the execution steps are called activity states. The diagram depicts which steps are executed in sequence and which can be executed concurrently. The flow of control from one activity state to the next is called a transition.

•If a use case document has been completed then activity states can be discovered from the description of the main and alternative flows. There is, however, an important difference between the use case description and the activity model. Use case descriptions are written from an outside actor’s perspective. Activity models take an inside system’s viewpoint.

•They can be used to understand a business process at a high level of abstraction before any use cases are produced. Alternatively, they can be used at a much lower level of abstraction to design complex sequential algorithms or to design concurrency in multi-threaded applications.

Activities Activity states can be established from the use

case document

Activities should be named from the system’s

perspective, not the actor’s viewpoint

Activity takes time to complete

Action is so quick that – on our time scale – it is

considered to take no time at all

UML uses the same same graphical symbol for

activity state and action state – rounded rectangle

•If the activity modeling is used to visualize the sequencing of activities in a use case then activity states can be established from the use case document. An activity state is represented in UML by a rounded rectangle.


Refer to step 4 of the tutorial. Analyze the main and alternative flows in the use case document. Find activities for the use case Order Configured Computer in the online shopping application.

Table 2.3 lists the statements in the main and alternative flows of the use case document and identifies activity states.

Activities

The system assigns a unique order number and a customer account number to the purchase order and it stores the order information in the database.

Display Current Configuration

Get Order Request

Display Purchase Form

Get Purchase Details

Store Order Email Order Details

Activity Diagram Activity Diagram shows transitions between activities

A solid filled circle represents the initial state

The final state is shown using so called bull’s eye symbol

Transitions can branch and merge (diamond) – alternative

computation threads

Transitions can fork and re-join (bar line) –concurrent

(parallel) computation threads

Activity diagram without concurrent processes resembles a

conventional flowchart

•The activity diagram shows transitions between activities. The diagram will have an initial activity state and one or more final activity states. A solid filled circle represents the initial state. The final state is shown using a ‘bull’s eye’ symbol.

•Transitions can branch and merge. This creates alternative computation threads. A diamond box shows the branch condition.

•Transitions can also fork and rejoin. This creates concurrent (parallel) computation threads. The fork/join of transitions is represented by a bar line. Note that an activity diagram without concurrent processes resembles a conventional flowchart.


Refer to steps 4 and 5 of the tutorial and draw an activity diagram for the use case Order Configured Computer in online shopping application.

Display Current Configuration is the initial activity state.The recursive transition on this state recognizes the fact that the display is continuously refreshed until the next transition fires (to Get Order Request).

When in the state Display Purchase Form, the timeout condition finishes the execution of the activity model. Alternatively, the state Get Purchase Details is activated. If the purchase details are incomplete, the system again enters the state Display Purchase Form. Otherwise, the system gets into the state Store Order, followed by the state Email Order Details (the final state).

Activity Diagram

Display Current Configuration

Get Order Request

Display Purchase Form

Get Purchase Details

Store Order

Email Order Details

[ timeout ]

[ incomplete ]

[ OK ]

Multiple exit transitions (branch condition that is internal to activity state)

Explicit branch condition (that appears on exit from activity state)

Scan Customer Card

Scan Video Medium

Verify Customer

Initiate Rent Transaction

Remove One Medium

Request Deposit

Accept Payment

Update Stock Print Receipt

Commit Rent Transaction

[ is unreliable ]

[ is delinquent ]

[ deposit refused ]

[ > 8 videos ]

add deposit

Activity Diagram

Class Modeling Captures system state – the function of the

system's information content at a point in time Class modeling elements

• classes themselves• attributes and operations of classes• Relationships – associations, aggregation and

composition, generalization Class Diagram – combined visual representation

for class modeling elements Class modeling and use case modeling are typically

conducted in parallel

•The class modeling elements include classes themselves, attributes and operations of classes, associations , aggregation and composition, and generalization. A class diagram provides a combined visual representation for these modeling elements.

•We remind you again that although in the tutorial we discuss modeling after use case modeling, in practice these two activities are typically conducted in parallel. The two models feed each other with supplementary information. Use cases facilitate class discovery and vice versa – class models can lead to the discovery of overlooked use cases.

Classes So far, we have used classes to define "business

objects" • Called entity classes (model classes)

• Represent persistent database objects

Other classes• Classes that define GUI objects (such as screen forms) –

boundary classes (view classes)

• classes that control the program's logic – control classes

Boundary and control classes may or may not be

addressed in requirements analysis – may be

delayed until the system design phase

•Our class examples have all been long – lived (persistent) business entities, such as Order, Shipment, Customer, Student, etc. these are the classes that define the database model for an application domain. For that reason, such classes are frequently called entity classes (model classes). They represent persistent database objects.

•Then entity classes define the essence of any information system. Requirements analysis is interested predominantly in entity classes. However, for the system to function other classes are needed as well. The system needs classes that define GUI objects (such as screen forms) – called the boundary classes (view classes). The system also needs classes that control the program’s logic – the control classes (see Section 5.2.3)


Refer to the requirements defined in the tutorial statement (Section 2.2.1) and in Step 1 of the tutorial (Section 2.2.2.1). find candidate entity classes in the online shopping application.

Following the approach taken in finding actors and use cases (see Table 2.1), we can construct a table that assists in finding classes from the analysis of function requirements.

Finding classes is an iterative task and the initial list of candidate classes is likely to change. Answering a few questions may help to determine whether a concept in the requirements is a candidate class.

Classes

Is this a class?

• Is the concept a container for data?

• Does it have separate attributes that will take on

different values?

• Would it have many instance objects?

• Is it in the scope of the application domain?

The questions are:

1. Is the concept a container for data?

2. Does it have separate attributes that will take on different values?

3. Would it have many instance objects?

4. Is it in the scope of the application domain?

•For the purpose of this tutorial, we have chosen the list of classes as shown in Figure 2.27. Note that the class Customer has already appeared as an actor in the use case diagram – hence the annotation ‘from use case view’.

Classes The warehouse obtains the invoice from the salesperson and

ships the computer to the customer

Customer(from Use Case View)

Computer

ConfiguredComputer

Order InvoicePayment

ConfigurationItem

Is Salesperson a class or an attribute of Order and Invoice?

Do we need Shipment class? Is it in the scope?

AttributesCustomer

customer_name : Stringcustomer_address : Stringphone_number : Stringemail_address : String

(from Use Case View)

Orderorder_number : Stringorder_date : Dateship_address : Stringorder_total : Currencyorder_status : Stringsalesperson_name : String

Paymentpayment_method : Stringdate_received : Dateamount_received : Currency

Invoiceinvoice_number : Stringinvoice_date : Dateinvoice_total : Currency

ConfiguredComputercomputer_name : Stringconfigured_price : Currency

Computercomputer_name : Stringstandard_price : Currency

ConfigurationItemitem_type : Stringitem_descr : String

•The structure of a class is defined by its attributes.


Refer to Steps 5, 6 and 7 of the tutorial. Think about attributes for the classes in Figure 2.27. consider only attributes with primitive type (Section 2.1.2.1).

•Figure 2.28 shows the classes with primitive attributes. Attributes of ConfigurationItem warrant brief explanation. The attribute item_type will have values such as processor, memory, screen, hard drive, etc. the attribute item_descry will further describe the item type. For example, the processor in the configuration may be an Intel 600MHz with 256 k cache.

Admittedly and understandably, there is a significant amount of arbitrary decisions in defining attributes in Figure 2.28.

AssociationsComputer

ConfigurationItem


ConfiguredComputerPayment Invoice

Order

0..*1..1

0..*1..1

1..*

0..*

1..*

0..*1..1

1..1

1..1

1..1

1..1

0..1

1..1

0..1

•Associations between classes establish pathways for easy object collaboration (Section 2.1.3). in the implemented system, the associations will be represented with attribute types that designate associated classes.


Refer to the previous steps of the tutorial. Consider the classes in Figure 2.28. think what access paths between these classes are required by the use cases. Add associations to the class model.

•We made a few assumptions when determining association multiplicities. Order is from a single Customer, but Customer may place many Orders. Order is not accepted unless the Payment has been specified (hence, one-to-one association). Order does not have to have an associated Invoice, but Invoice is always related to a single Order. An Order is for one or many ConfiguredComputers. A ConfiguredComputer may be ordered many times or not at all.

AggregationsCustomer


Payment Invoice

Order

0..*1..1

0..*1..1

1..1

1..1

1..1

1..1

1..1

0..1

1..1

0..1

ConfiguredComputer

1..*

0..*

1..*

0..*ConfigurationItem

1..*1..*

Computer

1..*1..*

•In a typical commercial programming environment, aggregations and compositions are likely to be implemented like associations – with attribute types that designate associated classes.


Refer to the previous steps of the tutorial. Consider the models in Figure 2.28 and 2.29. Add aggregations to the class model.

•Figure 2.30 adds two aggregation relationships to the model. Computer has one or more ConfigurationItems. Likewise, ConfiguredComputer consists of one or many ConfigurationItems.

Generalizations

ConfiguredComputer StandardComputer


Payment Invoice

ConfigurationItem

Computer

1..*1..*

Order

0..*1..1

0..*1..1

1..1

1..1

1..1

1..1

1..1

0..1

1..1

0..1

1..*0..* 1..*0..*

•Can also greatly simplify and clarify the model. The simplification in the model is semantic not graphical. The simplification is achieved by the added precision with which the existing classes can be associated with the most applicable classes in the generalization hierarchy.


Refer to the previous steps of the tutorial. Consider the models in Figure 2.28 and 2.30. Think how you can extract any common attributes in the existing classes into a higher-level class. Add generalizations to the class model.

•Figure 2.31 shows a modified model with the class Computer changed to a generic abstract class for two concrete subclass StandardComputer and ConfiguredComputer.

Class Diagram

ConfiguredComputerconfigured_price : Currency

StandardComputerstandard_price : Currency

Customer

customer_name : Stringcustomer_address : Stringphone_number : Stringemail_address : String


Paymentpayment_method : Stringdate_received : Dateamount_received : Currency

Invoiceinvoice_number : Stringinvoice_date : Dateinvoice_total : Currency

ConfigurationItemitem_type : Stringitem_descr : String

Computer

computer_name : String

1..*1..*

Orderorder_number : Stringorder_date : Dateship_address : Stringorder_total : Currencyorder_status : Stringsalesperson_name : String

0..*

1..1

0..*

1..1

1..1

1..1

1..1

1..1

0..1

1..1

0..1

1..*0..* 1..*0..*

1..1

•The class diagram is the heart and soul of an object – oriented system. In this tutorial, we have only demonstrated the static modeling ability of the class model.

•We have not added as yet any operations to the classes. The operations belong more to the design than analysis realm. When operations are eventually included in classes, the class model implicitly defines the system dehavior.


Refer to the previous steps of the tutorial. Combine the models in Figures 2.28 and 2.31 to show a complete class diagram. Modify attribute content of classes as necessitated by the introduction of the generalization hierarchy.

Interaction modeling Captures interactions between objects needed to

execute a use case Shows the sequencing of events (messages)

between collaborating objects Used in more advanced stages of requirements

analysis, when a basic class model is known, so that the references to objects are backed by the class model

Two kinds of interaction diagrams• Sequence Diagram – concentrate on time sequences • Collaboration Diagram – emphasize object relationships

Prevailing IS development practice – Sequence Diagrams in requirements analysis and Collaboration Diagrams in system design

Interaction modeling captures between objects needed to execute a use case. Interaction models are used in more advanced stages of requirements analysis, when a basic class model is known, so that the references to objects are backed by the class model.

The above observation underprints the main distinction between the activity modeling and the interaction modeling. Both capture the behavior of a single use case (usually). However, the activity modeling is done at a higher level of abstraction – it shows the sequencing of events without assigning the events to objects. The interaction modeling shows the sequencing of events (messages) between collaborating objects.

There are two kinds of interaction diagram – the sequence diagram and the collaboration diagram. They can be used interchangeably and, indeed, many CASE tools support an automatic conversion from one model to the other. The difference is in emphasis. The sequence models concentrate on time sequences and the collaboration models emphasize object relationships.

In this book, we elected to use sequence diagrams in requirements analysis and collaboration diagrams in system design.

Interactions Interaction – set of messages in some behavior that are

exchanged between objects across links Sequence Diagram

• Objects - horizontal dimension

• Message sequence - top to bottom on vertical dimension

• Each vertical line - the object's lifeline

• Arrow - message from a calling object (sender) to an operation (method) in the called object (target)

» Actual argument can be input argument (from the sender to the target) output argument (from the target back to the sender).

crs_ref.getCourseName(out crs_name)• Showing the return of control from the target to the sender is not

necessary

• Iteration marker – an asterisk in front of the message label – indicates iterating over a collection

•An interaction is a set of messages in some behavior that are exchanged between objects across links. The sequence diagram is a two – dimensional graph. Objects are shown along the horizontal dimension. Sequencing of messages is shown top to bottom on the vertical dimension. Each vertical line is called the object’s lifeline.

•An arrow represents each message from a calling object (sender) to an operation (method) in the called object (target). As a minimum, the message is named. Actual arguments of the message and other control information can also be included. The actual arguments correspond to the formal arguments in the method of the target object.

•The actual argument can be an input argument (from the sender to the target) or an output argument (from the target back to the sender). The input argument may be identified by the keyword in. the output argument is identified with the keyword out. The message getCourseName (see Section 2.1.1.3.1), sent to an object identified by variable crs_ref, has one output argument and no input arguments.

•Showing the return of control from the target to the sender object is not necessary. The message arrow to the target object implies automatic return of control to the sender. The target knows the OID of the sender.

•A message can be sent to a collection of objects. This is frequently the case when a calling object is linked to multiple receiver objects (because the multiplicity of the association is one-to-many or many-to-many). An iteration marker – an asterisk in front of the message label – indicates iterating over a collection.


Refer to the activity diagram in Figure 2.26. Consider the first step in the diagram, Display Current Configuration. Construct a sequence diagram for this step.

The outside actor (Customer) chooses to display the configuration of a computer. The message openNew is sent to an object ConfWin of the class ConfigurationWindow. The message results in creating (instantiating) a new aConfWin object. (Configuration Window is a boundaryclass (Section 2.2.4.1).)

The object aConfWin needs to ‘display itself’ with the configuration data. To this aim, it sends a message to the object aComp : Computer. In reality, aComp is an object of the class StandardComputer or ConfiguredComputer.

The object acomp uses the output argument item_rec to ‘compose itself’ from ConfigurationItem objects. It then sends the configuration items in bulk to aConfWin as an argument I_recset of displayComputer message. The object aConfWin can now display itself. The screen display will be similar to Figure 2.34.

Interactions

: Customer

aConfWin : ConfigurationWindow

aComp : Computer

: ConfigurationItem

openNewgetConf

* getConfItem (out item_rec)

displayComputer(item_recset)

Interactions

Operations

Examining the interactions can lead to the

discovery of operations

• Each message invokes an operation in the called object

• The operation has the same name as the message

Similarly, the presence of a message in a

Sequence Diagram stipulates the need for an

association in the Class Diagram

•Although the introduction of operations to classes is frequently delayed to the design phase, we will illustrate in this tutorial that examining the interactions can lead to the discovery of operations. The dependency between interactions and operations is straightforward. Each message invokes an operation in the called object. The operation has the same name as the message.

•Of course, this one-to-one mapping between messages in interaction models and methods in implemented classes.

•As an aside we observe that similar one-to-one mapping exists between messages and associations, when a message is sent between persistent (model) objects. Therefore, the presence of a message in a sequence diagram stipulates the need for an association in the class diagram.


Refer to the class diagram in Figure 2.32 and to the sequence diagram in Figure 2.33. For each interaction message in the sequence diagram add an operation to a relevant class in the class diagram. Do not redraw the whole class diagram – only show the classes extended with operations.

•The solution to this simple tutorial step is shown in Figure 2.35. Three affected classes are shown. ConfigurationWindow is a boundary class. Two other classes are entity classes representing persistent database objects. The operation openNew is stereotyped as a constructor operation. This means that openNew will be implemented as a constructor method that instantiates objects of the class.

•The class Computer is an abstract class. GetConf is an abstract operation to be inherited by subclasses (ConfiguredComputer and StandardComputer). These subclasses provide their own implementations of getConf.

Operations

ConfigurationWindow

<<constructor>> openNew()displayComputer(item_recset)

<<boundary>>

Computer

computer_name : String

<<abstract>> getConf()

ConfigurationItem

item_type : Stringitem_descr : String

getConfItem(out item_rec)

Sequence Diagram

•As mentioned, a separate sequence diagram is frequently constructed for each use case. Since each use case is likely to be also expressed in an activity diagram, a sequence diagram can be built for each activity diagram. Providing multiple correlated viewpoints on the same system is the cornerstone of a good modeling.


Refer to the activity diagram in Figure 2.26 and construct a sequence diagram for it. To simplify the diagram do not shown the exchange of messages between Computer and ConfigurationItem objects.

Also, do not visualize subclass objects – assume that a Computer object is either a StandardComputer or ConfiguredComputer.

Shown only activation messages. Returns and implicit. There is no need to specify operation arguments or other control information.

•The sequence diagram has been split into two parts for redability (Order and OrderWindow lifelines are repeated in the two parts).

•The sequence diagram is largely self-explanatory. The message acceptConf results in the prepareForOrder message sent to an : Order object. This creates a transient : Order object that is displayed in : OrderWindow.

•On the customer’s acceptance of the order details (submitOrder),: OrderWindow instigates (storeOrder) the creation of a persistent : Order object. The : Order object then links itself to the ordered : Computer and to relevant : Customer and Payment objects. Once these objects are persistently linked in the database, the :Order object sends the emailOrder message to the outside actor Customer.

•Note the double use of : Customer as an outside actor object and an inside class object.

Sequence Diagram

Statechart modeling Captures dynamic changes of class states – the life

history of the class These dynamic changes describe typically the

behavior of an object across several use cases State of an object – designated by the current

values of the object's attributes Statechart Diagram – a bipartite graph of

• states (rounded rectangles) and • transitions (arrows) caused by events

The concepts of states and events are the same concepts that we know from Activity Diagrams – the difference is that “the states of the activity graph represent the states of executing the computation, not the states of an ordinary object”

•An interaction modelingprovides a detailed specification for a use case. A statechart model gives a detailed description of a class – dynamic changes of class states. These dynamic changes describe typically the behavior of an object across several use cases.

•A state of an object is designed by the current values of the objet’s attributes.

•A statechart diagram is a bipartite graph of states (rounded rectangles) and transitions (arrows) caused by events. The underlying concepts of states and events are the same concepts that we know from activity diagrams. The difference is that ‘the states of the activity graph represent the states of executing the computation, not the states of an ordinary object’.

States and transitions

Objects change values of their attributes but not all

such changes cause state transitions

We construct state models for classes that have

interesting state changes, not any state changes

Statechart Diagram is a model of business rules

• Business rules are invariable over some periods of time

• They are relatively independent of particular use cases

•Objects change values of their attributes but not all such changes cause state transitions.

•The above example captures the essence of state modeling. We construct state models for classes that have interesting state changes, not any state changes. A statechart diagram is a model of business rules.


Consider the class Invoice in the online shopping application. We know from the use case model that a customer specifies the payment method (credit card or check) for the computer when the purchase form is filled out and submitted to the vendor. However, the use case model has not specified when the payment is actually received with relation to the invoice that is to be prepared for the order.

From the class model we know that the invoice for the order is prepared by a salesperson, but it is eventually handed over to the warehouse. The warehouse sends the invoice to the customer together with the computer shipment. It is important that the payment status of the invoice is maintained in the system so that invoices are properly annotated.

Draw a statechart diagram that captures possible invoice states as far as payments are concerned.

States and transitions

Unpaid Partly Paid

Fully Paid

partial payment

final paymentfinal payment

Statechart Diagram Normally attached to a class, but can be attached to

other modeling concepts, e.g. a use case When attached to a class, the diagram determines

how objects of that class react to events• Determines – for each object state – what action the

object will perform when it receives an event• The same object may perform a different action for the

same event depending on the object’s state• The action’s execution will typically cause a state change

A statechart diagram is normally attached to a class, but in general, it can be attached to other modeling concepts, e.g. a use case. When attached to a class, the diagram determines how objects of that class react to events. The same object may perform a different action for the same event depending on the object’s state.

The complete description of a transition consists of three parts:

event (parameters) [guard] /action.

Each part is optional. It is possible to omit all of them, if the transition line by itself is self-explanatory.

The event is a quick occurrence that effect an object. It can have parameters, e.g. mouse button clicked (right_button). The event can be guarded by a condition, e.g. mouse button clicked (right_button) [inside the window].

The action is a short atomic computation that executes when the transition fires. An action can also be associated with a state.The states can additionally contain longer computations – called activities.

States can be composed of other states- nested states. A transition taken out of a composite state’s boundary means that it can fire from any of the nested states.

Analysis tutorial: step 17 (Online Shopping)

Refer to the previous steps of the tutorial. Consider the class Order in the online shopping application. Think about states in which order can be – starting from its submission to the system and culminating in its fulfillment.

Consider that an ordered computer can be in stock or it may need to be individually configured to satisfy your requirements. You may also specify some day in the future that you want to receive the computer, even if the computer is in stock.

You are allowed to cancel your order anytime prior to the computer’s shipment. You don’t need to model any penalty that may be involved in late canceling.

Draw a statechart diagram for the class order.

•The initial state is New Order. This is one of the Pending states – the other being Back Order and Future Order. There are two possible transitions out of any of the three states nested in the pending state.

•The transition into the Canceled state is guarded by the condition [canceled]. It would be possible – without violation the statechart modeling rules – to replace the guard by the event cancel.

Statechart Diagram The complete description of a transition consists

of three partsevent (parameters) [guard] / action

Action – short atomic computation that executes when the transition fires• can also be associated with a state

Activity – longer computation associated with a state

Statechart Diagram

Pending

Future Order

New Order Back Order

Filled

Future Order

Ready to Ship

New Order Back Order

Cancelled

stock not available

stock available[ ship date in future ]

stock available[ ship date in future ]

stock available[ ship date now ] / configureComputer[ canceled ]

ship[ accepted ]

[ canceled ]

Problem statement 1: University Enrollment A medium-size university offers a number of undergraduate and postgraduate degrees to full-time and part-time students. The educational structure of the university consists of divisions. Divisions contain several departments. While a single division administers each degree, the degree may include courses from other divisions. In fact, the university prides itself on the freedom of choice given to students in selecting courses towards their degrees.

The flexibility of course selection puts strains on the university enrolment system. Individually tailored programs of study must not contradict the rules governing the degree, such as the structure of prerequisite courses required so that the student can qualify for the degree’s compulsory courses. A student’s choice of courses may be restricted by timetable clashes, maximum class sizes, etc.

The flexibility of education offered by the university has been the main reason behind the steady growth in student numbers. However, to maintain its traditional strength, the current enrolment system – still partly manual – has to be replaced by a new software solution. The preliminary search for an off-the-shelf software package has not been successful. The university enrolment system is sufficiently unique to warrant the in-house development.

The system is required to assist in pre-enrolment activities and to handle the enrolment procedures. The pre-enrolment activities must include the mail-outs of last semester’s examination grades to students together with any enrolment instructions. During enrolment session, the system must accept the students proposed programs of study and validate them for prerequisites, timetable clashes, class sizes, special approvals, and etc. Resolutions to some of the problems may require consultation with academic advisers or academics in charge of course offerings.

Problem statement 2: Video Store A new store intends to offer rentals of videotapes and disks to the wider public. The store management is determined to launch its operations with the support of a computer system. The management has already sourced a number of small-business software packages that might be suitable for customization and further development. To assist with the package selection, the store hired a business analyst whose job is to determine and specify the requirements.

The video store will initially keep a stock of about a thousand videotapes and five hundred videodisks. The inventory has already been ordered from one supplier, but more suppliers will be approached in future orders. All videotapes and disks will be bar coded so that a scanning machine integrated with the system can support the rentals and returns. The customer membership cards will also be bar coded.

Existing customers will be able to place reservations on videos to be collected at a specific date. The system must be have a flexible search engine to answer customer enquires, including enquires about movies that the video store does not stock (but may order them on request).

Problem statement 3: Contact Management A market research company has an established customer base of organization that buys market analysis reports. Some larger customers have also purchased specialized reporting software from the company. These customers are then provided with raw and pre-aggregated information for their own report generation.

The company is constantly on the search for new customers, even if the new customers may only be interested in one-off, narrowly targeted market reports. Since the prospective customers are not quite customers ye, the company prefer to call them contacts – hence, contact management system (contact are prospective actual and past customers).

A new contact management system is to be developed internally and be available to all employees in the company, but with varying levels of access. The employees of the Customers Services Department will take the ownership of the system. The system will permit flexible scheduling and re-scheduling of contact=related activities so that the employees can successfully collaborate to win new customers and foster existing relationships.

Problem statement 4: Telemarketing

A charitable society sells lottery tickets to raise funds. The fundraising is done in campaigns to support currently important charitable causes. The society keeps a list of past contributors (supporters). For each new campaign, a subset of these supporters is pre-selected for telemarketing and/or direct mail contact.

The society uses some innovative schemes to gain new supporters. The schemes include special bonus campaigns to reward supporter for bulk buying, for attracting new contributors, etc. The society does not randomly target potential supporters by using telephone directories or similar means.

To support its work, the society decided to contract out the development of a new telemarketing application. The new system is required to support up to fifty telemarketers working simultaneously. The system must be able to schedule the phone calls according to pre-specified priorities and other known constraints.

The system is required to dial up the schedule phone calls. Unsuccessful connections must be re-scheduled and tried again later. Telephone callbacks to supporters must also be arranged. The conversation outcomes, including ticket orders and any changes to supporter

records, ought to be maintained.

requirements analysis overview fundamentals of object technology (ooa/d) cmpe 104 lesson 4

Documents