Block VI

Software Development:
Detailed Design and
Implementation
 Chapter 45
Class Specification
The Detailed Design
 The detailed design is the final stage of
the design activity.
 It is concerned with specifying how the
structural model may be represented by
appropriate software components which
have the properties required to be able to
realise the system in the subsequent
implementation activity
Design Document
 The end-product of the detailed design
activity.
 It consists of a class specification for each
class in the system together with the
walk-throughs, sequence diagrams and
class diagram to which the class
specifications refer.
Class Specification
 A detailed specification of the instance
variables and methods that a class has to
define.
The detailed design stages
 The detailed design stages :

 Refining and representing the

inheritance structure.
 Representing attributes
 Representing associations
 Specifying protocols
1. Refining the initial inheritance
structure1

The aim of this task is to produce a well-

designed inheritance hierarchy that is
amenable to reuse
Refining the initial inheritance
structure
 An abstract superclass Person represents
the common behaviour shared by both the
doctors and patients in the hospital.
Ultimately, this abstract class could
represent other common behaviour shared
by people. The abstract class would be a
useful addition to our Smalltalk class library
and could be reused in other applications.
We call such a class implementation class.
 The person superclass inherits the Object
abstract class specified in the Smalltalk
class library.
Implementation Class
 Implementation classes do not appear in
the structural model, but are used in the
detailed design either to refine the
inheritance structure or to define the
objects that represent such things as
attribute values, association links and
method answers.
Application Class
 A class that represents a significant
category of entities in the specific
application area being modelled.
Application classes feature in the
structural model of a system.
Refining the initial inheritance
structure
Refining the initial inheritance
structure
 The responsibilities for the class Person that are needed for
the HAT system are as follows.

 By making Doctor and Patient subclasses of Person:

 We ensure that they inherit the attributes name and address
from Person.
 They also inherit getName from Person, but may override it if
the required behavior for Doctor and Patient instances is
different.
2.Attribute and Association
responsibilities
 In this section we consider how to represent the
responsibilities of an object for recording information
and for keeping track of other objects.

 These are the responsibilities that we have classified in

the structural model under the headings Attributes and
Associations, respectively.
Representing Attributes
 Attributes are represented in classes by
instance variables.

 For each such instance variable we must

consider the type of object(s) that it should
reference to meet its responsibility for
recording the required information.

 The values of the attributes might be simple

such as a single number or complex such as
a combination of several numbers.
Representing Attributes
 For the HAT system the attributes we need to represent are:

 Typical values for the first three attributes are given in the
following table.
Representing Attributes
 The name in Person is rather more
complicated.
 The person’s name contains many parts (title,
first name, initials, surname).
 It’s insufficient to represent it as a simple string; it
won’t highlight each part of the name.
 Bearing in mind the possible reuse of the Person

class, so we should consider other possibilities.

Representing Attributes
Representing Associations
 Associations require an object of a class to ‘keep
track’ of another object or objects.

 As with attributes, these responsibilities will be

represented in classes by instance variables set
up to reference instances of appropriate classes

 Example : To implement the isHeadedBy

association we need an instance variable in the
class Team. We will call this variable consultant.
Since the multiplicity of isHeadedBy at the
ConsultantDoctor end is 1, the instance variable,
consultant, in Team needs to reference only a
single instance of ConsultantDoctor
Representing Associations
Representing Associations

 In the case of Team’s responsibility for keeping

track of patients, the most appropriate choice is
Set.
This representation of the responsibility is shown
in the class specification table for Team as:
patients--->aSet(aPatient ...).
The following figure shows an object diagram
which is used to illustrate the situation of a team
caring for three patients:
Representing Associations
Representing Associations
 Summary of what we have done right now:
 We can represent all associations by means of instance
variables.
 An instance variable is required in each class that the
association is navigated from.
 i.e. in each class that has a ‘keep track of’ responsibility for
the association.
 Such an instance variable in an object references:
 The linked object if the multiplicity at the other end is ‘one’.
 A suitable collection of the linked objects when the multiplicity
at the other end is ‘many’.
3. Specifying protocols
 We now have to translate the specifications of
the protocols into specifications of the
methods that will implement the protocols.
 Much of a method specification will simply be a
copy of the corresponding message
specification.
 The main objective at this stage is:
 To ensure that the class of each argument and of
the expected answer is specified clearly.
3. Specifying protocols
 The sequence diagram for the List Patient's Treatment
use case (use case A):
3. Specifying protocols
 The sequence diagram for the List Team’s Patients use
case (use case B):
3. Specifying protocols
 The sequence diagram of the Admit Patient use case
(use case C):
3. Specifying protocols
 The sequence diagram for the Treat Patient use case
(use case D):
3. Specifying protocols
 The sequence diagram of the Discharge Patient use
case (use case E):
3. Specifying protocols
 In the class Team:
 The message getPatientsAndWards has to answer with a
collection of patients and wards.

 In the class Ward:

 The message getDoctors(aPatient) has to answer with a
collection of instances of Doctor.
3. Specifying protocols
 Most of the other messages that have significant answers
correspond to simple getter methods, such as:
 getConsultant in class Team simply answers with the object
which the instance variable consultant references.

 getWard (or ward), getDoctors (or doctors) and getTeam (or

team) in class Patient are all simple getter messages.
 Information of (dates of birth, ward names and team
codes) that is returned by the orchestrating instance to the
user interface is in the form of strings.
 Design Document
 The complete class specifications, together with
the walk-throughs and the sequence diagrams
comprise the design document.
The complete class specifications of
the HAT system