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.
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)
Analysis tutorial: Step 3 (OnLine Shopping)
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.
Analysis tutorial: Step 4 (OnLine Shopping)
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.
Analysis tutorial: Step 5 (OnLine Shopping)
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.
Analysis tutorial: Step 6 (OnLine Shopping)
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)
Analysis tutorial: Step 7 (OnLine Shopping)
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.
Analysis tutorial: Step 8 (OnLine Shopping)
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
Customer(from Use Case View)
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.
Analysis tutorial: Step 9 (OnLine Shopping)
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
(from Use Case View)
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.
Analysis tutorial: Step 10 (OnLine Shopping)
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
Customer(from Use Case View)
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.
Analysis tutorial: Step 11 (OnLine Shopping)
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
(from Use Case View)
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.
Analysis tutorial: Step 12 (OnLine Shopping)
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.
Analysis tutorial: Step 13 (OnLine Shopping)
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.
Analysis tutorial: Step 14 (OnLine Shopping)
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.
Analysis tutorial: Step 15 (OnLine Shopping)
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.
Analysis tutorial: Step 16 (OnLine Shopping)
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.