Chapter 12: Low Level Design

1
Chapter 12 Low Level Design

• 12.1 Introduction
• We will see a systematic way to perform OOD using
  design patterns, and a responsibility-driven
  approach
• A good way to design a solution in terms of
  collaborating objects is to think in terms of
  responsibilities
• A pattern is a named and well-known
  problem/solution pair that can be applied in new
  contexts, with advice on how to apply it in novel
  situations and discussion of its trade-offs,
  implementations, variations, and so forth
• There are hundreds of OO design patterns, only a
  few a fundamentals
• Patterns do not express new software engineering
  ideas quite the opposite in fact. Patterns
  codifies good solutions to well-known recurring
  problems. In fact many OOD patterns originate
  from traditional non-OO software engineering
• Patterns have names which allow easier
  communication we can talk of the low-coupling
  pattern, or the controller pattern and everyone
  knows what is being talked about.

2
(No Transcript)
3

• 12.2 Case Study
• Going back to the Point of Sale business
  application ... (see previous artifacts)
• For the current iteration, and the Process Sale
  use case, the following system operations have
  been identified
• makeNewSale
• enterItem
• endSale
• makePayment
• These system operations, as identified previously
  in the system sequence diagram, form the starting
  points of interaction diagrams

4

• Fig 12.1 Sequence diagrams and system operation
  handling

5

• We also use all the documentation at our
  disposal
• Use cases
• Supplementary specification
• Vision
• UI prototypes
• Etc.
• but remember that written requirements are most
  of the time imperfect (incomplete, misleading
  etc.)
• Hence, remember to involve stakeholders as much
  as possible
• it is hard to beat the ongoing participation of
  customers in evaluating demos, discussing
  requirements and tests, prioritizing, and so
  forth.
• Remember that one of the Agile method principle
  is "Business people and developers must work
  together daily throughout the project.

6
Fig 12.2 POS Domain Model
7
Fig 12.3 POS SSD
8

• 12.3 POS Case Study Design
• We consider each actor-generated event, and
  design algorithms by assigning responsibilities
  to objects using design patterns.
• 12.3.1 makeNewSale System Operation
• The makeNewSale system operation occurs when a
  cashier initiates a request to start a new sale,
  after a customer has arrived with things to buy.
• What needs to be done? What changes in the
  underlying objects when this event occurs?
• An informal object diagram that respects the
  current class diagram helps to clarify the
  changes necessary
• Who should be the controller for this event?

9

• Choosing the controller class
• Who in the, domain layer, should be responsible
  for handling this system event? By the controller
  pattern here are some candidates
• Facade controllers Store, Register, POSSystem
• Pure Fabrications ProcessSaleHandler,
  ProcessSaleSession
• At the moment Register is suitable most logical
  (unlike Store), not too many system operations at
  the moment (no risk of bloated controller)

10

• Creating a new Sale
• Who should be responsible for creating a new
  SaleSo far we have created this sequence diagram
  

11

• Have we finished?
• But what about the container (aka the data
  structure) of SaleLineItems?
• We may as well create an empty one during the
  creation of a new Sale (or it could be created
  later ...).
• What kind of data structure to use is also a
  design decision...
• Hence the Register creates the Sale, and the Sale
  creates an empty collection, represented by a
  multi-object (aka a container, a collection etc.)
  in the sequence diagram.
• So far we have created the sequence diagram Fig
  12.4

12

• Fig 12.4 makeNewSale Sequence Diagram

13

• 12.3.2 enterItem System Operation
• The enterItem system operation occurs when a
  cashier enters the itemID and (optionally) the
  quantity of something to be purchased.
• Simulation using an object diagram - that
  respects the class diagram (obviously !) ...

14

• Choosing the controller class
• We usually use the same controller class for all
  the system operations of a use case
• Hence we stick with Register
• We must not forget to look at the use cases it
  says that on each item being entered its
  description and price are displayed
• Not part of the contract, because it has no
  effect on domain layer objects
• In fact here, as long as we have the information
  about items description and price (which we
  obviously do according to the domain model), the
  domain objects are not involved displaying
  information is not the responsibility of domain
  objects.
• Creating a new SalesLineItem
• Using the Creator pattern, a clear candidate is
  obviously the current Sale object (in addition
  consider focus of control according to the system
  sequence diagram).

15

• Finding a ProductDescription
• (NB we do not need the Item class from the
  domain model in this iteration since we will not
  take into account stock control in this
  iteration)
• The SalesLineItem needs to be associated with the
  ProductDescription that matches the incoming
  itemID. This implies that we must retrieve a
  ProductDescription, based on an itemID match.
• Who should be responsible for knowing a
  ProductDescription, based on an itemID match?
• Using the Expert pattern, and since, by the
  domain model, the ProductCatalog contains the
  ProductDescriptions, the ProductCatalog is a good
  candidate for the lookup responsibility.
• Now, who should be responsible for sending a
  getProductDescription message to the
  ProductCatalog? According to the domain model it
  should be the store.
• Performance discussion

16

• Hence, we have decided that the Registers will
  have direct visibility to the ProductCatalog
  (created at startup) this increases the
  coupling but may well be necessary on performance
  grounds.
• NB for an object to send a message to another
  object, it must have visibility to it.
• Below, is the interaction diagram for the
  enterItem system operation.

17

• Design Class Diagram so far

• Note the two dependency relationships

18

• 12.3.3 endSale System Operation
• The endSale system operation occurs when a
  cashier presses a button indicating the end of
  entering line items into a sale.
• ... Object diagram ...
• As decided, Register is the controller class
• Who should be responsible for setting the
  isComplete attribute of the Sale to true? By
  expert, the Sale itself, and the Register will
  send a message to it to that effect.
• See Figure 12.5 for the corresponding
  interaction diagram.

19

• Figure 12.5 the endSale system operation.

• 12.3.4 Other, Non-Actor, Responsibilities
• Remember UI related matters, and non actor
  generated operations...
• In this case study, and closely reading the
  current use case, we discover that the sale total
  needs to be displayed as currently no one class
  knows the sale total it needs to be calculated.
  

20

• Here is the detailed design process
• Who should be responsible for knowing the sale
  total?
• We need to know
• The sale total is the sum of the subtotals of all
  the sales line-items.
• sales line-item subtotal line-item quantity
  product description price
• Who are the experts?

• Hence the Sale should be responsible for knowing
  its own total since it knows about all the
  SalesLineItem instances.

21

• Who should be responsible for calculating the
  SalesLineItem subtotal? By Expert, it should be
  the SalesLineItem itself, since it knows the
  quantity and the ProductDescription it is
  associated with.
• Further, ProductDescription will have the
  responsibility of knowing its price, implemented
  as a getPrice operation.
• That was very detailed here is the result

22

• We can also had more detailed algorithm
  information to clarify the diagram

23

• 12.3.5 makePayment System Operation
• The makePayment system operation occurs when a
  cashier enters the amount of cash tendered for
  payment.
• Simulation ...

24

• Creating the new Payment instance
• Using the Creator pattern two candidates emerge
  the Register (closer to real-world situation,
  and also because it has all the initialisation
  information), and the Sale (according to the
  domain model).
• Since we have two clear candidates we must
  consider the cohesion and coupling consequences
  of either choices.
• As seen in the last chapter this leads to
  deciding that the Sale should be responsible for
  a creating the payment, and the Register telling
  the Sale to do so (since it is the controller).
• This leads us to the following interaction
  diagram so far which satisfies 3 postconditions
  in the contract the Payment has been created,
  associated with the Sale, and its amountTendered
  has been set

25

• Logging the Sale
• If we use our domain model and use the expert
  pattern then the following rough sequence of
  messages could possible
• Log_current_sale from Register to Store, and then
  from Store to Ledger. This is a good solution
  because it separates the store from the
  historical log of all sales the Store instance
  remains cohesive.
• Note that our contract is actually wrong
  according to our domain model
• If we didnt think of the Ledger class (as would
  be typical during analysis) then the simpler
  sequence of messages would work
• Log_current_sale from Register to Store. This is
  a simpler solution which may lead to
  incohesiveness in the Store class.
• Just to show that we do not have to follow the
  domain model blindly, and although it is the
  better solution, we eliminate the Ledger class
• Hence the interaction diagram for makePayment is

26
(No Transcript)
27

• 12.3.6 Other, Non-Actor, Responsibilities
• Calculating the Balance
• According to the use case
• Because of the Model-View Separation principle,
  we should not concern ourselves with how the
  balance will be displayed or printed, but we must
  ensure that it is known. Note that no class
  currently knows the balance, so we need to create
  a design of object interactions that satisfies
  this requirement.
• Who is responsible for knowing the balance?
• To calculate the balance, we need the sale total
  and payment cash tendered. Therefore, Sale and
  Payment are partial Experts on solving this
  problem.
• If the Payment is primarily responsible for
  knowing the balance, it needs visibility to the
  Sale, to ask the Sale for its total. Since it
  does not currently know about the Sale, this
  approach would increase the overall coupling in
  the design it would not support the Low Coupling
  pattern.

28

• In contrast, if the Sale is primarily responsible
  for knowing the balance, it needs visibility to
  the Payment, to ask it for its cash tendered.
  Since the Sale already has visibility to the
  Payment, as its creator, this approach does not
  increase the overall coupling and is therefore a
  preferable design

29

• 12.3.7 Complete Design Class Diagram for Domain
  Layer of Iteration 1

30

• 12.3.8 Connecting the UI Layer
• The UI layer that will run on the actual register
  hardware (the till) must be able to communicate
  to the domain layer of the application
  (containing the Store, Register, Sale classes
  etc.)
• Note that the domain layer will probably not run
  (at least entirely) on the register hardware it
  will be a physically distributed system with may
  be 20 register hardware, an application server
  (for the domain layer), a database server (for
  the catalog, possibly containing an up-to-date
  image of a national catalog). Possibly another
  database server local to the store will contain
  backups of all the sales to be updated daily too.
• So we can assume for now that the UI of the
  register will be passed at least one reference to
  a domain object (e.g. the Store, or the Register)
  whenever it is created.

31

• Once the UI has a connection to the Register
  instance (the facade controller in this design),
  it can forward system event messages, such as the
  enterItem and endSale message, to it

32

• The UI may also need to have access to other
  domain objects (e.g. the current Sale to ask
  about its total in other words for non system
  operations). Two solutions
• Everything goes through the Controller (the
  Register here) the UI sends the getTotal message
  to the Register, which delegates to the Sale.
  This has the possible advantage of maintaining
  lower coupling from the UI to the domain layer
  the UI only knows of the Register object. But it
  starts to expand the interface of the Register
  object, making it less cohesive.
• A UI asks for a reference to the current Sale
  object, and then when it requires the total (or
  any other information related to the sale), it
  directly sends messages to the Sale. This design
  increases the coupling from the UI to the domain
  layer.
• Low coupling is always attractive ... but so is
  maintaining high cohesion ... its a compromise
  ... There is no clear best solution here.
• Here is the design to the second solution

33
(No Transcript)
34

• 12.3.9 Initialisations and the Start Up Use Case
• We need to consider Start Up so that we can
  deliver an executable increment at the end of
  this iteration.
• We need to decide which initial object from
  domain layer needs to be created by the main
  application
• Here obviously the Store should be the first
  object created at startup.
• Hence the store instance will be responsible for
  initialising the rest of the domain layer.
• According to our current design class diagram
  (which reflects our current information needs)
  our current initialisation needs are

35

• Create a Store, Register, ProductCatalog, and
  ProductDescriptions.
• Associate the ProductCatalog with
  ProductDescriptions.
• Associate Store with ProductCatalog.
• Associate Store with Register.
• Associate Register with ProductCatalog.
• Mostly using the Creator pattern we obtain the
  interaction diagram shown in Figure 12.6.

36

• Figure 12.6 Design for the start up use case

37

• 12.4 Conclusions
• Remember the Agile Manifesto e.g. Model the
  creative, difficult parts of the design using
  UML. The UML should be a tool not a hindrance
  especially during modeling sessions tidy up
  later.
• During the UP elaboration phase, requirements can
  change update use cases, vision, supplementary
  documents as you go along.
• If the design is done properly, it will allow the
  software to be modified easily at coding time
• Adding error handling considerations
• Improving performance
• Allowing thorough testing and efficient
  debugging
• Also, future iterations (for Elaboration or
  Construction phase) will be able to build upon a
  well designed set of collaborating objects.

38

• 12.4.1 Patterns Summary
• Creator Pattern
• Problem Who should be responsible for creating a
  new instance of some class?
• Solution Assign class B the responsibility to
  create an instance of class A (to make B the
  creator of A objects) if one of these is true
• B contains, compositely aggregates, or records A.
• B closely uses A.
• B has the initializing data for A that will be
  passed to A when it is created. Thus B is an
  Expert with respect to creating A.
• Expert Pattern
• Problem What is a general principle of assigning
  responsibilities to objects?
• Solution Assign a responsibility to the
  information expert, the class that has the
  information necessary to fulfil the
  responsibility.

39

• Low Coupling Pattern
• Problem How to support low dependency, low change
  impact, and increased reuse?
• Solution Assign a responsibility so that coupling
  remains low. Use this principle to evaluate
  alternatives.
• Controller Pattern
• Problem What first object beyond the UI layer
  receives and coordinates ("controls") a system
  operation?
• Solution Assign the responsibility to a class
  representing one of the following choices
• Represents the overall "system," a "root object,"
  a device that the software is running within, or
  a major subsystem (aka a facade controller).
• Represents a use case scenario within which the
  system event occurs, often named
  ltUseCaseNamegtHandler, ltUseCaseNamegtCoordinator,
  or ltUseCaseNamegtSession (use case or session
  controller).
• Use the same controller class for all system
  events in the same use case scenario.

40

• High Cohesion Pattern
• Problem How to keep objects focused,
  understandable, and manageable, and as a side
  effect, support Low Coupling?
• Solution Assign a responsibility so that cohesion
  remains high. Use this to evaluate alternatives.
• The 5 patterns above are fundamental, they were
  used to create the solution explored in this
  chapter.