GUI-Hanger syndrome Jyrki Nummenmaa University of Tampere, CS - PDF document

“GUI-Hanger” syndrome Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department SOFTWARE ARCHITECTURES FuncX(…) An architecture contains the information on how the FuncX(…) FuncX(…) { FuncX(…) { { do this; FuncX(…) { software devides into building blocks. do this; do this; do that; { do this; FuncX(…) do that; do that; do this; do this; do that; { do this; do this; do that; do that; do this; FuncX(…) do this; do that; do that; do this; FuncX(…) { do this; do that; do this; do this; do that; do that; { do this; do that; do this; do this; do that; do that; do this; do this; do this; do that; do that; do this; do this; do that; do that; do that; do this; do that; do this; do this; do that; do that; do this; do this; do that; do this; do that; do that; do this; do this; do that; do that; do this; do that; do this; do that; do that; do that; do this; do that; do this; do this; do that; do this; do this; do this; do that; do that; do this; do that; do this; do that; do that; do this; do that; do that; do that; do this; do that; Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se do this; do this; do this; do that; do that; do this; do this; do this; do that; do that; do that; do this; do that; do that; do this; do that; do this; do this; do this; do that; do that; do this; do this; do this; do that; do that; do that; } do that; do that; do this; do that; } } } } } do that; } } Why software architectures? Architectural Design Choices • Managing complexity Choices Made In Architectural Design: Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department – It is easier to manage complexity, if we divide the • Components application into reasonable parts. • High-Level Design Patterns • Maintainability • Architectural Styles – Usually a reasonable architecture makes it much easier to • A Possible Framework Architecture maintain the software. • Processes and Hardware – This may actually be the biggest reason for architectural • Processes and Communication design. Other Architecture-Related Decisions ☺ • • Efficiency • -> Some of these issues depend on each other strongly. – A good architecture enables us to isolate the potential causes for inefficiency and makes it possible to scale up • Let’s have a look at some historical development. performance when load increases. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se Monolithic Architecture / 1 Monolithic Architecture / 2 • Monolithic systems are not divided into independent parts. • Typically and historically, the monolithic system talks with Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department They typically run on a single processing unit (computer). fairly dumb clients (like terminals). • 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. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se 1

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

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