Post on 04-Jan-2016
transcript
CMSC 345 Fall 2000
Design
What is Design? Verb: The creative process of
transforming the problem into the solution
Noun: The description of the solution Typically multiple acceptable soultions Two types of design
Conceptual for the customer Technical for the developer
Conceptual Design Tells the customer what the system
will do Characteristics of Conceptual
Design Written in customer language No technical jargon Describes functions of the system Independent of the implementation Links to requirements documents
Conceptual Design (2) System defined by its boundaries,
entities, attributes and relationships Answer questions:
Where will the data come from? What will happen to the data in the system? What will the system look like to users? What choices will be offered to users? What is the timing of events? What will the reports and screens look like?
Technical Design More detailed than conceptual design Describes the form the system will take Description of major hardware
components and their interactions (if not part of problem space)
Hierarchy and function of software components (those not part of problem)
Major data structures used within system and data flow through system
WHAT HOW
Customers Systembuilders
CONCEPTUALDESIGN
TECHNICALDESIGN
function formSystemdesigners
CONCEPTUALDESIGN
TECHNICALDESIGN
“The user will be able to route messages to any other user on any other network computer.”
Network topologyProtocol usedPrescribed bps rate. . .
Decomposition and Modularity To design a system is to determine
a set of components and interfaces that satisfy the requirements.
Many ways to create good design, but….
Every design method involves some kind of decomposition
Design Strategies Functional design
system is designed from a functional viewpoint and progressively refined
The system state is centralized and shared between the functions operating on that state
Object-oriented design system is viewed as a collection of objects.
Based on the idea of information hiding The system state is de-centralized and each
object manages its own state. Objects may be instances of an object class and
communicate by exchanging methods
Design Stages (Sommerville) Architectural design Identify sub-systems Abstract specification Specify sub-systems Interface design Describe sub-system
interfaces Component design Decompose sub-systems
into components Data structure design Design data structures
to hold problem data Algorithm design Design algorithms for
problem functions
Design Methods (Wasserman) Modular decomposition: assign functions to
components Data-oriented decomposition: based on
external data structures. Event-oriented decomposition: based on
how events handled by system change the system state
Outside-in: black-box approached based on user inputs to the system
Object-Oriented : identifies classes of objects and their relationships
Toplevel
First level ofdecomposition
Second level ofdecomposition
Architectural Design Architecture: associates system
capabilities with components that will implement them, and their interconnections
Code: involves algorithms and data structures, primitives and compositions in terms of language primitives
Executable: memory allocation, data formats, bit patterns, etc.
Architectural Styles Pipes and Filters Object-Oriented Implicit Invocation Layering Repositories Process Control Others…
Pipes and Filter Architecture aka Data-Flow model Pipes are streams of data for input
and output Filters transform the input to
output Filters are independent and
“unaware” of other filters
FilterPipe
Invoice processing system
Read issuedinvoices
Identifypayments
Issuereceipts
Findpayments
due
Receipts
Issuepaymentreminder
Reminders
Invoices Payments
Pipe and Filter Plus and Minus Plus – Filters easily reused Plus – Easy to add/remove filters Plus – Easy to implement as concurrent
or sequential system Minus – Not good for interactive systems Minus – Independent filters may duplicate
(preparatory) processing Minus – Must maintain correspondence
between multiple data streams
Object Oriented Architecture Each component is an instance of an ADT.
Components must preserve integrity of data representation, keeping hidden from other objects
Decompose problem into system loosely coupled objects with well defined interfaces
However, each object must know identity of other objects it interacts with, and all objects that invoke a changed object must themselves be changed
Invoice processing system
IssueSend reminderAccept paymentSend receipt
invoice #dateamountcustomer
Invoice
customer #nameaddresscredit period
Customer
invoice #dateamountcustomer #
Receipt
invoice #dateamountcustomer #
Payment
OO Plus and Minus Plus – loosely coupled objects allow
changing implementation without affecting other objects
Plus – objects represent “real world” entities and are therefore reusable
Minus – objects must explicitly reference name and interface of other objects, so interface change affects all other objects
Minus – complex objects may be difficult to represent
Layering Architecture Models the interfacing of
subsystems Layers are hierarchical Each layer provides a service to the
one outside of it and is a client to the layer inside of it
Each layer is an increased level of abstraction
Users
Cryptography
File interface
Key management
Authentication
Layering Plus and Minus Plus – portable and changeable if the
interface between layers is preserved Plus – machine dependencies localized
in the inner layers Minus – structuring the system in this
way may be difficult Minus – multiple layers require multiple
levels of command interpretation which may affect performance
Client-Server Architecture Distributed system architecture Client requests action or service Server responds to the request Clients must know the name of the
available servers and the services they provide
Servers need not know the identity of clients or how many there are
Clients access services provide by a server through a remote procedure call
Film and picture library
Catalogueserver
Catalogue
Videoserver
Film clipfiles
Pictureserver
Digitizedphotographs
Hypertextserver
Hypertextweb
Client 1 Client 2 Client 3 Client 4
Wide-bandwidth network
Client-Server Plus and Minus Plus – clients get information only
when they need it. Plus – distribution is straightforward Plus – clients handle presentation
details Minus – require sophisticated
security, systems management, more resources to implement and support
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 and may execute
sequentially or in parallel
OOD Structure
state 3
O3
state 4
O4
state 1
O1
state 6
O6
state 5
O5
state 2
O2
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
OOD Method Commonality The identification of objects, their
attributes and services The organization of objects into an
aggregation hierarchy The construction of dynamic object-
use descriptions which show how services are used
The specification of object interfaces
Objects, Classes and Inheritance Objects are entities in a software
system which represent instances of real-world and system entities
Object classes are templates for objects. They may be used to create objects.
Object classes may inherit attributes and services from other object classes
A Mail_Message Object Class
SenderReceiver
Sender addressReceiver address
Date sentDate received
RouteTitleText
SendPresentFile
Mail message
ObjectsAn object is an entity which has a state and a defined set of
operations which operate on that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects (clients) which request these services when some computation is required. Objects are created according to some object class definition. An object class definition serves as a template for objects. It includes declarations of all the attributes and services which should be associated with an object of that class.
Object Communication Conceptually, objects communicate by
message passing. 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 calls Name = procedure name. Information = parameter list.
Inheritance Objects are members of classes which define
attribute types and operations Classes may be arranged in a class hierarchy
where one class is derived from an existing class (super-class)
A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own
A Class Hierarchy
Employee
NameAddressSalar yManager. . .
Programmer
ProjectProg languages
Manager
DeptStaffGrade. . .
Projectmanager
ProjectDate Appointed. . .
Advantages of Inheritance It is an abstraction mechanism which
may be used to classify entities It is a reuse mechanism at both the
design and the programming level The inheritance graph is a source of
organizational knowledge about domains and systems
Problems with Inheritance Object classes are not self-contained. they
cannot be understood without reference to their super-classes
Designers have a tendency to reuse the inheritance graph created during analysis. Can lead to significant inefficiency
The inheritance graphs of analysis, design and implementation have different functions and should be separately maintained
Object Identification Identifying objects 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
Approaches to Identification Use a grammatical approach based on a
natural language description of the system
Base the identification on tangible things in the application domain
Use a behavioral approach and identify objects based on what participates in what behavior
Use a scenario-based analysis,
Objects and Operations Nouns in the description give pointers to
objects in the system Verbs give pointers to operations
associated with objects Approach assumes that the designer
has a common sense knowledge of the application domain as not all objects and services are likely to be mentioned in the description
Static System Structure Object aggregation hierarchy
diagrams show the static system structure. They illustrate objects and sub-objects. This is NOT the same as an inheritance hierarchy
Aggregation Hierarchy
BarometerAir
thermometerGround
ther mometer Rain gauge Wind vane Anemometer
Weatherdata Instr uments Clock Comms
Met.data
Weather *station
Mapdatabase
Weathermap
Weathermappingsystem
. . . . . . . . .
. . .. . .
Dynamic System Structure Object-service usage diagrams
illustrate how objects use other objects. They show the messages passed (procedures called) between objects
Object Interactions
RainfallGround temp .
dataAir temp.
dataWind direction
data PressureWind speed
data
Cumulative Readings Average AverageMax. gust
MaximumMinimumAverage
Weatherdata
Processdata
Weatherstation
Transmitdata
Transmitdata
Comms Comms
Object Interface Design Concerned with specifying the detail of
the object interfaces. This means defining attribute types and the signatures and semantics of object operations
Representation information should be avoided
Precise specification is essential so a programming language description should be used
C++ Interfaceclass Weather_station {public: Weather_station () ; ~Weather_station () ; void Transmit_data (computer_id dest) ; void Transmit_status (computer_id dest) ; void Self_test () ; void Shut_down () ;
// Access and constructor functionschar* Identifier () ;void Put_identifier (char* Id) ;instrument_status Inst_status () ;void Put_instrument_status (Instrument_status ISD) ;weather_data_rec Weather_data () ;void Put_weather_data (weather_data_rec WDR) ;
private: char* station_identifier ; weather_data_rec Weather_data ; instrument_status inst_status ;} ;
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
OO Key Points OOD is design with information hiding.
Representations may be changed without extensive system modifications
An object has a private state with associated constructor and access operations. Objects provide services (operations) to other objects.
Object identification is a difficult process. Identifying nouns and verbs in a natural language description can be a useful starting point for object identification.
OO Key Points Object interfaces must be precisely
defined. A programming language such as Ada or C++ may be used for this
Useful documentation of an OOD include object hierarchy charts and object interaction diagrams