Modeling and Systems Development Lecture 9 Architectural Design Creating a clear plan of what needs to be built and the infrastructure to build it on
Design The purpose of the analysis phase is to figure out wha the client needs. The purpose of the design phase is to figure out how to provide it. The steps both in analysis and design phases are highly interrelated and may require much going back and forth Nieuwbouw Leuvenlaan 2
Avoid classic design mistakes Reducing design time and jumping into programming Feature creep requirements will change Silver bullet syndrome unrealistic claims of new tool support Switching tools in mid-project 3
Partitions and collaborations Creating subsystems or larger units e.g. splitting system claim handling into claim assessment, claim processing, claim payment Merging overlapping collaborations The more messages or contracts between objects, the more likely they are in the same partition 4
Layers (1) Each layer is a cluster of collaborating objects dependent on the facilities offered by lower layers The top layer is the easiest to change because no other layers depend on it Every layer may be replaced by one with the same interface User interface Business rules Problem domain Data management Database 5
Layers (2) HC interaction Physical architecture Data management Problem domain User interface Foundation Business rules Problem domain Data management Database 6
Package A general UML construct for organizing elements into groups Elements: classes, use cases, components, other packages etc. A package and its elements are in a composite relationship Used to reduce complexity of models 7
Syntax for package diagram Packages have (simple or path) names If the package elements are displayed (which is uncommon), the package name is shown in the package tab a dependency Package 1 Package 2 Types Time Types Integer 8
Modification dependency Indicates that a change in one package could cause a change in another package Example: adding a parameter to an operation op of class C will impact all objects sending messages of the form op( ); e.g. changing getseminarhistory() to getseminarhistory(fromdate) 9
Put classes in one package if they are related via inheritance; or composition; or if they collaborate a lot Similar rules of thumb apply to e.g. use cases Package diagram: appointment system 10
Design strategy: custom development Allows for meeting highly specialized (tailor made) requirements Allows flexibility and creativity in solving problems Easier to change components Builds personnel skills May ask a lot of the firm s resources May add significant risk This is Dr. Thompson - He'll be making you fit into your suit today. 11
Design strategy: packaged software Software already written May be more efficient May be more thoroughly tested and proven May range from components to tools to whole enterprise systems Must accept the functionality provided May require change in how the firm does business May require significant customization or workarounds 12
Packaged SW and system integration The process of combining packages, legacy systems, and new software Key challenge is integrating data Write data in the same format Revise existing data formats Develop object wrappers 13
Design strategy: outsourcing Hire external firm to create system May have more skills May extend existing resources Never outsource what you don t understand Carefully choose vendor Prepare contract and payment style carefully 14
Selecting a design strategy Business need, e.g. Unique => custom development No core business => outsourcing In-house experience Project skills Project management Time frame 15
System architecture The system architecture design consists of plans for the hardware, software, communications, security, and global support for the new application The designers must decide if processing will occur in the server (server-based), at the personal computer (client-based), or in some combination of these (client-server based) 16
Server-based architectures In server based architectures, the servers (mainframes) do the work and present the results to clients (terminals or PCs) 17
Client-based architectures In client based architectures, clients do most of the work (except data storage) and present the results Terminals Microcomputer (PC) 18
Client/server-based architectures Two-tier Three-tier 19
Client/server pros and cons Typical pros Compatible with web-based system design Scalable Work with multiple vendors/products No central point of failure Typical cons/limits Complexity New programming languages and techniques (stress for personnel) More complex to update 20
N-tiered client/server pros and cons Typical pros Separates processing to better balance load More scalable Typical cons/limits Greater load on the network More difficult to program and test 21
Distributed object architectures Middleware between clients and servers Update middleware when changing client code May reduce efficiency of the application CORBA DCOM,.NET 22
Selecting a computing architecture Server-based Client-based Client-Server Cost of infrastructure Very high Medium Low Cost of development Medium Low High Ease of development Low High Low-medium Interface capabilities Low High High Control and security High Low Medium Scalability Low Medium High 23
Realities of infrastructure design Most often the infrastructure will be in place Coordination of infrastructure components is very complex The application developer will need to coordinate with infrastructure specialists 24
The network model Diagram showing the major components e.g. Clients Servers Communication lines Networks Geographic locations 25
Hardware and software specification Used if new hardware or software must be purchased Actual acquisition of hardware and software usually left to a purchasing department -- especially in larger firms 26
Security A threat is any potential adverse occurrence that can do harm to the application or its data Threats come from internal as well as external sources Categories of threats Disruptions, destruction and disaster Unauthorized access 27
Internal threats 28
Most common threats 29
Creating controls A control is something that mitigates or stops a threat Controls include redundancy fault tolerant servers disaster recovery plans anti-virus software 30