• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Ppt slides 05
 

Ppt slides 05

on

  • 1,278 views

 

Statistics

Views

Total Views
1,278
Views on SlideShare
1,278
Embed Views
0

Actions

Likes
0
Downloads
13
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Ppt slides 05 Ppt slides 05 Presentation Transcript

    • PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 5: Restaurant System: Analysis
    • Analysis
      • What is to be analyzed?
        • the system requirements
      • Why?
        • to demonstrate their implementability
      • How?
        • by drawing interaction diagrams realizing use cases
    • 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
    • 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
    • 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
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • 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
    • 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).
    • 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.
    • Three tier architecture
    • 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
    • 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.
    • 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
    • A Layered Architecture
      • Subsystems are shown as UML packages linked by dependencies
      • A dependency without a stereotype means uses
    • 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
    • Analysis Class Stereotypes
      • Within this architecture objects can have various typical roles
        • boundary objects interact with outside actors
        • control objects manage use case behaviour
        • e ntity objects maintain data
      • These are represented explicitly in UML by using analysis class stereotypes
    • Class Stereotype Notation
      • Stereotypes can be text or a graphic icon
      • The icon can replace the normal class box
    • Restaurant Domain Model(4.10)
    • Restaurant Use Case Diagram(4.7)
    • 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
    • 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)
    • 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
    • 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
    • Retrieving Bookings
      • Add a message to get relevant bookings
      • ‘ updateDisplay’ is an internal message
      • (fig. 5.4)
    • Retrieving Booking Details
      • Dates of individual bookings will need to be checked by the ‘Restaurant’ object (fig. 5.5)
    • 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
    • Updated Class Diagram
      • Operations are derived from messages sent to the instances of a class (fig. 5.6)
    • Recording New Bookings
      • Give ‘Restaurant’ responsibility for creation
        • don’t model details of user input or data yet (fig. 5.7)
    • 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 )
    • Creating a New Booking
      • This completes the previous diagram (fig. 5.8)
    • 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
    • Cancelling a Booking (fig 5.9)
    • Refining the Domain Model (2)
      • ‘ BookingSystem’ has the responsibility to remember which booking is selected
      • Add an association to record this (Fig. 5.10)
    • Recording Arrival (5.11)
      • Selected booking must be a reservation
    • 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
    • Refined Class Hierarchy (5.12)
    • 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
    • Summary
      • Analysis can be defined as the activity of representing the application domain and the system’s 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.
    • 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.
    • 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
    • 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.
    • Complete Analysis Class Model (5.13)