Analysis

1
PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e
Chapter 5 Restaurant System Analysis
2
Analysis

• What is to be analyzed?
• the system requirements
• Why?
• to demonstrate their implementability
• How?
• by drawing interaction diagrams realizing use
  cases

3
Analysis v. Design

• Difficult to draw a boundary
• Traditional informal distinction
• analysis models the real-world system
• design models the software
• Object-oriented methods use the same notation for
  both activities
• encourages seamless development and iteration

4
Object Design

• We need to define attributes and operations for
  each class in the model
• Start from domain model, but
• structure of real-world application is not always
  the optimal structure for a software system
• domain model does not show operations
• Realization identifies operations and confirms
  that design supports functionality

5
Object Responsibilities

• Each class in a system should have well-defined
  responsibilities
• to manage a subset of the data in the system
• to manage some of the processing
• The responsibilities of a class should be
  cohesive
• they should belong together
• they should form a sensible whole

6
Software Architecture

• A software architecture a high level view of
  software, described as a number of of distinct
  components or subsystems together with their
  relationships and interaction .
• Description of UML component/deployment may be
  used to document architectures
• Architectures are the configurations of
  components that make up the systems.
• Architectural pattern is a high level pattern
  describing a solution at architectural level.
• Architectures are the configurations of
  components that make up the systems.

7
Software Architecture

• A software architecture describes a
  configurations of a number of distinct components
  or subsystems together with their relationships
  and interaction. Or more simply, architectures
  are the configurations of components that make up
  the systems. Different Architectural Styles, such
  as client/server or layered, data centric,
  address different design problems.

8
Software Architecture Types

• Data-flow concentrates on the flow of data e.g.
  batch processing.
• Data-centered focuses on centralised persistent
  data e.g. data base.
• Virtual-machine layered software e.g. ISO OSI
  seven layer model.
• Call-return focuses on a sequence of
  instruction, single thread of control.
• Independent-component supports modifiability
  e.g. client server.

9
UML and Architecture

• To be useful, architecture must be described in a
  clear, explicit way to serve as the basis for
  understanding, implementation reuse, and
  evolution of the system. In the UML packages,
  profiles, component and deployment diagrams may
  be used to document architectures.
• Designing the architecture of the system is part
  the RUP process (using packages and profiles
  etc).
• RUP considers architecture as central and is
  included in the process.
• The UML also provides an architectural view of
  how its own components fit together.

10
Business Object

• A car hire company with branches at major
  airports plans to develop a web-based system to
  support customer-based functions, such as car
  hiring, and company focused activities, such as
  maintaining the vehicle fleet.

11
Possible Business Object

• Customer Someone who checks on the availability
  of cars, makes contractual arrangements for
  hiring cars, takes cars out, returns them, is
  billed for this service and who in turn makes
  payments. Without customers the business model
  would not make sense and could not function.
• Car Cars are reserved for use, taken out (and
  returned) by customers, maintained and repaired.
  The business is a car hire business without cars
  the business model would not make sense.
• Hire Contract These are agreed between
  customers and the business. They are contractual
  arrangements for the provision of car rental
  services for a specified period of time. Hire
  contracts are fundamental to how the business
  operates and how operational data is recorded

12
Possible Architecture

• A possible architectural approach is to structure
  a system as a number of tiers including
  presentation, application, and storage tier. All
  of these are supported by a layer of software
  which is relatively independent of a given
  application (e.g. networks and operating
  systems).

13
Possible Architecture

• The use of a three tier architecture is the core
  of a distributed application.
• Presentations tier HCI can go on the client and
  does not require to be transmitted over network.
  Usually a browser that can talk HTTP. The
  presentation tier should provide the essential
  logic for user interaction. The presentation tier
  would contain facilities which allow the user to
  interact with the stored data in the other tiers.
• Processing tier Business objects reflect domain
  entities i.e. Customer, Car, and Hiring Business
  objects shield the implementation of data, they
  are not just reflections of database tables. The
  application tier provides the essential logic for
  the particular system.
• Data or storage tier should handle persistence,
  usually requires files or a database.
• Support layers software such as middleware,
  operating systems, network software must be
  included.

14
Three tier architecture
15
Advantages of three-tier architecture

• A three-tier architecture is used mainly for
  maintenance reasons. Such an architecture
  allocates most of the code in the middle and data
  layer to the server, with the presentation layer
  residing on the client. This means that when a
  change occurs, for example a change to an
  object-to-database mapping, it only usually
  affects one copy of the software the part
  residing on the server. It also means that when a
  change in functionality occurs the effect on the
  presentation layer is minimised. Other advantages
  tiers and layers
• separation of function
• modular development
• building on work of others
• reusable components
• substitutable components
• use of standard protocols

16
Tiers mapped to system functions

• The presentation tier would enabled the customer
  to
• create a car booking
• check car availability at a given airport
• The presentation tier would enabled the an
  employee to
• retrieve the current status of a car
• check the history of a car
• The middle tier would contain business objects
  which would correspond to entities in the
  application. Typical business objects would
  include
• a cars details
• a booking details
• a maintenance history
• The database tier would usually contain
  relational tables which would store the business
  objects (need mapping between tables and
  objects). For example there would be a table
  which listed all the cars, customers, and a
  hiring related cars to cstomers.
• The support layers are important, but are usually
  support and are more concerned with
  implementation rather than analysis. However,
  they still provide the architecture with the
  advantage of reuse in general purpose features.

17
Software Architecture

• The UP analysis workflow includes the production
  of an architectural description
• This defines
• the top-level structure of subsystems
• the role and interaction of these subsystems
• Typical architectures are codified in patterns
• for example, layered architectures

18
A Layered Architecture

• Subsystems are shown as UML packages linked by
  dependencies
• A dependency without a stereotype means uses

19
Separation of Concerns

• Layers aim to insulate a system from the effects
  of change
• For example, user interfaces often change
• but the application layer does not use the
  presentation layer
• so changes to system should be restricted to
  presentation layer classes
• Similarly, details of persistent data storage are
  separated from application logic

20
Analysis Class Stereotypes

• Within this architecture objects can have various
  typical roles
• boundary objects interact with outside actors
• control objects manage use case behaviour
• entity objects maintain data
• These are represented explicitly in UML by using
  analysis class stereotypes

21
Class Stereotype Notation

• Stereotypes can be text or a graphic icon
• The icon can replace the normal class box

22
Class Stereotype Notation

• Entities (model) Objects representing system
  data, often from the domain model.
• Boundaries (view) Objects that interface with
  system actors (e.g. a user or external service).
  Windows, screens and menus are examples of
  boundaries that interface with users.

23
Class Stereotype Notation

• Controls (controller) Objects that mediate
  between boundaries and entities. These serve as
  the glue between boundary elements and entity
  elements, implementing the logic required to
  manage the various elements and their
  interactions. It is important to understand that
  you may decide to implement controllers within
  your design as something other than objects
  many controllers are simple enough to be
  implemented as a method of an entity or boundary
  class for example.

24
Restaurant Domain Model(4.10)
25
Restaurant Use Case Diagram(4.7)
26
Use Case Realization

• Begin with functionality in application layer
• Display Bookings simple dialogue
• the user provides the required date
• the system response is to update the display
• Initial realization consists of
• instance of the Staff actor
• an object representing the system
• message(s) passed between them

27
System Messages

• System messages are sent by an actor
• Represent system by a controller
• initially analysing use case behaviour, not I/O
• (Fig. 5.3)

28
Sequence Diagrams

• Time passes from top to bottom
• Instances of classes and actors at top
• only show those participating in this interaction
• each instance has a lifeline
• Messages shown as arrows between lifelines
• labelled with operation name and parameters
• return messages (dashed) show return of control
• activations show when receiver has control

29
Accessing Bookings

• How does the system retrieve the bookings to
  display?
• Which object should have the responsibility to
  keep track of all bookings ?
• if this was an additional responsibility of the
  BookingSystem object it would lose cohesion
• so define a new Restaurant object with the
  responsibility to manage booking data

30
Retrieving Bookings

• Add a message to get relevant bookings
• updateDisplay is an internal message
• (fig. 5.4)

31
Retrieving Booking Details

• Dates of individual bookings will need to be
  checked by the Restaurant object (fig. 5.5)

32
Refining the Domain Model

• This realization has involved
• new 'Restaurant' and 'BookingSystem' classes,
  with an association between them
• an association from Restaurant to Booking
• Restaurant maintains links to all bookings
• messages sent from restaurant to bookings
• an association from BookingSystem to Booking
• BookingSystem maintains links to currently
  displayed bookings

33
Updated Class Diagram

• Operations are derived from messages sent to the
  instances of a class (fig. 5.6)

34
Recording New Bookings

• Give Restaurant responsibility for creation
• dont model details of user input or data yet
  (fig. 5.7)

35
Creating a New Booking

• Bookings must be linked to table and customer
  objects
• responsibility of Restaurant to retrieve these,
  given identifying data in booking details
• New objects shown at point of creation
• lifeline starts from that point
• objects created by a message arriving at the
  instance (a constructor)

36
Creating a New Booking

• This completes the previous diagram (fig. 5.8)

37
Cancelling a Booking

• A three-stage process
• select on screen the booking to be cancelled
• confirm cancellation with user
• delete the corresponding booking object
• Object deletion represented by a message with a
  destroy stereotype
• lifeline terminates with an X
• Role names used to distinguish selected object
  from others displayed

38
Cancelling a Booking (fig 5.9)
39
Refining the Domain Model (2)

• BookingSystem has the responsibility to
  remember which booking is selected
• Add an association to record this (Fig. 5.10)

40
Recording Arrival (5.11)

• Selected booking must be a reservation

41
Class Interface Design

• Should setArrivalTime be defined in Booking or
  Reservation class?
• on the one hand, it doesn't apply to walk-ins
• but we want to preserve a common interface to all
  bookings if possible
• Define operation in Booking class
• default implementation does nothing
• override in Reservation class

42
Refined Class Hierarchy (5.12)
43
Summary

• Analysis has led to
• a set of use case realizations
• a refined class diagram
• We can see how the class design is going to
  support the functionality of the use cases
• This gives confidence that the overall design
  will work

44
Summary

• Analysis can be defined as the activity of
  representing the application domain and the
  systems requirement in terms of the object model
• The basic analysis technique is the production of
  use case realizations, which demonstrate how the
  functionality specified in a use case could be
  delivered by a set of interacting objects.

45
Summary

• Realizations can be documented using one of the
  forms of interaction diagram defined in UML i.e.
  collaboration or sequence diagrams.
• Producing use case realizations will suggest
  changes in the domain model, which will evolve
  into more detailed analysis class model.
• A central metaphor of object design is to make
  objects responsible for a subset of the data and
  operations in the system.

46
Summary

• The Unified Process includes an architectural
  description as one of the product analysis. A
  widely used architectural approach is to
  structure a system as a number of layers, for
  example presentation, application, and storage
  layer.
• The objects in a system can be assigned a number
  of roles, to clarify the organization of the
  system. UML defines class stereotypes boundary,
  control and entity objects

47
Summary

• User interaction can be shown on realizations by
  means of system messages received by control
  objects. There can be one control object per use
  case or one representing the system as a whole.

48
Complete Analysis Class Model (5.13)