Software Processes

1
CmpE 104 Lesson 4
Requirements Analysis Overview FUNDAMENTALS OF
OBJECT TECHNOLOGY (OOA/D)
2
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

3
Fundamentals of OT

• Object has
• State
• Behavior
• Identity
• Objects and natural systems

4
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.

5
I. Instance object

• Class
• Instance object
• Class object

6

• 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

7
Instance ObjectHow objects collaborate?
8
How do 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)

9
Instance Object How objects identify each other?

• OID
• OID links
• Object longevity
• Persistent object
• Transient object
• Object communication via
• Persistent OIDs
• Transient OIDs

10

• 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.

11
Instance ObjectPersistent link implementation
12

•  
• 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_at_ - 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.

13
Instance ObjectPersistent links in UML
14
Instance ObjectTransient 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

15
II. Class
16

•  
• 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.

17
II. Class Attribute
18

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

19
II. ClassAttribute type designating a class
20

•  
• 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.

21
II. Class Attribute visibility
22

•  
• 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.

23
II. Class Operation
24

•  
• 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.
•  

25
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

26
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.

27
III. Association
28

• 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 ).

29
III. Association Association degree

• Binary
• Unary (singular)
• Ternary

30

• 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

31
III. Association Association multiplicity

• 0..0
• 0..1
• 0..
• 1..1
• 1..

32

• 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..

33
III. Association Association link and extent

• Link association instance
• Extent set of association instances

34

•  
• 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.

35
III. Association Association class
36

• 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.

37
IV. Composition and aggregation

• Composition aggregation by value
• Aggregation aggregation by reference
• Properties
• Transitivity
• Asymmetry
• Existence dependency

38
Aggregation and composition

• 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.
•  

39
V. Generalization

• Inheritance
• Reuse

40

• 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.

41
V. Generalization Polymorphism
The same signature (operation name and the number
and type of arguments)
42

•  
• 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.

43
V. Generalization Multiple inheritance
44

• 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.

45
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.
46
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 Person is specialized in
  few orthogonal hierarchies
• Person can be Employee or Student, Male or
  Female, Child or Adult, etc.
• Without multiple classification
• need to define classes for each legal combination
  between the orthogonal hierarchies
• ChildFemaleStudent etc.

47

• 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)
  

48
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)

49

• 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.

50
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

51

•    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.

52
VI. Class object

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

53
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.
54
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
• 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. 
• 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. 
• 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 objects attributes and associations with
  other objects). The main visualization technique
  for state change modeling is the state chart
  diagram.

55
Statements for case studies

• University Enrolment
• Video Store
• Contact Management
• Telemarketing

56
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.

57
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

58
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)

59
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

60
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

61
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

62
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

63
OnLine Shopping - Tutorial
Tutorial Guided Tutorial in Analysis
ModelingOnLine Shopping
64
Topics

• Online Shopping Tutorial Statement
• Use Case Modeling
• Activity Modeling
• Class Modeling
• Interaction Modeling
• Statechart Modeling

65
Online Shopping

• Our quick tutorial refers to an online shopping
  application. We are mostly concerned with the
  back end of the application accepting a
  customers 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.

66
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

67
Customer order processing
A computer manufacturer offers the possibility of
purchasing computers via the internet. The
customer can select a computer on the
manufacturers 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 customers 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.
68
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

69

• 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 systems intended
  behavior. The notation of UML diagram is
  synonymous with UML model.

70
Actors

• Consider the requirementAfter customers order
  has been entered into the system, the salesperson
  sends an electronic request to the warehouse with
  details of the ordered configuration

71

• 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).

72
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.      The customer uses the manufacturers
  online shopping web page to view the standard
  configuration of the chosen server, desktop or
  portable computer. The price is also shown. 
• 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 customers request. 
• 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.      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 customers order has been
  entered into the system, the salesperson sends an
  electronic request to the warehouse with details
  of the ordered configuration. 
• 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.
•  

73
Use cases

• The customer uses the manufacturers 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

74

• 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 actors 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.

75
Use Case Diagram
The ltltextendgtgt relationship - the use case Order
Configured Computer can be extended by Customer
with the use case Request Salesperson Contact
76

• 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 ltltextendgtgt relationship is
  that the use case Order Configured Computer can
  be extended by Customer with the use case Request
  Salesperson Contact.

77
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

78

• 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.

79
Narrative use case specification
Use 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 systems database.
80
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 actors perspective
• Activity models take an inside systems viewpoint

81

• 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 actors perspective. Activity models take
  an inside systems 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.

82
Activities

• Activity states can be established from the use
  case document
• Activities should be named from the systems
  perspective, not the actors 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

83

• 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.

84
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.

85
Activity Diagram

• Activity Diagram shows transitions between
  activities
• A solid filled circle represents the initial
  state
• The final state is shown using so called bulls
  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

86

• 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
  bulls 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).

87
Activity Diagram
Explicit branch condition (that appears on exit
from activity state)
Multiple exit transitions (branch condition that
is internal to activity state)
88
Activity Diagram
89
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

90

• 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.

91
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

92

• 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
  programs 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.  

93
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?

94

• 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.
•  

95
Classes

• The warehouse obtains the invoice from the
  salesperson and ships the computer to the
  customer

Do we need Shipment class? Is it in the scope?
Is Salesperson a class or an attribute of Order
and Invoice?
96
Attributes
97

• 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.

98
Associations
99

•  
• 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.

100
Aggregations
101

• 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.

102
Generalizations
103

• 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.

104
Class Diagram
105

• 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.
•  

106
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

107
        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.
108
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

109

•  
• 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 objects
  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. 

110

• 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.

111
Interactions
112
Interactions
113
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

114

• 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.

115
Operations
116
Sequence Diagram
117

• 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 customers acceptance of the order details
  (submitOrder), OrderWindow instigates
  (stor