GUI-Hanger syndrome SOFTWARE ARCHITECTURES. Architectural Design Choices. Why software architectures? Monolithic Architecture / 2

Size: px

Start display at page:

Download "GUI-Hanger syndrome SOFTWARE ARCHITECTURES. Architectural Design Choices. Why software architectures? Monolithic Architecture / 2"

Ophelia Jacobs
5 years ago
Views:

1 GUI-Hanger syndrome SOFTWARE ARCHITECTURES An architecture contains the information on how the software devides into building blocks. Software Engineering do this; Why software architectures? Architectural Design Choices Managing complexity It is easier to manage complexity, if we divide the application into reasonable parts. Maintainability Usually a reasonable architecture makes it much easier to maintain the software. This may actually be the biggest reason for architectural design. Efficiency A good architecture enables us to isolate the potential causes for inefficiency and makes it possible to scale up performance when load increases. Choices Made In Architectural Design: Components High-Level Design Patterns Architectural Styles A Possible Framework Architecture Processes and Hardware Processes and Communication Other Architecture-Related Decisions -> Some of these issues depend on each other strongly. Let s have a look at some historical development. Monolithic Architecture / 1 Monolithic Architecture / 2 Monolithic systems are not divided into independent parts. They typically run on a single processing unit (computer). There was a time when computers typically did not talk that much with each other. This made monolithic systems more or less the only choice. Lack of complicated communication speeds up processing, but it is hard to improve performance in any other way than increasing processing power for that one computer. Typically and historically, the monolithic system talks with fairly dumb clients (like terminals). 1

2 Client/Server Architecture /1 When terminals were replaced by microcomputers, they started to have processing power. To use this power just to run a terminal program was a waste of processing capabilities. Consequently, the microcomputers were used to run a client program, which talked with the mainframe server. Client/Server Architecture /2 Fat clients contained more functionalities and data. Thin clients contained more or less terminal-type functionalities. Client/Server (C/S) computing was the first step towards multi-tier (multi-layer) architectures on processing unit level. It allowed a better division of work. However, fat clients also needed maintenance and installations to keep up with current versions. Three-tier architecture / 1 The server side was still monolithic in a basic C/S architecture, which created a performance bottleneck. As the applications usually had a database, multiplying the database is hard in many cases, which makes it hard to multiply the servers. However, by having a separate database server it was possible to have multiple application servers. APPLICATION SERVERS DATABASE SERVER Three-tier architecture / 2 The database server only runs the database, as having several of them is difficult. If there are database server performance problems, get a more powerful server! You may use several servers for backup to always have a backup server on-line ready for action. The three-tier architecture is fairly common. To make client installation easier, it is possible to have a client server (or UI server), from which the client is software is loaded for execution (like an applet to be executed in the browser). Using multiple database servers If data is replicated to several databases, updating them correctly is a problem in particular if the replicas must be consistent. If data is replicated, then it should be easily found somehow. Like assume a library keeps books with title starting with A on one data server, B on a second server, and so on. Queries based on other selection criteria or data from several servers are problematic. A B C... Z Some application architectures Frame Docu ment Slide by Ari Jaaksi. Application Docu ment MDI (MFC) User interface Min=0 Max=400 Value=50 Abstraction Control Presentation PAC (J.Coutaz) Model Simple Separation (N.N) MVC Model (Reenskaug) 2

3 MVC Model Often uses a database. Could include basic rules about the domain. User interface Typical implementation is graphical (GUI, graphical user interface) Understands user interface requests. Uses the model to fulfill them. MVC - web development examples Model Typically uses an SQL database Objects to manage the database according to the rules of the model HTML forms Applets JSP (Java Server Pages, an XML-like description from which HTML is generated) ( application programs using M and V ) Java servlets, perl programs, etc... MVC++ triad MVC++ application in action -knows how this particular application works -controls the view and the model Model -"real world" -works when the controller asks it to work -user interface -knows how to communicate with the end user MVC++ is an MVC variant developed at Nokia. Slide by Ari Jaaksi. Observations of the End User =Feedback Actions of the End User =Manipulation User Interface Action requests Interpreted actions Decisions Results Action requests End User Model From a slide by Ari Jaaksi. Actions Working together Peer-To-Peer Computing Balance Get view::getpressedmm() controller->balancewanted(); ; view::showbalancefm(int b) TextField.WriteInt(b); ; controller::balancewanted() b = model->getbalance(); view->showbalancefm(b); ; int model::getbalance() return(balance); ; Balance: 7800:- Model Slide by Ari Jaaksi. The above processing architectures have assumed that we have separate servers and clients and the configuration of the system is controlled in a centralised fashion. In Peer-To-Peer computing, each computer (node) is equal, and the nodes may ask each other for processing services. The nodes may contact each other flexibly and forward processing requests, which removes a fixed configuration for processing. Grid computing ( a software infrastructure enabling flexible, secure and coordinated resource sharing ) 3

4 Processing Unit vs. Software Architecture If an architecture divides processing into different types of processing units (clients and various servers), then of course this division implies also a division of the software functionalities. However, there is also architectural structural decisions, which do not need to be based on the processing unit architecture. Dividing the tiers As an example, we may divide the application server functionalities into domain tier and control (application) tier. Typically it is the domain tier, which talks to the database. It makes a big difference, how the layers talk with each other. It is typically seen as a good thing, if the layers call each other in top-down fashion and the calls do not pass-by layers (e.g. application layer does not call database layer). - Makes maintenance easier. - Performance may suffer. Client tier Application tier Domain tier Database tier Issues with multi-layer architectures Number of layers Error/exception management (what to pass on, what to process) Callback from lower layers. Interfaces between layers / encapsulation of layers. Maintenance knock-on effects (do changes of one layer imply changes in other layers?) Components - What? Component technologies can be seen as packaging technologies Independent Can be used as a building block to build larger systems dynamic, plug & play linking Have a well-defined interface, which hides the implementation completely Can be treated as a product of its own Can be installed separately Can be implemented with any language, as long as it implements the necessary interfaces Components - Why? Component Diagram Object-oriented source-level re-use of code requires same source code language. Object-oriented source-level re-use may require understanding of the implementation. Building the system from source-level pieces requires that these pieces compile happily with each other. We want to avoid the above problems and build binary components with well-defined interfaces. ComponentZ ComponentY InterfaceX component implements uses Interface this may also be represented with stereotype <<interface>> for a class. 4

5 Component - Interfaces Component Technologies An interfaces defines a set of services, which semantically belong together. An interface is a contract between the user and the implementor. A componenent may implement many interfaces and an interface may be implemented by many components. Once an interface is released, it does not change. If changes are necessary, a new interface is released. As a matter of fact, you should know all this. Microsoft COM & DCOM (distributed COM) CORBA standard several vendors heavyweight system Java Beans Component Diagram For The Game Application Seq. Diagram for Take Card, Component Level GameGUI Game GameModel GameInterface GameModelInterface User Choose to take card Show funds Show card value Show funds Game Game GameModel Take card Pay (1) Show funds Updated funds Turn Card Show card value Card Value Add Funds (Value) Show funds Updated funds Deployment Diagram FRAMEWORKS Processing resource (a device, not a device type) : GameClient : GameServer : GUI Object ok, this was a component in an earlier slide, this is just for example <<TCP/IP>> : GameModel : Game Component instance A an application framework contains core parts for an application. The framework serves as a starting-point for application development. We add new things to the core. In case of OO software development, a framework may contain a set of core classes. Naturally, the new system inherits the basic architecture from the framework. 5

6 Black-box vs. white-box frameworks In black-box frameworks, we just build things on top of the framework without a need to see the implementation details in the framework. - Easy to use In white-box frameworks, we typically implement new subclasses based on the classes in the framework. - More flexible Frameworks vs. components When you use components, you typically write the main programs yourself and call the services from the components. When you use frameworks, the framework includes the main programs and you implement the application-specific special services, which the framework calls. - The so-called Hollywood principle: Don t call us, we call you. Frameworks conclusions It is harder to write a good application framework than it is to write a good application. However, if it succeeds, a lot of effort can be saved in producing future applications based on the framework. In particular, it is possible to get the products out earlier (a time-to-market improvement). Design Patterns The idea is to copy an existing design idea and modify it to our needs. The idea of copying designs like this is the basic idea behind design patterns. It has been difficult to reuse code. The idea of design patterns is to reuse ideas. In a way, applying the MVC model is reusing the idea. However, there have been efforts to give a fixed format for presenting design patterns. Design patterns can be used at architectural design as well as in more detailed design. Design Pattern Description Name Problem Solution Static: E.g. Class Diagram Dynamic: E.g. Sequence Diagram Strategy How to implement the pattern Consequences Results and trade-offs Design Pattern Observer Problem: We want to keep a number of objects (observers) aware of the state of an object (subject) This is done by making the observers subscribe to the subject. Whenever the subjects state changes, it will publish information about that to all subscribed observers. 6

7 Class Diagram for Observer Design Pattern A Sequence Diagram For Observer Design Pattern Subject abstract observes * Object abstract abstract attach(x:observer) detach(x: Observer) notify() registers for all g in observes g. ConcereteObserver ConcreteSubject :ConcreteSubject1:ConcreteObservert2:ConcereteObserver Changes State attach(t1) notify() attach(t2) Some observations A subject and the respective observers need minimal information on each other. In fact, they need to implement the required operations (attach, detach, notify, update), but that s about that. This way, we get a high level of independence in their implementations. Applying The Observer Design Pattern Subject abstract GameModel observes * attach(x:observer) detach(x: Observer) notify() registers for all g in observes g. Object abstract abstract GameGUI Software Engineering? 7

Client/Server-Architecture

Client/Server-Architecture Content Client/Server Beginnings 2-Tier, 3-Tier, and N-Tier Architectures Communication between Tiers The Power of Distributed Objects Managing Distributed Systems The State