270 likes | 313 Views
MVC++ application architecture. Ari Jaaksi. MVC++ application architecture. Model View Controller C++ OMT++ = MVC++. OMT (Rumbaugh et al./ GE). “OMT/NMS” (NTC). Fusion (Coleman et al. / HP). OMT+ (Nokia). UML (Rumbaugh, Booch, Jacobson / Rational). OMT++ (Nokia Networks).
E N D
MVC++ application architecture Ari Jaaksi
MVC++ application architecture Model View Controller C++ OMT++ = MVC++
OMT (Rumbaugh et al./ GE) “OMT/NMS” (NTC) Fusion (Coleman et al. / HP) OMT+ (Nokia) UML (Rumbaugh, Booch, Jacobson / Rational) OMT++ (Nokia Networks) OMT++
Object Analysis Behaviour Analysis User Interface Specification OOA Analysis Class Diagrams Operations, Use Cases Dialogue Diagrams, Operation Specifications OOD Object Design Behaviour Design Design Class Diagrams Sequence Diagrams, Statechart Diagrams OOP Class Specification Class Implementation Class Declarations Implementation of Methods OMT++ process
MVC & OMT++ & C++ => MVC++ • Original MVC (SmallTalk) is Adapted to C++ • Adapted to Java programs • Essential part of OMT++ • Based on agreements • naming • division of labour • communication • Base classes • Text templates
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; } “GUI-Hanger” syndrome
Min=0 Max=400 Value=50 Frame View Abstraction Control Presentation PAC (J.Coutaz) MDI (MFC) Controller View View Application User interface Model Docu ment Docu ment Simple Separation (N.N) MVC Model (Reenskaug) Some application architectures
VIEW CONTROLLER MODEL Objectives of MVC++ 1. To separate applications into parts which each have their own job and purpose, 2. To get more reusable software components, 3. To make software easier to maintain and understand, 4. To fill the gap between the analysis and design phases
Controller -knows how this particular application works -controls the view and the model View -user interface -knows how to communicate with the end user Model -"real world" -works when the controller asks it to work MVC++ triad
Observations of the End User =Feedback Action requests Results User Interface Decisions Actions Interpreted actions Action requests Actions of the End User =Manipulation End User View Controller Model MVC++ application in action
Balance • int model::GetBalance() • { • return(balance); • }; 7800.00 Get controller::BalanceWanted() { b = model->GetBalance(); view->ShowBalanceFM(b); }; view::GetPressedMM() { controller->BalanceWanted(); }; view::ShowBalanceFM(int b) { TextField.WriteInt(b); }; Balance: 7800:- View Controller Model Working together
A typical MVC task 1. The end user manipulates the view (e.g. presses a button). 2. The user's actions are interpreted by the view. 3. The view passes the interpreted commands to the controller. 4. The controller decides what should be done in a situation like this. 5. According to its own intelligence the controller makes the model act. 6. The model acts independently. 7. After the model has completed the tasks, the control returns to the controller. It decides if the changes in the model should cause changes in the view. 8. If so, the controller gets all the information needed from the model. 9. The controller passes the information to the view. 10. The view displays the information in its own way.
View layer • the user interface • contains e.g. the windowing system • all the callback functions of the windowing system • all the widgets of the windowing system • knows how to communicate with the end user • knows how to present things to the end user • knows how to receive the end user’s actions • does not decide what to do with the user’s actions • lets the controller decide • has feedback, manipulation and query methods • has methods like ShowObjectIDFM(), PresentBTSStateFM() to present things to the end user, • has methods like ButtonXXXPressedMM(), SliderYYYMovedMM() to capture the end user’s actions, • has methods like GetSelectionQM(), GetChosenElementQM() to capture the end user’s selections made some time ago • is instantiated by the controller; communicates with the controller
Model layer • the “real world” • is capable of completing “real world” tasks independently • is controlled by the controller • the controller makes the model act • the model is not aware of the view • has methods like GetObjectID(), ChangeBTSState() etc.
Controller layer • brains of the application • makes application specific decisions • knows how this application should behave • controls the application by making the model and the view act • knows WHAT the model and the view are capable of doing • knows WHAT the model and the view should do • doesn’t know HOW things are done inside the model and the view • instantiates the view and often the model too • has corresponding methods for manipulation methods of the view • a typical task: 1. Gets the user’s commands interpreted by the view. 2. Decides what to do with user’s commands. 3. Asks the model to work. (model->ChangeBTSState(...);) 4. Asks the view to present the results. (view->PresentBTSStateFM(...);)
Some facts ... • view part consists of view objects • controller part consists of controller objects • model part consists of model objects • every controller class has a view class of its own • every view class has a controller class of its own • there are typically many controller-view class pairs in an application • there is the main controller controlling the main window and all other controllers • normally every window/dialogue of an application forms a view class
MVC++ application «view» SubViewB «view» MainView «view» SubViewA View Layer 1 1 1 Controller Layer «controller» SubControllerB «controller» MainController «controller» SubControllerA 1 1 1 1 Model Layer 1 ModelA ModelD Could be any cardinality * ModelB ModelC
Very simple view objects Very Simple View 1 «view» SubViewB «view» MainView «view» SubViewA 1 1 1 «controller» SubControllerB «controller» MainController «controller» SubControllerA 1 1 1 1 ModelA ModelD ModelB ModelC
A Query Method • char *xxxView::GetNameQM() • { • return(XmTextGetString(widgetY)); • } A Manipulation Method A Feedback Method • xxxView::ButtonPressedMM() • { • controller->ActionWanted(); • } • xxxView::ShowTextFM(char *txt) • { • XmTextSetString(widgetX,txt); • } Methods of the view • There are three main categories of methods in a view class: • Manipulation Methods (MM) • callback methods, associated with widgets • these methods typically call the controller • Feedback Methods (FM) • these methods are used by the controller • show things to the end user • Query Methods (QM) • these methods are used by the controller • investigate the state of the view
Constructing an MVC hierarchy 0. The main program creates an instance of the program object of the application. 1. The program object creates the main controller. 2. The main controller creates the view that initializes the windowing system 3. The main controller creates its model. 4. The main controller creates controller A 5. Controller A creates its view. 6. Controller A creates its model. 7. The main controller creates controller B 8. Controller B creates its view. 9. Controller B creates its model.
View A View B 5. Creates 8. Creates Controller A Controller B 6. Sets 6. Sets 4. Creates 7. Creates Main 1. Creates 2. Creates Main Controller Main View Program 3. Creates Model C Constructing an MVC hierarchy #2 0. The main program creates an instance of the program object of the application. 1. The program object creates the main controller. 2. The main controller creates the view that initializes the windowing system 3. The main controller creates the model. 4. The main controller creates the controller A 5. Controller A creates its view. 6. The main controller sets a link between the controller A and the model. 7. The main controller creates the controller B 8. Controller B creates its view. 9. The main controller sets a link between controller B and the model.
Attempt to connect a view anda controller class • xxxView_c • ... • xxxcontroller->ActionAsked() • uses • yyyController_c • { • public: • ActionAsked(); • }; • xxxView_c • ... • xxxcontroller->ActionAsked() • uses • xxxController_c • { • public: • ActionAsked(); • }; 1 1 1 1 1 1 NJET!
xxxAbsViewPartner_c • { • ActionAsked{abstract} • }; • xxxAbsViewPartner_c • { • ActionAsked{abstract} • }; Connecting view and controller uses uses • xxxView_c • ... • xxxAbsViewPartner->ActionAsked() • xxxController_c: • public xxxAbsViewPartner • { • public: • ActionAsked(); • }; • xxxView_c • ... • xxxAbsViewPartner->ActionAsked() • yyyController_c: • public xxxAbsViewPartner • { • public: • ActionAsked(); • }; Da!
Abstract partners uses uses Main View Some View Abstract Main View Partner Abstract Some View Partner Abstract Some Controller Partner uses Main Controller Some Controller 1 Program Model A Model B
«mvclib» MVCBase_c «mvclib» MVCViewBase_c «mvclib» MVCControllerBase_c «mvclib» MVCProgramBase_c «mvclib» MVCModelBase_c «mvclib» MVCMainController Base_c «mvclib» MVCMainView Base_c «mvclib» MVCSubController Base_c «mvclib» MVCSubViewBase_c ownPrg_c ownMainCo_c ownSubCo_c ownSubVi_c ownModel_c ownMainVi_c uses Base classes
References • Krasner G.E., Pope S.T., "A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80", Journal of Object-Oriented Programming, August/September, 1988. • Jaaksi A., “Object-Oriented Development of Interactive Systems”, Diss. Tampere University of Technology, Publications 201, 1997. • Jaaksi et al., “Tried & True Object Development - Industry-Proven Approaches with UML”, Cambridge University Press, 1999. • NET internal training material, slidesets...