Flextier problem

This is a rather cryptic report on the 2001 designfest group, in the tuesday full-day session, that worked on the flextier problem. Except for me all the guys had a first name starting with an "A", and the girls where colleagues.

Assumption:

• Deliveries are within the context of the Mobile Telephone Network Operators. But the larger purpose is to extend the solution to go across other domains.
• Customers are persons, instead of entities or companies.

Observations

There are 2 actors - top and bottom; so how to make flexible?

Missing authentication and validation.

What does flexible mean?

Is easy to change individual service must not change service API?

API is extendible?

Easy to add services?

Actors

• from the Presentation Tier

  1. Customer
  2. Customer Representative
  3. Operational

• Maintainer functions

  1. Service Configuration
  2. Developer
• Legacy Systems
• ** No time based actors
• ** No external Systems

Use Cases

Presentation Tier:

• Create Customer
• Maintain Customer
• Maintain Contract
• Search Customer
• Add Contract
• Validation
  • Customer Address validation
  • Blacklist Validation

Maintainer

• Define current services Create configuration file
• start service
• start all services
• stop service
• stop all services
• 1. System presents services
  2. Actor chooses appropriate service
  3. Actor defines service sequence

Classes/Objects

• Service

  

  Purpose

  1. To store information about a service

  Responsibilities

  1. Be available to be called
  2. Know its properties
  3. Apply its properties to its behavior??
  4. Manipulate its properties

  Collaborations

  1. Service set

• Service set

  

  Purposes

  1. To group a number of services together that creates some sort of domain or module?
  2. Also to be able to know the order of service invocation (which is kind of business rule in itself?)
  3. To be able to be called just like a simple services (and the presentation tier isn't aware of it)

  Responsibilities

  1. Lists services that make up a certain set or domain
  2. Order the services

  Collaborations

  1. Service
  2. Just about all other candidates (customer, contract, blacklist)

• Customer

  

  Responsibilities

  1. Hold client data
  2. Validate input/output
  3. Know representation?

  Collaborations

  1. Contract
  2. Service Set
  3. Service
  4. Blacklist
  5. Address

• Address

  

  Responsibilities

  1. Hold address data
  2. Validate io
  3. Know representation

  Collaborations

  1. Customer

• Blacklist

  

  Purpose

  1. This candidate keeps or maintains all information about blacklists

  Responsibilities

  1. Creates an empty blacklist
  2. searches for a customer in the blacklist. Equality is by value
  3. Delete customer blacklist, delete customer from blacklist
  4. Retrieves how many elements the blacklist has
  5. Confirms whether a blacklist is empty
  6. Confirms whether the customer is in the blacklist or not
  7. Adds elements (customers) to blacklist, no repetitions allowed
  8. Gets the reason of why the customer is in the blacklist.

  Collaborations

  1. Customer (either identified by customer id or the whole customer object)
  2. Reason (is it a class or property?)

  Questions/issues

  1. Is history something that is required, i.e. was this customer in the blacklist before?

• Contract

  

  Responsibilities

  1. Contains information about what kind of features are available for the "customer" and what the responsibilities of the customer are
  2. Contracts for the customers are to be accessible through services (?)
  3. Defines the phone numbe (ID)
  4. Constraint: has to be created before added to the customer

  Collaborations

  1. Customer
  2. Service (?)

Sequence Diagram

Annotation: Calling the GetProperties method brings up a complexity concerning the mapping of properties to services. The issue is: Are you calling GetProperties for a hierarchy of services, or are you calling GetProperties as you traverse the hierarchy of services.

Service Specification annotation: If we make it that flexible, it knows what kind of information it needs (because it does the lookup). The issue is that we don't pass any parameters to it, because again it is THAT flexible.

The ice-cream presentation