1 chapter 13 design concepts and principles. 2 software design design is an overloaded term. =...
TRANSCRIPT
1
Chapter 13 Chapter 13 Design Concepts and Design Concepts and
PrinciplesPrinciples
2
Software Software DesignDesign
DESIGN is an overloaded term.DESIGN is an overloaded term.
= entire development of a system.= entire development of a system. = design of architecture = design of architecture (host, c/s, client)(host, c/s, client) = design of software components and their = design of software components and their
collaborationcollaboration = design of individual components (classes. = design of individual components (classes. = design of an individual structure of a attribute= design of an individual structure of a attribute = design of an individual method or function = design of an individual method or function
3
SofSoftwtware are arcarchithitectectureure
This design process is for identifying This design process is for identifying the sub-systems making up a system the sub-systems making up a system and the framework for sub-system and the framework for sub-system control and communication is control and communication is architectural designarchitectural design
The output of this design process is a The output of this design process is a description of thedescription of the software software architecturearchitecture
4
ArcArchithitectecturaura
l l desdesignign
An early stage of the entire system An early stage of the entire system design process.design process.
Represents the link between Represents the link between specification by the user and and the specification by the user and and the design processes for each component.design processes for each component.
Often carried out in parallel with Often carried out in parallel with some specification activitiessome specification activities
It involves identifying major system It involves identifying major system components and their components and their communicationscommunications
5
ArcArchithitectecturaura
l l desdesign ign proprocescesss
System structuringSystem structuringThe system is decomposed into several The system is decomposed into several
principal sub-systems and communications principal sub-systems and communications between these sub-systems are identifiedbetween these sub-systems are identified
Control modellingControl modellingA model of the control relationships A model of the control relationships
between the different parts of the system between the different parts of the system is establishedis established
Modular decompositionModular decompositionThe identified sub-systems are The identified sub-systems are
decomposed into modulesdecomposed into modules
6
Architectural modelsArchitectural models
As related to overloaded definition of DESIGNAs related to overloaded definition of DESIGN
Different architectural models may be produced Different architectural models may be produced during the design processduring the design process
Each model presents different perspectives on the Each model presents different perspectives on the architecturearchitecture
Static structural model that shows the major system Static structural model that shows the major system componentscomponents
Dynamic process model that shows the process Dynamic process model that shows the process structure of the systemstructure of the system
Interface model that defines sub-system interfacesInterface model that defines sub-system interfaces Relationships model such as a data-flow modelRelationships model such as a data-flow model
7
Architecture attributesArchitecture attributes
PerformancePerformance Localize operations to minimise sub-system Localize operations to minimise sub-system
communicationcommunication
SecuritySecurity Use a layered architecture with critical assets in inner Use a layered architecture with critical assets in inner
layerslayers
SafetySafety Isolate safety-critical componentsIsolate safety-critical components
AvailabilityAvailability Include redundant components in the architectureInclude redundant components in the architecture
MaintainabilityMaintainability Use fine-grain, self-contained componentsUse fine-grain, self-contained components
8
SysSystetem m strstructucturiuringng
Concerned with decomposing the Concerned with decomposing the system into interacting sub-systemssystem into interacting sub-systems
The architectural design is normally The architectural design is normally expressed as a block diagram expressed as a block diagram presenting an overview of the presenting an overview of the system structuresystem structure
More specific models showing how More specific models showing how sub-systems share data, are sub-systems share data, are distributed and interface with each distributed and interface with each other may also be developedother may also be developed
9
The repository ((mainframe) The repository ((mainframe) modelmodel
Sub-systems must exchange data. Sub-systems must exchange data. This may be done in two ways:This may be done in two ways:Shared data is held in a central database or Shared data is held in a central database or
data repository and may be accessed by all data repository and may be accessed by all sub-systems on the same hardwaresub-systems on the same hardware
Each sub-system maintains its own Each sub-system maintains its own database and passes data explicitly to other database and passes data explicitly to other sub-systemssub-systems
When large amounts of data are to When large amounts of data are to be shared, the repository model of be shared, the repository model of sharing is most commonly usedsharing is most commonly used
10
Repository model Repository model characteristicscharacteristics AdvantagesAdvantages
Efficient way to share large amounts of dataEfficient way to share large amounts of dataSub-systems need not be concerned with how data Sub-systems need not be concerned with how data
is produced Centralised management e.g. backup, is produced Centralised management e.g. backup, security, etc.security, etc.
Sharing model is published as the repository schemaSharing model is published as the repository schema
DisadvantagesDisadvantagesSub-systems must agree on a repository data model. Sub-systems must agree on a repository data model.
Inevitably a compromiseInevitably a compromiseData evolution is difficult and expensiveData evolution is difficult and expensiveNo scope for specific management policiesNo scope for specific management policiesDifficult to distribute efficientlyDifficult to distribute efficiently
11
CliClientent
--serserver ver arcarchithitectectureure
Distributed system model which shows Distributed system model which shows how data and processing is distributed how data and processing is distributed across a range of componentsacross a range of components
Set of stand-alone servers which Set of stand-alone servers which provide specific services such as provide specific services such as printing, data management, etc.printing, data management, etc.
Set of clients which call on these Set of clients which call on these servicesservices
Network which allows clients to access Network which allows clients to access serversservers
12
Client-server characteristicsClient-server characteristics
AdvantagesAdvantagesDistribution of data is straightforwardDistribution of data is straightforwardMakes effective use of networked systems. May Makes effective use of networked systems. May
require cheaper hardwarerequire cheaper hardwareEasy to add new servers or upgrade existing serversEasy to add new servers or upgrade existing servers
DisadvantagesDisadvantagesNo shared data model so sub-systems use different No shared data model so sub-systems use different
data organisation. data interchange may be inefficientdata organisation. data interchange may be inefficientRedundant management in each serverRedundant management in each serverNo central register of names and services - may be No central register of names and services - may be
hard to determine servers and services are availablehard to determine servers and services are available
13
AbAbstrstract act mamachichine ne momodeldel
Used to model the interfacing of sub-Used to model the interfacing of sub-systemssystems
Organizes the system into a set of Organizes the system into a set of layers (or abstract machines) each of layers (or abstract machines) each of which provide a set of serviceswhich provide a set of services
Supports the incremental development Supports the incremental development of sub-systems in different layers. of sub-systems in different layers. When a layer interface changes, only When a layer interface changes, only the adjacent layer is affectedthe adjacent layer is affected
However, often difficult to structure However, often difficult to structure systems in this waysystems in this way
14
CoContrntrol ol
momodeldelss
Are concerned with the control Are concerned with the control flow between sub-systems. Distinct flow between sub-systems. Distinct from the system decomposition from the system decomposition modelmodel
Centralized controlCentralized controlOne sub-system has overall responsibility for One sub-system has overall responsibility for
control and starts and stops other sub-control and starts and stops other sub-systemssystems
Event-based controlEvent-based controlEach sub-system can respond to externally Each sub-system can respond to externally
generated events from other sub-systems or generated events from other sub-systems or the system’s environmentthe system’s environment
15
Centralized Centralized controlcontrol
A control sub-system takes A control sub-system takes responsibility for managing the responsibility for managing the execution of other sub-systemsexecution of other sub-systems
Call-return modelCall-return model Top-down subroutine model - control starts at top of Top-down subroutine model - control starts at top of
a hierarchy and moves downwards. (non concurrent a hierarchy and moves downwards. (non concurrent systems)systems)
Manager modelManager model Applicable to concurrent systems. One system Applicable to concurrent systems. One system
component controls the stopping, starting and component controls the stopping, starting and coordination of other system processes. Can be coordination of other system processes. Can be implemented in sequential systems as a case implemented in sequential systems as a case statementstatement
16
CalCall-l-
retreturn urn momodeldel
Routine 1.2Routine 1.1 Routine 3.2Routine 3.1
Routine 2 Routine 3Routine 1
Mainprogram
17
Event-driven systemsEvent-driven systems
Driven by externally generated events Driven by externally generated events where event timing is out with the where event timing is out with the control of the sub-systems which control of the sub-systems which process the eventprocess the event
Two principal event-driven modelsTwo principal event-driven models Broadcast models. An event is broadcast to all Broadcast models. An event is broadcast to all
sub-systems. Any sub-system which can handle sub-systems. Any sub-system which can handle the event may do sothe event may do so
Interrupt-driven models. Used in real-time systems Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt where interrupts are detected by an interrupt handler and passed to some other component for handler and passed to some other component for processingprocessing
18
BroBroadcadcast ast momodeldel
Effective in integrating sub-systems on Effective in integrating sub-systems on different computers in a networkdifferent computers in a network
Sub-systems register an interest in Sub-systems register an interest in specific events. When these occur, specific events. When these occur, control is transferred to the sub-system control is transferred to the sub-system which can handle the eventwhich can handle the event
Control policy is not embedded in the Control policy is not embedded in the event and message handler. Sub-systems event and message handler. Sub-systems decide on events of interest to themdecide on events of interest to them
However, sub-systems don’t know if or However, sub-systems don’t know if or when an event will be handledwhen an event will be handled
19
IntInterrerruptupt
--dridriven ven syssystetemsms
Used in real-time systems where fast Used in real-time systems where fast response to an event is essentialresponse to an event is essential
There are known interrupt types with There are known interrupt types with a handler defined for each typea handler defined for each type
Each type is associated with a Each type is associated with a memory location and a hardware memory location and a hardware switch causes transfer to its handlerswitch causes transfer to its handler
Allows fast response but complex to Allows fast response but complex to program and difficult to validateprogram and difficult to validate
20
MoModuldular ar
decdecomompospositioitionn
Structural level where sub-systems are Structural level where sub-systems are decomposed into modulesdecomposed into modules
Two modular decomposition models Two modular decomposition models An object model where the system is decomposed An object model where the system is decomposed
into interacting objectsinto interacting objectsA data-flow model where the system is decomposed A data-flow model where the system is decomposed
into functional modules which transform inputs to into functional modules which transform inputs to outputs. Also known as the pipeline modeloutputs. Also known as the pipeline model
If possible, concurrency decisions If possible, concurrency decisions delayed until implementation.delayed until implementation.
21
ObjObject ect momodeldelss
Structure the system into a set of Structure the system into a set of loosely coupled objects with well-loosely coupled objects with well-defined interfacesdefined interfaces
Object-oriented decomposition is Object-oriented decomposition is concerned with identifying object concerned with identifying object classes, their attributes and classes, their attributes and operationsoperations
When implemented, objects are When implemented, objects are created from these classes and some created from these classes and some control model used to coordinate control model used to coordinate object operationsobject operations
22
DatData-a-floflow w
momodeldelss
Functional transformations process Functional transformations process their inputs to produce outputstheir inputs to produce outputs
May be referred to as a pipe and filter May be referred to as a pipe and filter model (as in UNIX shell)model (as in UNIX shell)
Variants of this approach are very Variants of this approach are very common. When transformations are common. When transformations are sequential, this is a batch sequential sequential, this is a batch sequential model which is extensively used in model which is extensively used in data processing systemsdata processing systems
Not really suitable for interactive Not really suitable for interactive systemssystems
23
InvInvoicoice e
proprocescessinsing g
syssystetemm
Read issuedinvoices
Identifypayments
Issuereceipts
Findpayments
due
Receipts
Issuepaymentreminder
Reminders
Invoices Payments
24
DoDomamain-in-spespecificific c
arcarchithitectectureuress
Architectural models which are specific Architectural models which are specific to some application domainto some application domain
Two types of domain-specific modelTwo types of domain-specific model Generic models which are abstractions from a Generic models which are abstractions from a
number of real systems and which encapsulate the number of real systems and which encapsulate the principal characteristics of these systemsprincipal characteristics of these systems
Reference models which are more abstract, idealised Reference models which are more abstract, idealised model. Provide a means of information about that model. Provide a means of information about that class of system and of comparing different class of system and of comparing different architecturesarchitectures
Generic models are usually bottom-up Generic models are usually bottom-up models; Reference models are top-down models; Reference models are top-down modelmodel
25
SysSystetem m
typtypeses
Personal systems that are not distributed Personal systems that are not distributed and that are designed to run on a and that are designed to run on a personal computer or workstation. personal computer or workstation.
Embedded systems that run on a single Embedded systems that run on a single processor or on an integrated group of processor or on an integrated group of processors. processors.
Distributed systems where the system Distributed systems where the system software runs on a loosely integrated software runs on a loosely integrated group of co-operating processors linked group of co-operating processors linked by a network. by a network.
26
Distributed system Distributed system characteristicscharacteristics
CharacteristicsCharacteristicsResource sharing Resource sharing OpennessOpennessConcurrencyConcurrency ScalabilityScalabilityFault toleranceFault tolerance TransparencyTransparency
DisadvantagesDisadvantagesComplexityComplexity SecuritySecurityManageabilityManageability UnpredictabilityUnpredictability
27
Issues in distributed system Issues in distributed system designdesign
Design issue
Description
Resource Identification
Resources in a distributed system are spread across different computers.
A naming scheme has to be devised so users can discover and refer to the resources.
An example of such a naming scheme is the URL (Uniform Resource Locator) which identifies WWW pages.
oo
28
Issues in distributed system Issues in distributed system designdesign
Design issue
Description
Communications
Universal availability of the Internet and the efficient implementation of Internet TCP/IP communication protocols means that, for most distributed systems, these are the most effective way for the computers to communicate. However, communications has specific performance and reliability issues.
29
Issues in distributed system Issues in distributed system designdesign
Design issue
Description
Quality of service
Quality of service offered reflects a systems performance, availability and reliability
30
Issues in distributed system Issues in distributed system designdesign
Design issue
Description
Software Architectures
Architecture describes how the application functionality is distributed over a number of logical components and how these components are distributed across processors.
31
DisDistribtributeuted d
syssystetems ms arcarchithitectectureuress
Client-server architecturesClient-server architecturesDistributed services which are called Distributed services which are called
on by clients. Servers that provide on by clients. Servers that provide services are treated differently from services are treated differently from clients that use servicesclients that use services
Distributed object Distributed object architecturesarchitecturesNo distinction between clients and No distinction between clients and
servers. Any object on the system may servers. Any object on the system may provide and use services from other provide and use services from other objectsobjects
32
MidMiddledlewawarere
Software that supports different Software that supports different components of a distributed system components of a distributed system sitting in the sitting in the middle middle of systemof system
Middleware is usually off-the-shelf Middleware is usually off-the-shelf rather than specially written rather than specially written softwaresoftware
ExamplesExamples Transaction processing monitorsTransaction processing monitors Data convertersData converters Communication controllersCommunication controllers
33
MulMultiprtiproceocessossor r
arcarchithitectectureuress
Simplest distributed system modelSimplest distributed system model System composed of multiple System composed of multiple
processes which may (but need not) processes which may (but need not) execute on different processorsexecute on different processors
Architectural model of many large Architectural model of many large real-time systemsreal-time systems
Distribution of process to processor Distribution of process to processor may be pre-ordered or may be may be pre-ordered or may be under the control of a dispatcherunder the control of a dispatcher
34
CliClientent
--serserver ver arcarchithitectectureuress
The application is modelled as a The application is modelled as a set of services that are provided set of services that are provided by servers and a set of clients by servers and a set of clients that use these servicesthat use these services
Clients know of servers but Clients know of servers but servers need not know of clientsservers need not know of clients
Clients and servers are logical Clients and servers are logical processes processes
The mapping of processors to The mapping of processors to processes is not necessarily 1 : 1processes is not necessarily 1 : 1
35
A A clieclient-nt-serserver ver syssystetemm
s1
s2 s3
s4c1
c2 c3 c4
c5
c6c7 c8
c9
c10
c11
c12
Client process
Server process
36
LayLayereered d apapplicplicatiation on arcarchithitectectureure
Presentation layerPresentation layer Concerned with presenting the results of a Concerned with presenting the results of a
computation to system users and with computation to system users and with collecting user inputscollecting user inputs
Application processing layerApplication processing layer Concerned with providing application Concerned with providing application
specific functionality e.g., in a banking specific functionality e.g., in a banking system, banking functions such as open system, banking functions such as open account, close account, etc.account, close account, etc.
Data management layerData management layer Concerned with managing the system Concerned with managing the system
databasesdatabases
37
ThiThin n anand d
fat fat clieclientsnts
Thin-client modelThin-client model In a thin-client model, all of the application In a thin-client model, all of the application
processing and data management is carried processing and data management is carried out on the server. The client is simply out on the server. The client is simply responsible for running the presentation responsible for running the presentation software.software.
Fat-client modelFat-client model In this model, the server is only responsible In this model, the server is only responsible
for data management. The software on the for data management. The software on the client implements the application logic and client implements the application logic and the interactions with the system user.the interactions with the system user.
38
ThiThin n anand d
fat fat clieclientsnts
Thin-clientmodel
Fat-clientmodel Client
Client
Server
Data managementApplicationprocessing
Presentation
Server
Datamanagement
PresentationApplication processing
39
ThiThin n
clieclient nt momodeldel
Used when legacy systems are Used when legacy systems are migrated to client server migrated to client server architectures. architectures. The legacy system acts as a server in The legacy system acts as a server in
its own right with a graphical interface its own right with a graphical interface implemented on a clientimplemented on a client
A major disadvantage is that it A major disadvantage is that it places a heavy processing places a heavy processing load on both the server and load on both the server and the networkthe network
40
Typical Thin client Typical Thin client modelmodel
GUI done in html GUI done in html (usually generated by frontpage, etc)(usually generated by frontpage, etc).. Downloaded when used. Some items may Downloaded when used. Some items may be cached such as drop downs. (GUI be cached such as drop downs. (GUI downloaded takes too much time, GUI on downloaded takes too much time, GUI on client requires too much setup for each client requires too much setup for each machines and Config. Man.machines and Config. Man.
Servlets, JSP run for application Servlets, JSP run for application processing. processing.
Little or nothing residing at the client Little or nothing residing at the client side. side.
41
Fat Fat clieclient nt momodeldel
More processing is delegated to the More processing is delegated to the client as the application processing is client as the application processing is locally executedlocally executed
Most suitable for new C/S systems Most suitable for new C/S systems where the capabilities of the client where the capabilities of the client system are known in advancesystem are known in advance
More complex than a thin client model More complex than a thin client model especially for configuration especially for configuration management. New versions of the management. New versions of the application have to be installed on all application have to be installed on all clientsclients
42
A A clieclient-nt-serserver ver ATATM M
syssystetemm
Account server
Customeraccountdatabase
Tele-processing
monitor
ATM
ATM
ATM
ATM
43
Three-tier architecturesThree-tier architectures
In a three-tier architecture, each of the In a three-tier architecture, each of the application architecture layers may application architecture layers may execute on a separate processorexecute on a separate processor
Allows for better performance than a thin-Allows for better performance than a thin-client approach and is simpler to manage client approach and is simpler to manage than a fat-client approachthan a fat-client approach
A more scalable architecture - as demands A more scalable architecture - as demands increase, extra servers can be addedincrease, extra servers can be added
Client
Server
Datamanagement
PresentationServer
Applicationprocessing
44
Use of C/S architecturesUse of C/S architectures
Architecture
Applications
Two-tier C/S architecture with thin clients
Legacy system applications where separating application processing and data management is impractical Computationally-intensive applications such as compilers with little or no data management Data-intensive applications (browsing and querying) with little or no application processing.
45
Use of C/S architecturesUse of C/S architectures
Architecture
Applications
Two-tier C/S architecture with fat clients
Applications where application processing is provided by COTS (e.g. Microsoft Excel) on the client Applications where computationally-intensive processing of data (e.g. data visualisation) is required. Applications with relatively stable end-user functionality used in an environment with well-established system management
46
Use of C/S architecturesUse of C/S architectures
Architecture
Applications
Three-tier or multi-tier C/S architecture
Large scale applications with hundreds or thousands of clients Applications where both the data and the application are volatile. Applications where data from multiple sources are integrated
47
DisDistribtributeuted d
objobject ect arcarchithitectectureuress
There is no distinction in a distributed There is no distinction in a distributed object architectures between clients object architectures between clients and serversand servers
Each distributable entity is an object Each distributable entity is an object that provides services to other objects that provides services to other objects and receives services from other and receives services from other objectsobjects
Object communication is through a Object communication is through a middleware system called an object middleware system called an object request broker (software bus)request broker (software bus)
However, more complex to design than However, more complex to design than C/S systemsC/S systems
48
Advantages of distributed object Advantages of distributed object architecturearchitecture
It allows the system designer to delay It allows the system designer to delay decisions on where and how services decisions on where and how services should be providedshould be provided
It is a very open system architecture It is a very open system architecture that allows new resources to be that allows new resources to be added to it as requiredadded to it as required
The system is flexible and scaleableThe system is flexible and scaleable It is possible to reconfigure the It is possible to reconfigure the
system dynamically with objects system dynamically with objects migrating across the network as migrating across the network as requiredrequired
49
Uses of distributed object Uses of distributed object architecturearchitecture
As a logical model that allows you to As a logical model that allows you to structure and organise the system. In structure and organise the system. In this case, you think about how to provide this case, you think about how to provide application functionality solely in terms application functionality solely in terms of services and combinations of servicesof services and combinations of services
As a flexible approach to the As a flexible approach to the implementation of client-server systems. implementation of client-server systems. The logical model of the system is a The logical model of the system is a client-server model but both clients and client-server model but both clients and servers are realised as distributed servers are realised as distributed objects communicating through a objects communicating through a software bussoftware bus
50
CORBCORBAA CORBA is an international standard CORBA is an international standard
for an Object Request Broker - for an Object Request Broker - middleware to manage middleware to manage communications between distributed communications between distributed objectsobjects
Several implementation of CORBA Several implementation of CORBA are availableare available
DCOM is an alternative approach by DCOM is an alternative approach by Microsoft to object request brokersMicrosoft to object request brokers
CORBA has been defined by the CORBA has been defined by the Object Management GroupObject Management Group
51
ApApplicplicatiation on strstructuctureure
Application objectsApplication objects Standard objects, defined by the Standard objects, defined by the
OMG, for a specific domain e.g. OMG, for a specific domain e.g. insuranceinsurance
Fundamental CORBA services such as Fundamental CORBA services such as directories and security managementdirectories and security management
Horizontal (i.e. cutting across Horizontal (i.e. cutting across applications) facilities such as user applications) facilities such as user interface facilitiesinterface facilities
52
COCORBRBA A
stastandndardardss
An object model for application An object model for application objectsobjects A CORBA object is an encapsulation of state with a A CORBA object is an encapsulation of state with a
well-defined, language-neutral interface defined in well-defined, language-neutral interface defined in an IDL (interface definition language)an IDL (interface definition language)
An object request broker that An object request broker that manages requests for object servicesmanages requests for object services
A set of general object services of use A set of general object services of use to many distributed applicationsto many distributed applications
A set of common components built on A set of common components built on top of these servicestop of these services
53
COCORBRBA A
objobjectectss
CORBA objects are comparable, in CORBA objects are comparable, in principle, to objects in C++ and Javaprinciple, to objects in C++ and Java
They MUST have a separate interface They MUST have a separate interface definition that is expressed using a definition that is expressed using a common language (IDL) similar to C++common language (IDL) similar to C++
There is a mapping from this IDL to There is a mapping from this IDL to programming languages (C++, Java, etc.)programming languages (C++, Java, etc.)
Therefore, objects written in different Therefore, objects written in different languages can communicate with each languages can communicate with each otherother
54
ObjObject ect reqrequesues
t t brobroker ker (O(ORB)RB)
The ORB handles object communications. The ORB handles object communications. It knows of all objects in the system and It knows of all objects in the system and their interfacestheir interfaces
Using an ORB, the calling object binds an Using an ORB, the calling object binds an IDL stub that defines the interface of the IDL stub that defines the interface of the called objectcalled object
Calling this stub results in calls to the Calling this stub results in calls to the ORB which then calls the required object ORB which then calls the required object through a published IDL skeleton that through a published IDL skeleton that links the interface to the service links the interface to the service implementationimplementation
55
COCORBRBA A
serservicviceses
Naming and trading servicesNaming and trading services These allow objects to discover and refer These allow objects to discover and refer
to other objects on the networkto other objects on the network
Notification servicesNotification services These allow objects to notify other objects These allow objects to notify other objects
that an event has occurredthat an event has occurred
Transaction servicesTransaction services These support atomic transactions and These support atomic transactions and
rollback on failurerollback on failure
56
SofSoftwtware are ReReuseuse
Buy, don’t buildBuy, don’t buildcheapercheaperfasterfasterhigher qualityhigher qualityspecializationspecialization
Capital investmentCapital investment
57
SofSoftwtware are reureusese
RisksRiskshard to learnhard to learndoesn’t do what you wantdoesn’t do what you wantcan’t changecan’t changedeveloper goes out of businessdeveloper goes out of business
Other problemsOther problemshave to find ithave to find it
58
COCOTSTS
HistoryHistory60’s: compilers, OS, accounting apps, 60’s: compilers, OS, accounting apps,
IBMIBM70’s: numerical libraries, other apps 70’s: numerical libraries, other apps
(payroll, manufacturing, etc.)(payroll, manufacturing, etc.)80’s: GUI libraries, Unix, Microsoft80’s: GUI libraries, Unix, Microsoft90’s: CORBA, COM, VB, Office, Internet, 90’s: CORBA, COM, VB, Office, Internet,
Java, SAP, Oracle, PeopleSoftJava, SAP, Oracle, PeopleSoft2K: XML, EJB, SOAP, .NET2K: XML, EJB, SOAP, .NET
59
COCOTSTS
Standard apps need Standard apps need standard OSstandard OSstandard way of customizing standard way of customizing themthem
standard way of connecting standard way of connecting them to other softwarethem to other software
60
CusCustoto
mizmizing ing COCOTSTS
Programming languages Programming languages (COBOL, PL/I, FORTRAN, C, VB, Java)(COBOL, PL/I, FORTRAN, C, VB, Java)
Scripting languages Scripting languages (javascript, VB, perl)(javascript, VB, perl)
APIs APIs (DLL, CORBA, COM, SOAP)(DLL, CORBA, COM, SOAP)
Data formats Data formats (Unix streams, RDBMS, XML)(Unix streams, RDBMS, XML)
61
StaStandndardards s
for for intinterferfaciacingng
Unix: All components have the Unix: All components have the same interface, stream of ASCII same interface, stream of ASCII characterscharacters
Mesa, Ada, Smalltalk, Java: Use Mesa, Ada, Smalltalk, Java: Use some programming language to some programming language to define custom data types and define custom data types and use it to write components and use it to write components and clients that use the componentsclients that use the components
62
StaStandndardards s
for for intinterferfaciacingng
CORBA: Use IDL (interface CORBA: Use IDL (interface description language) to define description language) to define the interface of component. the interface of component. Generate code from IDL.Generate code from IDL.
COM: Component has many COM: Component has many interfaces. There is a binary interfaces. There is a binary standard for interfaces.standard for interfaces.
63
COCORBRBAA Developed by OMG Developed by OMG
(www.omg.org)(www.omg.org) Language independent, object-Language independent, object-
orientedoriented Define interface with IDLDefine interface with IDL Generate proxies for clients, Generate proxies for clients,
skeleton for serversskeleton for servers Complete standard includes Complete standard includes
many standard interfacesmany standard interfaces
64
COM COM now .netnow .net
Developed by MicrosoftDeveloped by Microsoft An An interfaceinterface is an array of is an array of
pointers to functions.pointers to functions. Clients refer to objects by their Clients refer to objects by their
interfacesinterfaces The first operation of any The first operation of any
interface is QueryInterface(I), interface is QueryInterface(I), which returns a pointer to the which returns a pointer to the interface named I if the object interface named I if the object has onehas one
65
CoCompmpononentent
Component - a nontrivial, nearly Component - a nontrivial, nearly independent, and replaceable independent, and replaceable part of a system that fulfills a part of a system that fulfills a clear function in the context of a clear function in the context of a well-defined architecturewell-defined architecture
Software component - a unit of Software component - a unit of composition with contractually composition with contractually specified and explicit context specified and explicit context dependencies onlydependencies only
66
StaStandndardardss
Technical definition of a Technical definition of a component, how components are component, how components are named, interactnamed, interactAn object modelAn object model
Standard interfacesStandard interfaces Standard componentsStandard components Tools for selecting, composing, Tools for selecting, composing,
buildingbuilding
67
CoCompmpononent ent SysSystetemm
Component System
COTS Custom
components
Application
Component systemCORBACOMJavaBeans
68
What is component-based What is component-based design?design?
Designing an application by Designing an application by breaking it into components?breaking it into components?
Designing an application by Designing an application by building it from existing building it from existing components?components?
Designing components?Designing components? Designing reusable components?Designing reusable components? Designing reusable interfaces?Designing reusable interfaces?
69
ReReusiusing ng cocompmpononententss
Must change architectureMust change architecturebased on componentsbased on components
Usually changes specificationUsually changes specificationeliminate features that are too expensiveeliminate features that are too expensive
Changes detailed design and Changes detailed design and implementationimplementationwrapping components and gluing themwrapping components and gluing them
70
CoCompmpononent ent arcarchithitectectureuress
Some architectures based Some architectures based on componentson componentsASP, MTSASP, MTSJavaBeans, ServletsJavaBeans, Servlets
71
Analysis to Analysis to DesignDesign
Entity-Relationship
Diagram
Data FlowDiagram
State-TransitionDiagram
Data Dictionary
Process Specification (PSPEC)
Control Specification (CSPEC)
Data Object Description
THE ANALYSIS MODEL
proceduraldesign
interfacedesign
architecturaldesign
datadesign
THE DESIGN MODEL
72
Where Do We Where Do We Begin?Begin?
Spec
PrototypePrototype
DesignDesign
modeling
73
Design Design PrinciplesPrinciples The design process should not suffer from
‘tunnel vision.’ The design should be traceable to the
analysis model. The design should not reinvent the wheel. The design should “minimize the
intellectual distance” [DAV95] between the software and the problem as it exists in the real world.
The design should exhibit uniformity and integration.
74
Design Design PrinciplesPrinciples
The design should be structured to accommodate change.
The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.
Design is not coding, coding is not design. The design should be assessed for quality
as it is being created, not after the fact. The design should be reviewed to minimize
conceptual (semantic) errors.
75
Fundamental Fundamental ConceptsConcepts abstractionabstraction—data, procedure, control—data, procedure, control
refinementrefinement—elaboration of detail for all abstractions—elaboration of detail for all abstractions modularitymodularity—compartmentalization of data and —compartmentalization of data and
functionfunction architecturearchitecture—overall structure of the software—overall structure of the software
Structural propertiesStructural propertiesExtra-structural propertiesExtra-structural propertiesStyles and patternsStyles and patterns
procedureprocedure—the algorithms that achieve function—the algorithms that achieve function hidinghiding—controlled interfaces—controlled interfaces
76
Data Data AbstractionAbstraction
door
implemented as a data structure
manufacturermodel numbertypeswing directioninsertslights type numberweightopening mechanism
77
Procedural Procedural AbstractionAbstraction
open
implemented with a "knowledge" of the object that is associated with enter
details of enter algorithm
78
Stepwise Stepwise RefinementRefinementopen
walk to door;reach for knob;
open door;
walk through;close door.
repeat until door opensturn knob clockwise;if knob doesn't turn, then take key out; find correct key; insert in lock;endifpull/push doormove out of way;end repeat
79
Modular Modular DesignDesigneasier to build, easier to change, easier to fix ...
80
Modularity: Trade-Modularity: Trade-offsoffs
optimal numberoptimal number of modulesof modules
What is the "right" number of modules What is the "right" number of modules for a specific software design?for a specific software design?
cost ofcost of softwaresoftware
number of modulesnumber of modules
modulemoduleintegrationintegration
costcost
module development cost module development cost
81
Sizing Modules: Two Sizing Modules: Two ViewsViews
MODULE
What's inside??
How big is it??
82
Functional Functional IndependenceIndependence
COHESION - the degree to which a module performs one and only one function. COUPLING - the degree to which a module is "connected" to other modules in the system.
83
ArchitectuArchitecturere
““The overall structure of the software and the The overall structure of the software and the ways in which that structure provides ways in which that structure provides conceptual integrity for a system.” [SHA95a]conceptual integrity for a system.” [SHA95a]
Structural properties. This aspect of the architectural design representation defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods .
84
ArchitectuArchitecturere
““The overall structure of the software and the The overall structure of the software and the ways in which that structure provides ways in which that structure provides conceptual integrity for a system.” [SHA95a]conceptual integrity for a system.” [SHA95a]
Extra-functional properties. The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics.Families of related systems. The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design
should have the ability to reuse architectural building blocks.
85
Information HidingInformation Hiding
modulemodulecontrolledcontrolledinterfaceinterface
"secret""secret"
• • algorithmalgorithm
• • data structuredata structure
• • details of external interfacedetails of external interface
• • resource allocation policyresource allocation policy
a specific design decisiona specific design decision
clientsclients
86
Why Information Why Information Hiding?Hiding?
reduces the likelihood of “side reduces the likelihood of “side effects”effects”
limits the global impact of local limits the global impact of local design decisionsdesign decisions
emphasizes communication through emphasizes communication through controlled interfacescontrolled interfaces
discourages the use of global datadiscourages the use of global data leads to encapsulation—an attribute leads to encapsulation—an attribute
of high quality designof high quality design results in higher quality softwareresults in higher quality software