©ian sommerville 2000 software engineering, 6th edition. chapter 12slide 1 software design l...
TRANSCRIPT
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 1
Software Design
Objectives• To explain how a software design may be represented as
a set of interacting objects that manage their own state and operations
• To introduce various models that describe an object-oriented design
• To show how the UML may be used to represent these models
• To introduce design patterns
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 2
Characteristics of OOD Objects are abstractions of real-world or system entities
and manage themselves Objects are independent and encapsulate state and
representation information. System functionality is expressed in terms of object
services Shared data areas are eliminated
• Objects communicate by message passing
Objects may be distributed Objects may execute sequentially or in parallel
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 3
Interacting objects
state o3
o3:C3
state o4
o4: C4
state o1
o1: C1
state o6
o6: C1
state o5
o5:C5
state o2
o2: C3
ops1() ops3 () ops4 ()
ops3 () ops1 () ops5 ()
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 4
Advantages of OOD Easier maintenance. Objects may be
understood as stand-alone entities Objects are appropriate reusable components For some systems, there may be an obvious
mapping from real world entities to system objects
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 5
Object-oriented development Object-oriented analysis, design and
programming are related but distinct OOA is concerned with developing an object
model of the application domain OOD is concerned with developing an object-
oriented system model to implement requirements OOP is concerned with realising an OOD using
an OO programming language such as Java or C++
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 6
Objects and object classes Objects are entities in a
software system which represent instances of real-world and system entities
Object classes are templates for objects
• Classes may be used to create objects
Object classes may inherit attributes and services from other object classes
Employee
name: stringaddress: stringdateOfBirth: DateemployeeNo: integersocialSecurityNo: stringdepartment: Deptmanager: Employeesalary: integerstatus: {current, left, retired}taxCode: integer. . .
join ()leave ()retire ()changeDetails ()
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 7
Object communication Conceptually, objects communicate by
message passing Messages
• The name of the service requested by the calling object.• Copies of the information required to execute the service
and the name of a holder for the result of the service.
In practice, messages are often implemented by procedure (a.k.a. method) calls• Name = method name• Information = parameter list• Result holder = method return value
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 8
Message examples
// Call a method associated with a buffer // object that returns the next value // in the buffer
v = circularBuffer.Get () ;
// Call the method associated with a// thermostat object that sets the // temperature to be maintained
thermostat.setTemp (20) ;
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 9
Generalisation and inheritance Objects are members of classes which define attribute types
and operations Classes may be arranged in a class hierarchy where one class
(a super-class) is a generalisation of one or more other classes (sub-classes)
A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own
It is a reuse mechanism at both the design and the programming level
Inheritance introduces complexity and this is undesirable, especially in critical systems
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 10
A generalisation hierarchyEmployee
Programmer
projectprogLanguage
Manager
ProjectManager
budgetsControlled
dateAppointed
projects
Dept.Manager
StrategicManager
dept responsibilities
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 11
Object Relationships Objects and object classes participate in
relationships with other objects and object classes• In UML, such a relationship is indicated by an association
Associations may be annotated with information that describes the association
EmployeeDepartment
Manager
is-member-of
is-managed-by
manages
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 12
Concurrent objects The nature of objects as self-contained entities
make them suitable for concurrent implementation
The message-passing model of object communication can be implemented directly if objects are running on separate processors in a distributed system
Active objects have an internal thread of control and may change their own state
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 13
Object identification Identifying objects (or object classes) is the most
difficult part of object oriented design There is no “magic formula” for object
identification• It relies on the skill, experience
and domain knowledge of system designers
Object identification is an iterative process• You are unlikely to get it right first time
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 14
Approaches to identification Use a grammatical approach based on a natural
language description of the system (used in Hood method)
Base the identification on tangible things in the application domain
Use a behavioural approach and identify objects based on what participates in what behaviour
Use a scenario-based analysis – the objects, attributes and methods in each scenario are identified
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 15
Object interface specification Object interfaces have to be specified so that the
objects and other components can be designed in parallel
Designers should avoid designing the interface representation but should hide this in the object itself
Objects may have several interfaces which are viewpoints on the methods provided
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 16
Identifying HazMat Rover Objects
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 17
Design models Design models show the objects and object
classes and relationships between these entities Static models describe the static structure of the
system in terms of object classes and relationships
Dynamic models describe the dynamic interactions between objects.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 18
Examples of design models Sub-system models that show logical groupings of objects
into coherent subsystems• UML package diagrams
Sequence models that show the sequence of object interactions
• UML sequence diagrams State machine models that show how individual objects
change their state in response to events• UML statechart diagrams
Other models include use-case models, aggregation models, generalisation models,etc.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 19
Weather station subsystems«subsystem»
Interface
CommsController
WeatherStation
«subsystem»Data collection
«subsystem»Instruments
Air thermometer
WeatherData
Ground thermometer
Anemometer
WindVane
RainGauge
InstrumentStatus
Barometer
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 20
Weather stationdata collection sequence
:CommsController
request (report)
acknowledge ()report ()
summarise ()
reply (report)
acknowledge ()
send (report)
:WeatherStation :WeatherData
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 21
Statecharts Object states State transitions triggered by requests to objects
Shutdown Waiting Testing
Transmitting
Collecting
Summarising
Calibrating
transmission done
calibrate ()
test ()startup ()
shutdown ()
calibration OK
test complete
weather summarycomplete
clock collectiondone
Operation
reportWeather ()
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 22
Design patterns A design pattern is a way of reusing abstract
knowledge about a problem and its solution A pattern is a description of the problem and the
essence of its solution It should be sufficiently abstract to be reused in
different settings Patterns often rely on object characteristics such
as inheritance and polymorphism
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 23
Pattern elements Name
• A meaningful pattern identifier
Problem description Solution description
• Not a concrete design but a template for a design solution that can be instantiated in different ways
Consequences• The results and trade-offs of applying the pattern
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 24
Multiple displaysenabled by Observer
Subject
A: 40B: 25C: 15D: 20
Observer 1 Observer 2
0
50
25
A B C D
A
B
C
D
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 25
The Observer pattern Name
• Observer
Description• Separates the display of object state from the object itself
Problem description• Used when multiple displays of state are needed
Solution description• See slide with UML description
Consequences• Optimisations to enhance display performance are impractical
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 26
The Observer pattern
Subject Observer
Attach (Observer)Detach (Observer)Notify ()
Update ()
ConcreteSubject
GetState ()
subjectState
ConcreteObserver
Update ()
observerState
return subjectState
for all o in observers o -> Update ()
observerState = subject -> GetState ()
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12 Slide 27
OOD is an approach to design in which design components have private state and operations
Objects provide services to other objects Objects may be implemented sequentially or
concurrently The Unified Modeling Language provides different
notations for defining different object models Object-oriented design simplifies system evolution Design patterns are generic, reusable design templates
Key points