1. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa SOFTWARE ARCHITECTURES An architecture contains the information on how the software devides into building blocks.

2. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa “GUI-Hanger” syndrome FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; } FuncX(…) { do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; }

3. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa Why software architectures? 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.

4. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa Architectural Design Choices 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.

5. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa Monolithic Architecture / 1 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.

6. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa Monolithic Architecture / 2 Typically and historically, the monolithic system talks with fairly dumb clients (like terminals).

7. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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.

8. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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.

9. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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. DATABASE SERVER APPLICATION SERVERS

10. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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).

11. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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 distributed, 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...

12. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa Some application architectures Min=0 Max=400 Value=50 AbstractionControlPresentation PAC (J.Coutaz) ControllerView Model MVC Model (Reenskaug) Application User interface Simple Separation (N.N) Frame View Docu ment Docu ment View MDI (MFC) Slide by Ari Jaaksi.

13. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa MVC Model –Often uses a database. –Could include ”basic rules” about the domain. View –User interface –Typical implementation is graphical (GUI, graphical user interface) Controller –Understands user interface requests. –Uses the model to fulfill them.

14. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa MVC - web development examples Model –Typically uses an SQL database –Objects to manage the database according to the rules of the model View –HTML forms –Applets –JSP (Java Server Pages, an XML-like description from which HTML is generated) Controller (”application programs using M and V”) –Java servlets, perl programs, etc...

15. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa MVC++ triad Controller -knows how this particular application works -controls the view and the model Model -"real world" -works when the controller asks it to work View -user interface -knows how to communicate with the end user MVC++ is an MVC variant developed at Nokia. Slide by Ari Jaaksi.

16. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa MVC++ application in action Actions of the End User =Manipulation Observations of the End User =Feedback End UserViewController Model Decisions Interpreted actions Results Actions Action requests Action requests User Interface From a slide by Ari Jaaksi.

17. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa Working together Balance: 7800:- ModelControllerView controller::BalanceWanted() { b = model->GetBalance(); view->ShowBalanceFM(b); }; 7800.00 Balance Get view::GetPressedMM() { controller->BalanceWanted(); }; view::ShowBalanceFM(int b) { TextField.WriteInt(b); }; int model::GetBalance() { return(balance); }; Slide by Ari Jaaksi.

18. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa Peer-To-Peer Computing 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”)

19. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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.

20. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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

21. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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?)

22. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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

23. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa Components - Why? 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.

24. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa ComponentZ ComponentY InterfaceX Component Diagram implements uses Interface – this may also be represented with stereotype > for a class. component

25. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa Component - Interfaces 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.

26. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa Component Technologies Microsoft COM & DCOM (distributed COM) CORBA standard –several vendors –heavyweight system Java Beans

27. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa GameGUI Game Controller GameModel GameModelInterface GameControllerInterface Component Diagram For The Game Application

28. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa User Choose to take card Show funds Card Value Seq. Diagram for ”Take Card”, Component Level Pay (1) Updated funds Turn Card Show card value Add Funds (Value) Show funds GameView GameController GameModel Take card Show funds Show card value Updated funds Show funds

29. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa : GameClient : GameServer : GameModel : GameController : GUI > Deployment Diagram Processing resource (a device, not a device type) Component instance Object – ok, this was a component in an earlier slide, this is just for example

30. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa FRAMEWORKS 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.

31. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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

32. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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”.

33. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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).

34. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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.

35. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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

36. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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.

37. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa Subject {abstract} Subject {abstract} Object {abstract} Object {abstract} update() {abstract} ConcreteSubject ConcereteObserver update() observes * registers for all g in observes { g.update() } attach(x:Observer) detach(x: Observer) notify() Class Diagram for Observer Design Pattern

38. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa :ConcreteSubject t1:ConcreteObserver attach(t1) update() t2:ConcereteObserver attach(t2) notify() update() Changes State A Sequence Diagram For Observer Design Pattern

39. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa 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.

40. Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS DepartmentJyrki Nummenmaa Subject {abstract} Subject {abstract} Object {abstract} Object {abstract} update() {abstract} GameModel GameGUI update() observes * registers for all g in observes { g.update() } attach(x:Observer) detach(x: Observer) notify() Applying The Observer Design Pattern Controller?