Microsoft Solutions Framework

Overview (27/02/2000)

Models, principles + practice to solve business problems

· Enterprise Architecture - build enterprise architecture through versioned release. 4 perspectives - business, application, information, technology

· Risk management - Asses probs, determine important risks, implement solutions strategies -> focus on what is important, make decisions and be prepared for future.

· Team model - organise teams, emphasises roles, responsibilities + goals. Produce effective teams

· Process model - milestone based, iterative + flexible life cycle guidance. Identifies phases, milestones, activities +deliverables in relationship to team model. Improves project control.

· Application model - multi-layer, services based approach to s/w development. Permits parallel s/w development, flexible distribution due to modular structure.

· Design presses - 3 phases (conceptual, logical, physical), user centric, parallel + iterative. Ensure apps meet business requirements.

Team model (27/02/2000)

Only starting point, must adapt to own organisation.

Goals: customer satisfaction, delivery within project constraints, meet spec, release after identifying defects, enhanced user performance, smooth deployment

Team roles; product management, program management, development, test, user education, logistics management

Process model (27/02/2000)

Traditional approaches (can't meet needs of current application development.

Waterfall based on milestones - inflexible to changing requirements. Extended analysis periods

Spiral based on iterations - significant admin, frequent product releases -> feelings of instability.

MSF combines both approaches.

Four phases

· Envisioning - shared vision

· Planning - detailed spec

· Developing - produce complete product

· Stabilising - produce stable, deployable product.

Milestone driven

For review and synchronisation, not freezing.

Asses progress and identify corrections

Major milestones - externally visible (seen by customers)

· Team members sync deliverables

· Update those outside project on status

Interim milestones - internally visible

· Track progress

· Break assignments into small pieces

Application model (27/02/2000)

Establish definitions, rules and relationships structuring applications

Basis for idea exchange during logical design

Multi-layer, service based approach

Application = net of cooperative, distributed reliable services

Service accessed through published interfaces

Application architecture (27/02/2000)

Conceptual view of application structure based on consumers and suppliers of services

Current apps (client/server) have 2 layers. Don't scale well. Fat clients (contains data processing logic, etc.)

3 layers

· User layer - data presentation, either native or web

· Business layer - enforce business rules but not tied to any client. Reusable. Available to all. Ensure data validity and integrity.

· Data layer - no knowledge of data locn - relies on data access services (e.g. ADO).

No implication of separate computers (although common)

Use of well defined interfaces -> creation of body of reusable components leading to rapid application development.

Highly scalable (provide additional business layer components to service more users)

Design process (27/02/2000)

Conceptual - view problem from business/user perspective to define problem and solution by scenarios. No account for approach or technologies need for solution. Model easily understood by user - analogous to rough house sketches.

Logical - view from project team to define solution as cooperating services. Produces abstract model of solution. Analogous to floor plans and elevations of a house. C++ developers particularly good here (principles of OO development similar to skills required at this stage).

Physical - view from developer’s perspective to define services and technologies. Add detail to architecture and reflects real world constraints. Output used to produce components, ui, etc.

Phases overlap, their findings affecting each other.

Design considerations (27/02/2000)

Understanding of project among members of team = key requirement.

Must manage complexity - too little and relevant interactions missed, too much -> overly complicated design.

Modularity - start logical design identifying major system services (collection of processes working together to accomplish task).

Abstraction - distil properties + features of items. Classify items through common characteristics. Concentrate on main characteristics, ignore irrelevancies.

Encapsulation - "black box" performing limited, well defined functions correctly. Packages information (data + process) to only expose what should be seen (do not expose inner states). Expose component aspects via interfaces. Permits systems to be assembled out of parts (frequently pre-existing).

Cohesion & coupling - cohesion is how closely operations within a service are relegated. Aim for high cohesion -> easy abstraction + specification. Coupling applies to relationships between services. Weaker coupling ->freedom of design, limited impact on internal operations of services.

Separate interface & implementation - Interface hides implementation -> implementation to change without impacting rest of system. Developers must realise services provide capabilities that act as contracts of service to other modules. Design interfaces to be "open-ended" - if conditions of interface met then advertised service should be supplied.

Explain elements of applications based on MFC framework (12/3/2000)

MFC = C++ classes + global functions -> simplified, rapid windows app development.

Win32 API = common to all 32 bit Windows platforms. Services include; windows management, controls, shell features, GDI, system services, etc. Time consuming to develop apps via Win32 - hence introduction of MFC, e.g. concept of Windows encapsulated by CWnd.

MFC class member functions have same name as Win32 function they emulate.

MFC hides low level aspects of Windows programming - though access still available via Win32 if required.

Use MFC for all but simplest apps. Development advantages outweigh speed and size overhead. Apps without GUI may be easier to implement without MFC (though they may find MFC utility classes useful).

MFC encapsulates most, not all Win32 functionality. Use Win32 to access low level functionality (e.g. network security).

Platform considerations

Although all use Win32, each have unique characteristics. MFC helps hide many of these. For example NT based around Unicode, Winows95/8 on ANSI. By using TCHAR and associated routines (tcslen, tcscat, etc.) differences between character handling hidden. Differing screen coordinates -NT 32 bit, Windows 16 bit addressing.

MFC Class Hierarchy

Relies heavily on inheritance - CObject = base, provides basic services - serialisation, run-time class identification, diagnostics + debugging support.

CCmdTarget = base of class handling Windows messages.

CWnd = base class of object representing windows.

MFC Categories

Application architecture - basic application elements, e.g. CwinApp

User interface - Elements of apps visible to users. Also includes those encapsulating Windows device contexts and GDI.

Collections - Arrays, lists, maps, etc (both template & non-template)

General purpose - Don't encapsulate Win32 API functionality, e.g. data types - points, rects and strings

ActiveX - Framework to provide ActiveX support

Database - ODBC and DAO wrapper classes

Internet - WinInet APIs (client-side) + Internet Server API (ISAPI) (server side)

Global functions - Afx prefix. Provide general-purpose utilities - e.g. AfxMessageBox

Win32 Application Architecture (12/03/2000)

App consists of one or more processes, which are each, a container for one or more threads (one primary and additional secondary threads). When primary thread stops application terminates.

All Windows apps have an entry point called WinMain(). Once started the app proceeds to register window classes that provide details on how windows are to be created and react to system messages.

Windows Messages = method of communication between OS, application and application components. e.g. to start app the os sends a series of messages to which app responds by initialising itself. Primary task of Windows app is to process these messages - developer writes functions to handle appropriate messages.

Processing messages = each thread that creates a windows has associated message queue. All apps have a main application window and message loop. Message loop retrieves messages from queue and dispatches to handler functions. Unhandled messages passed onto default window procedure (provided by windows) that provides default behaviour (e.g. window minimisation). The PostMessage function sends message to queue asynchronously, while SendMessage sends messages synchronously.

Windows Application Essentials

WinMain function acts as entry-point to program

Create instance of applications main window

Implement message loop to relay messages to appropriate handling procedure

Implement window procedure to handle messages.

MFC Application Framework (19/03/2000)

Wraps Win32 API

Provides extra classes representing common application objects + their relationships -> fundamental application behaviour.

Basic framework

· CWinApp representing application, derived from CWinThread. CWinApp = primary app thread - encapsulates, initiation, running and termination. App has only one class derived form CWinApp.
WinMain() implementation calls global functions to perform standard initialisation, launches the apps main message loop and finally class termination code when this loop stops.

· Class for main application window - principle interface to app. Various options - dialog boxes (CDialog), frame windows (CFrameWnd), etc. Windows displayed by call to InitInsance().

Regular vs Extension DLLs

MFC DLLs

Use MFC either through shared DLL or static library. If using dynamic both MFCxx.DLL and MSVCRT.DLL must be available - frequently shipped with app. Shared DLL -> smaller apps (sensible if installing many MFC based apps).

MFC Extension DLLS

If produce classes based on MFC classes and wish to use them in other apps it is common to export them in DLLs. To enable these DLLS to function correctly, e.g. allowing client apps to access functionality of base class the DLL needs to be packaged as an MFC Extension DLL. Option to create extension dll provided by AppWizard during project creation.

MFC Framework message handling

Win32 = supply own window procedure for each registered window class.

MFC = handled by member funcs of application classes (either own or AppWizard generated classes). Messages mapped to funcs by message maps.

Message map = table defined within class definition linking message IDs to handler functions. Recognised four types of messages:

· Windows - generated by OS, inform about window creation, destruction, mouse+ kbd events, etc. Identifiers begin WM_*. Handled by window to which OS sends messages, such as apps main frame window.

· Command - generated from user interaction with UI, e.g. selection of menu item, etc. Produced WM_COMMAND msg + appropriate parms. Framework routes message to application objects -> handling by class closely associated with message.

· UI update - generated by framework (MFC specific). Indicate update to UI status required, e.g. tick marks on menus.

· Control - Sent from controls + other child windows via WM_COMMAND + appropriate parms. e.g. edit control sends WM_COMMAND containing EN_CHANGE notification when text changed.

Creating message maps

Any class derived from CCmdTarget can support message maps. Often can be maintained via ClassWizard.

Handler functions declared within special comment blocks

DECLARE_MESSAGE_MAP() macro:

//{{AFX_MSG(CMyApp)

afx_msg void OnAppAbout();

afx_msg void OnEditPaste();

//}} AFX_MSG

DECLARE_MESSAGE_MAP()

Message map exists between BEGIN_MESSAGE_MAP() and END_MESSAGE_MAP() statements of header file.

Commands mapped by macros within statement

Standard Windows	ON_WM_XXX (XXX = msg name)	None (handled by overloaded functions so don't need provide Handler name)
Command	ON_COMMAND	Command ID, Handler name
Update	ON_UPDATE_COMMAND_UI	Command ID, Handler name
Controlnotification	ON_XXX (XXX = control notification)	Command ID, Handler name

ClassWizard generated map entries within section bounded by {{AFX_MSG ... AFX_MSG}} - don't place own entries within this section.

If use ClassWizard to delete message map will remove entry from map + class declaration, but not implementation in .cpp file (as may contain your code).

MFC command routing -> handle messagein class most closely associated with it. MFC framework routes commands through CCmdTarget derived objects to see which have handlers.

MFC Document / View Architecture (19/03/2000)

Coordinate application data + its views. Implemented by classes generated by AppWizard.

Document = container class for app data.

View = classes through which user interacts with document.

Document may have many views, changes made in one view reflected across all others.

Views maybe implemented from scratch or derived from a control, e.g. trees, lists or edit boxes.

Same drawing logic can be used for both view and print systems.

State saving simplified -> MFC objects derived from CObject that implements serialisation functions.

Apps using document/view architecture derive most benefit from MFC, but MFC can be used without having such a structure.

Can have performance and size costs - not appropriate in all cases, e.g. text file compressor only needs dialog box - main frame window and views not required.

Document/View Objects + related MFC Base Classes

Document	CVocument	Application data
View	CView	Specifies how document data seen + interacted with
Frame window	CFrameWnd	Views displayed in frame windows. If SDI frame window = main frame for application.
Document template	CDocTemplate	Controls creation of documents, views and frame windows.
Application	CWinApp	Controls all above objects, specifies app behaviour (init, cleanup, etc.)

Document templates created (during InitInstance() by call to AddDocTemplate() ) + maintained by application object. Associates document class with resources, frame window and view. In MDI keeps track of open documents.

Document object loads, stores + manages app data + funcs to access/manipulate data. Maintains list of associated views, contains function to force all associated views to redraw them.

View represents client area of application. Presents info held in document + allows input via mouse/keyboard. Only associated with one document - provides accessor function to gain access to the document.

SDI / MDI Applications

SDI only one document frame window at a time - e.g. Paint, WordPad.

MDI multiple document windows open simultaneously within main window - e.g. Word, Excel.

Drawing and Printing Architecture (19/03/2000)

Graphics Device Interface (GDI) = output abstraction. Manages data structure called device context - maintains info about current device, e.g. palette, font, pen width, etc.

In MFC the CDC class encapsulates device context + GDI manipulation routines. Derived classes to support specific needs:

CPaintDC to paint invalid regions of client windows

CClientDC - represents client area of window

CWindowDC encapsulates whole window, including frame

CMetafileDC allows drawing to a metafile.

Output of app data handled by views OnDraw() - function must be implemented by developer (AppWizard only provides skeleton). Pointer to CDC passed to OnDraw(), through this device context drawing functions are called.

OnDraw() calls in the framework (26/03/2000)

Document data change -> redraw of view. Typically happens in response to change via a view. Code updating document data should call document member function UpdateAllViews()

Invalid view receives WM_PAINT message. By default handed by views OnPaint() that creates device context to pass to OnDraw().

Printing & Print Preview (26/03/2000)

Very similar to output to screen – GDI is hardware independent. Same functions called to output to screen, printer, etc. – just provide appropriate CDC.

Differences do exist – when printing must divide document into distinct pages shown one at a time, not just showing what is currently visible within a window. Must also be aware of paper size (legal, A4, etc.)

CView provides provides print-related functions to help implement printing.

Evaluate whether access to DB should be encapsulated

Many apps work with large amounts of data frequently managed by RDBMS, such as Oracle or SQL Server. Desktop databases, such as Access, work on similar principles to RDBMS and will often be employed by applications.

Data Access Interfaces

A number of access interfaces (DAO, ODBC, RDO, UDA, OLE DB, ADO) are available through Windows.

Previously strategy based on Data Access Objects (DAO) for access to desktop databases and Remote Data Objects (RDO) that used Open Database Connectivity (ODBC) to access RDBMS.

New strategy based around Universal Data Access (UDA) providing access to all data. Provides high performance access to both relation and non-relational data in a language independent manner. UDA is implemented through ADO that provides a high level interface to OLE DB (a new COM based data access technology).

Should always use UDA when developing new applications. Generally use ADO as it is easy to use, powerful and high performance. Experienced developers can use OLE DB directly for additional performance gains – VC 6 provides OLE DB Templates to ease this route.

Data Access Objects (DAO)

Native interface to Jet, originally designed for use with VB. Provides set of data access objects encapsulating common database objects – tables, queries, recordsets.

Used to access desktop databases such as Access, FoxPro, Paradox. Can be used to access remote sources.

Exposes COM interfaces, but usually encountered through the MFC DAO database classes.

Open Database Connectivity (ODBC)

Common API for client/server data sources, usually RDBMS (SQL Server, Oracle). Consistent interface -> maximum interoperability – same application can use many different RDBMS.

To connect to RDBMS require an ODBC driver supplied by the RDBMS vendor. To cover different RDBMS capabilities and driver implementations there are three levels of driver conformance available:

· core – all ODBC drivers must meet

· Level 1 – core + additional features, such as transactions, usually available in RDBMS

· Level 2 – Level 1 + advanced features often specific to a particular RDBMS

ODBC drivers installed and configured via ODBC Data Sources applet in control panel. Also used to register Data Source Name (DSN) that is a uniquely named collection of information used by ODBC Driver Manager to connect application to a particular ODBC database. DSNs must be registered on system that will use it – can be stored in a file (file dsn)or the registry (machine dsn). DSNs either installed for a user (user dsn) or computer (system dsn).

ODBC based on SQL. Data accessed from database using SQL statements. Driver translates SQL statements into format required by database.

Provides cursor library allowing iteration across rows of data returned by database.

Using the ODBC API can result in a lot of code, consequently models such as ADO, RDO or the MFC ODBC support classes are more commonly used.

Remote Data Objects (RDO)

Thin object layer to ODBC similar to that used by DAO but without memory requirements needed to support local database. Provides additional features such as server side cursors, disconnected recordsets, asynchronous processing.

Objects exposed through COM. The Data Source Control = ActiveX control encapsulating query and recordset retrieval. Permits browsing of recordset and display using data-bound ActiveX controls such as DBGrid and DBList.

OLE DB

COM interfaces providing uniform access to data stored in diverse information sources, regardless of location or type. Open spec to build on success of ODBC. Access to both relation and non-relational data sources – mainframe and desktop databases, e-mail, file systems, spreadsheets, project management tools, etc.

Three component types; data consumers, service components and data providers.

Data Consumers

Applications or components using data exposed by data providers. Any app using ADO is a data consumer.

Service Components

Process or transport data to extend functionality of data providers. Examples include query processors that generate or optimise queries, cursor engines that consume data from a sequential source to provide scrollable data.

Data Providers

Applications such as SQL Server, Exchange, etc. that expose their data to others. Provide OLE DB interfaces that data consumers or service components can access. A provider is available for ODBC thus making any ODBC data source available to OLE DB data consumers.

ActiveX Data Objects (ADO)

High performance, easy to use API to OLE DB. Small footprint, minimal network traffic and small number of layers between application and data source.

Expose COM Automation interface – accessible to all RAD tools, development tools, databases, scripting languages, etc.

Designed to combine best features of and replace RDO and DAO -> similar conventions.

Provides ADO Data Control – improved version of RDO Data Source Control.

Can transport over HTTP as well as DCOM -> data-centric web applications.