Entity frame work architecture

http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework

Learn .Net

http://msdn.microsoft.com/en-us/vstudio/aa496123 -- Learn .Net

http://msdn.microsoft.com/library/vstudio/hh156542

SubVersion

http://pythonconquerstheuniverse.wordpress.com/2011/03/16/learning-subversion-the-mystery-of-svn-2/


https://ariejan.net/2006/11/24/svn-how-to-structure-your-repository


 

Service Locator Pattern --a specilised version of Inversion of control

http://www.martinfowler.com/articles/injection.html

Use the Service Locator pattern to achieve any of the following objectives:

• You want to decouple your classes from their dependencies so that these dependencies can be replaced or updated with little or no change to the classes.
• You want to write logic that depends on classes whose concrete implementation is not known at compile time.
• You want to be able to test your classes in isolation, without the dependencies.
• You do not want the logic that locates and manages the dependencies to be in your classes.
• You want to divide your application into loosely coupled modules that can be independently developed, tested, versioned, and deployed.

Solution

Create a service locator that contains references to the services and that encapsulates the logic that locates them. In your classes, use the service locator to obtain service instances. The following diagram illustrates how classes use a service locator.

How classes use a service locator

The Service Locator pattern does not describe how to instantiate the services. It describes a way to register services and locate them. Typically, the Service Locator pattern is combined with the Factory pattern and/or the Dependency Injection pattern. This combination allows a service locator to create instances of services.

Example;
In Business we used the wcf.Unity and wcf service host factory

Repository Pattern

The Repository Pattern is a common construct to avoid duplication of data access logic throughout our application. This includes direct access to a database, ORM, WCF dataservices, xml files and so on. The sole purpose of the repository is to hide the nitty gritty details of accessing the data. We can easily query the repository for data objects, without having to know how to provide things like a connection string. The repository behaves like a freely available in-memory data collection to which we can add, delete and update objects.
The Repository pattern adds a separation layer between the data and domain layers of an application. It also makes the data access parts of an application better testable.

Use the Repository pattern to achieve one or more of the following objectives:

• You want to maximize the amount of code that can be tested with automation and to isolate the data layer to support unit testing.
• You access the data source from many locations and want to apply centrally managed, consistent access rules and logic.
• You want to implement and centralize a caching strategy for the data source.
• You want to improve the code's maintainability and readability by separating business logic from data or service access logic.
• You want to use business entities that are strongly typed so that you can identify problems at compile time instead of at run time.
• You want to associate a behavior with the related data. For example, you want to calculate fields or enforce complex relationships or business rules between the data elements within an entity.
• You want to apply a domain model to simplify complex business logic.

Use a repository to separate the logic that retrieves the data and maps it to the entity model from the business logic that acts on the model. The business logic should be agnostic to the type of data that comprises the data source layer. For example, the data source layer can be a database, a SharePoint list, or a Web service.
The repository mediates between the data source layer and the business layers of the application. It queries the data source for the data, maps the data from the data source to a business entity, and persists changes in the business entity to the data source. A repository separates the business logic from the interactions with the underlying data source or Web service. The separation between the data and business tiers has three benefits:

• It centralizes the data logic or Web service access logic.
• It provides a substitution point for the unit tests.
• It provides a flexible architecture that can be adapted as the overall design of the application evolves.

Repositories are bridges between data and operations that are in different domains. A common case is mapping from a domain where data is weakly typed, such as a database or SharePoint list, into a domain where objects are strongly typed, such as a domain entity model.

Repositories often use the Data Mapper pattern to translate between representations.

project 2010

http://cdn-smooth.ms-studiosmedia.com/msstudios/1005/1003463/Mod_2_Planning_Design_and_Deployment/Default.html


http://www.brighthubpm.com/agile/124334-a-guide-to-agile-project-management/

Architect’s Class

  

Architect's Master Class


 
   Home     Services      Industry Leadership      About IDesign      Customers      Downloads      Contact Us   
 

  
  The Architect’s Master Class  
Overview
 While many developers and managers have a clear idea regarding the characteristics, practices, and corresponding set of responsibilities of their roles, the picture is often vague when it comes to software architects. What is the single most important task facing the software architect? What is the division of labor and responsibilities between the architect and the project manager? How much the architecture should be tied in to the particulars of the underlying technology used, or for that matter, for the specifics of the business? Where is the hand-off point between the architect and the developers? What are the necessary skills and analysis tools employed by an architect? How do you validate the design before construction begins? How do methodologies such as service-orientation affect the design and development process? What are software architecture's best practices, guidelines and pitfalls? How do you go about designing world-class systems? How do you make the transition from abstract design patterns and concepts to concrete development decisions? How does the architect decompose the system into its sub system and modules?
IDesign's flagship offering, the Architect’s Master Class, is the ultimate resource for the professional architect.
The class answers the above questions and more, and teaches the architect how to take an active leadership role in process, design, and technology. You will learn how to lead your team through the use of effective software processes, how to best leverage key technologies for the implementation of Service Oriented Architectures (SOA), and how to apply the IDesign Method™.
This 5 days training class is conducted by a Master Architect who shares his vast experience and perspective with the students, imparting both knowledge and insight, ensuring your success as a modern software architect. The IDesign Master architect will provide the common foundation required by software architects, both technical and soft skills. The class sets the focus on the why and the rationale behind particular design decisions, often shedding light on poorly understood aspects.
Noteworthy is that this class is called the Architect’s Master Class (as opposed to the Architecture Master Class) because it is dedicated to the core body of knowledge required of today’s modern software architects, knowledge that transcends mere design patterns and architecture. The core body of knowledge comprises of three elements: development process, technology, and finally analysis & design. The class shows the architect how to take an active leadership role on all three aspects, as a continuum, since in order to deliver high-quality, affordable solutions, one cannot separate process from design from technology – all three have to work in concert. The class also points out classic mistakes and risk mitigations across the process, technology and design. The agenda reflects these three elements. The first part is devoted to the accompanying service-oriented development process and the required project management skills. The second part is an immersion in key modern design patterns and development skills, using WCF as a reference model, as a way of illustrating the design ideas and best practices, ensuring the architect is a qualified technical lead.. This section of the class also includes a detailed projection of the next platform after .NET, and how to best prepare for it.
In the last part the IDesign architect will explain the IDesign original approach to large system analysis and design called the IDesign Method - a breakthrough, battle-proven approach to software architecture providing a significant reduction in the effort and time required for architecting, designing, and implementing software solutions. The IDesign Method distils the IDesign's accumulative lessons learned over more than a decade of architecting systems across numerous projects, industries, countries, and teams. The IDesign Method has three elements: it is a method for decomposing a system into modules or services based on the system top-level uses cases, the IDesign Method offers a set of very simple design notations to capture the design decisions, and a near-mechanical approach for automating the design decision of rarely discussed topics such as allocation of services to assemblies, allocation of services to processes, transaction boundaries, identity management, authorization and authentication boundaries, synchronization and more. To demonstrate the IDesign Method in action, the Architect Master Class will conclude in an interactive design session where the Master Architect will use the IDesign Method on a system provided by the students (a short version of what we focus on in our Architecture Clinics).
In the class you will also receive the IDesign documents and diagram templates, tools and samples, and reference projects.
Don’t miss on this unique opportunity to learn and improve your architecture skills with IDesign, and share our passion for architecture and software engineering, gain from our experience of numerous design projects and profound insight on architecture, technology and its applications.
Target Audience
Any .NET architect, project lead or senior developer would benefit greatly from the class.
Duration
5 very intense days.
 Outline  
The Architect
Software development as engineering
Types of architects
The role of the architect
Architects and technology
Architects and the business
Service-Oriented Development Process
Project planning
Estimation and tracking
Documentation
Requirement management and traceability
Configuration management
Quality control
Design for performance
Services simulation and emulation
Peer reviews
Development standards
Metrics collection
Visibility management
Introduction to Service-Orientation
Why service orientation
Service-oriented architecture
Service-oriented applications
WCF Essentials
Service-oriented programming
WCF architecture
Implementation considerations
Service Contract Design and Factoring
Service contract design
Contract factoring techniques
Contract metrics
Service-Oriented Design Patterns and Best Practices
Data contracts and data contracts versioning
Instance management and throttling
Operations and event management
Service discovery
Windows Azure AppFabric service bus
Transaction management and consistency
Concurrent management, responsiveness and availability
Design for security
Service Granularity
Every class as a service?
Performance consideration and perspective
WCF benchmarks
Beyond .NET and WCF
The future platform
Design and Architecture
The IDesign Method
Service decomposition
Use cases analysis
Assembly allocation
Run-time processes design
Identity management
Authentication
Authorization
Transaction flow
Synchronization
The Method in Action
The interview thought process
Use cases analysis
Service decomposition
Architecture diagrams
Process Groupthink
What about Monday
The pitfall of Groupthink
Architect as agent of change
 Upcoming Classes  
November 12-16, Los Gatos, CA (Register now to secure a seat!)
December 10-14, Belgium
February 25-March 1, Sydney, Australia
April 22-26, London, United Kingdom
Subscribe to the offerings feed
 Testimonials  
After taking the WCF Master Class last year, I felt the Architects Master Class would be the perfect follow up to take things to the next level. This class is light years ahead of the industry in terms of content and the sheer volume of knowledge the IDesign team presented. It’s a unique experience to be able to see the world through the eyes of world class architects, learn their techniques and way of thinking.
Stuart Snaddon
Software Engineer
United Kingdom

--------------------------------------------------------------------------------

IDesign’s Architect’s class is far and away the best training class I have ever taken. It transcends technological trends and gives you practical knowledge that will be useful for almost any platform and for the rest of your career. Easily the best thing I've spent my money on in quite a while.
Geoff Heeren
Lead Architect
Emportal

--------------------------------------------------------------------------------

The Architect’s Master Class rigorous approach to software design and development will enable you to engage in software architecture as an engineering discipline. I can see how my past failures could have been prevented if I had applied the IDesign method. My understanding of what the software architect is actually supposed to do has been clarified and reshaped by the class. The IDesign Architect’s Master Class is an essential part of any software architect’s training. You should not in good conscience call yourself a software architect if you don’t posses the skills and techniques presented in the class.
Russ Ferrill
Software Engineer
Vendor Safe Technologies

--------------------------------------------------------------------------------

Attending the Architect Master Class by Juval Lowy was simply the most rewarding professional experience of my career. The material was a world class combination of methodology, process, and technology that no one else in the industry is teaching. Juval’s extensive experience and knowledge base allowed him to present the material in a historical context that changed my perspective on current technologies in ways I did not previously think possible. I also thoroughly enjoyed Juval’s witty presentation style which kept me on my toes and, more importantly for such an intense class, kept my attention firmly focused. I now feel more prepared than ever to take my career to new heights and continue to build upon my newfound knowledge. I would recommend this class to any serious Architect looking for that elusive next level of enlightenment. Thank you Juval!
Joe Crabtree
Solutions Architect
SharePoint360

--------------------------------------------------------------------------------

It has to be the most influential and profound course I have ever undertaken; it has given me a depth and breadth of knowledge that was unbelievable.
Robert Dyball
WorkCover NSW

--------------------------------------------------------------------------------

Wanted to thank you for the highly impressive Architect’s Master Class.
I have never walked out of any training, whatsoever, so stunned as walking out of this. It has the exact mixture of practical and theoretical content. My only regret is that it didn't last longer :)
I have already started talking with our project managers and architects about process leadership and the role of an architect.
Thanks Again,
Ally Pearl
SharePoint Consultant
OBS

--------------------------------------------------------------------------------

The Architect’s Master course was the single most relevant and useful professional training I’ve ever attended. Juval brings his deep experience and Zen master-like wisdom to the class and makes it easy to apply the lessons to real world scenarios. If you are lucky enough to attend, you will emerge from the class, a lean, mean, service-oriented machine.
David Carrico
System Architect
ITG

--------------------------------------------------------------------------------

Thanks for sharing your wisdom and experience to us and it was the best technical class I have ever attended. You have provided answers to many of the lingering questions I used to have and that too without me asking all these questions, again it was wonderful and enchanting class.
Manoj Garg
FIS Global

--------------------------------------------------------------------------------

I just wanted to thank IDesign for the class, Brian for teaching it, and Juval for promoting it to me. I used things it taught me immediately in my work and found the ideas presented to be quite excellent. I would even say those that gave testimonials were not blowing smoke on this whatsoever. If anything they are underselling it. I started architecting my current system based on your methods, and am finding it to be a really intelligent way to go about my work. Juval, everything you said is coming out in spades. I feel I can handle pretty much anything that is thrown at me and I will create a great system for my company. Thanks again for the class and the ideas presented.
Steve Portock
Software Architect
St. Louis, Missouri

--------------------------------------------------------------------------------

IDesign has a unique way of presenting the design alternatives and narrowing them down to the best practices. The Architect's Master Class will teach you everything you need to know about architecting and building service-oriented applications. Not only will you walk away with a great learning experience, you will also have a host of tools and examples that you can put to work in your applications right away. This alone saved us months of development time and effort.
Michael Marchiondo
Spectrum Technology Consultants
Columbus, OH

--------------------------------------------------------------------------------

The incredible amount of experience and knowledge presented during the Architect’s Master class, in a few unbelievable days, has completely changed the way I think about software architecture. One of the main takeaways is the IDesign Method which is simple and effective was of designing systems. The method is so clear, simple and to the point that it can be implemented into our existing or future projects immediately, improving project schedules and increasing quality.
Camilo Orozco
Bioinformatics Programmer
GNF

--------------------------------------------------------------------------------

I wanted to let you know how impressed I was with the Architect’s Master Class. I have had a somewhat chequered career and for the last ten years or so have been in IT. During that time, I have attended more lectures, training courses and conferences than I care to count, but never have I walked out of any them as affected as last week left me. The course was entertaining, enormously thought provoking and yet, still managed to walk that fine line between theoretical and practical content. More importantly, it reignited my enthusiasm for the industry and my role in it. In addition, I will be seriously adopting the IDesign process for a project that we are just commencing. It is also the case that the knowledge that you divulged during the course will form part of our core architectural direction over the coming few years; in particular, your ‘every class as a service’ approach has ignited a great deal of curiosity and excitement amongst our senior developers!
Thanks Again,
Malcolm Young
General Manager, Architecture and Technology
F1 Solutions

--------------------------------------------------------------------------------

The IDesign Architect’s Master class was first rate. I never thought it was possible to learn so much in a few days, and my only regret is that the class was not longer. Juval’s clarity of thinking, precise examples, and anecdotal information has enabled me to start thinking more like a software architect. I highly recommended for anyone contemplating an architecture career or needing to work closely with architects.
Blair Shaw
Senior Consultant
Microsoft Partner Services
Redmond, Washington

--------------------------------------------------------------------------------

The IDesign Architect's Master Class is a true awakening. Juval spoke candidly about our software development crisis and presented his insight and solutions. His incredible knowledge of the software development history and methodical analysis of its evolution and future enlighten and inspire me. I am eager to apply the IDesign Method and WCF in our future projects along with the IDesign effective software development process using the templates for project management, top-level design, and share these techniques with management and fellow developers at Circle K.
Chao-Sha Huang
Senior Software Engineer
Circle K Stores

--------------------------------------------------------------------------------

The class was a mind blower, and a perfect educational complement to the WCF class. Juval was on fire. By the end of the week he had led the discussion beyond skills and techniques to address the larger concerns of professional and personal responsibility, which was truly inspirational. (And daunting. He sets the bar so high.)
Steve Taylor
Technical Lead
HEA Consulting

--------------------------------------------------------------------------------

Software architecture is engineering. Design and development of software systems must be done using a methodology that demystifies the process, reigns in technology and complexity and enables the teams’ productivity. The Architect’s Masters Class targets precisely these goals. The curriculum is built from Juval’s amazing in-depth understanding of architecture and original analysis techniques along with years of actual experience. All elements give architects the skills to deliver successfully on quality, on schedule, on budget, on features, for now and as the system evolve. I consider this the graduate class for real world Architects charged with providing solutions to real world businesses.
Joshua Dees
VP of MIS
Black Diamond Equipment Ltd.

--------------------------------------------------------------------------------

For anyone who has ever wondered if there is a better way of creating software, the Architect’s Master Class is nothing short of a revelation. Juval Löwy systematically demolishes (seemingly) all conventional-wisdom of software best-practice with precision, contextual honesty and reasoned argument; by the end of the first day you can already feel your consciousness being raised to a level you never knew existed. At the same time, he deconstructs each of his original teaching modules with crystal-clarity, coupled with the wit and good-humour of a master raconteur. As such, your attention is held with relentless focus for five gruelling days, during which Juval takes it upon himself to instil in you his vast experience as a world-class engineer. Microsoft recognizes him as a ‘Software Legend’, but to anyone who wants to be the best they can be, he is simply the Maestro.
Dr Riccardo Bennett-Lovsey
Senior Programmer Analyst
London, UK

--------------------------------------------------------------------------------

Simply put, the IDesign alumni that referred me to the Architect's Master Class described it as "career-altering," and he is not one for hyperbole. The class was the finest 5-day training I have been to in the last 10 years. Most classes focus only on technology, and by the end of day 5 you want to poke your eyes out with your laptop. The Architect's Master Class on the other hand, I could've done for another week. In fact, I will be back for your clinic next March. I have the benefit of having excellent sponsors that fully support my professional development, and that of my team. When I told them about the class and the clinic, they said "go!"
Ted Assur
IT Solutions Architect
Providence Health & Services

--------------------------------------------------------------------------------

I wanted to thank you for a (professional) life changing week. Usually I can't sit at class more than 50% of the time - it is boring and they don't teach me anything I couldn't teach myself or already know. In the Architect's Master Class I set for 9 hours a day and couldn't have enough of it: I learned what are my responsibilities as an architect (I thought the architect is only the software designer), the engineering aspect of software, the importance of delivering not only on time but also on budget and on quality, not to wait to "grow" to be an architect but to manage my career, and how to quantify and measure what I previously considered as hunches. I have much more insight from this week and many pieces are in place now. I can't wait to attend the Architecture Clinic and the other Master Classes.
Itai Zolberg
Software Architect
Tel Aviv, Israel

--------------------------------------------------------------------------------

I want to thank you again for the Architect's Master Class. You took me apart and put me back together again. I have known for years that the best way to do class design is to encapsulate what will change--that's what design patterns are all about. And yet it has eluded me for so long that this same concept is to be applied to architecture. It is so simple, so elegant, and was right under my nose for all of this time. I have been looking through the IDesign Alumni forum and it is an absolute gold mine, a treasure trove of knowledge and experience. Access to this alone is well worth the cost of the class. Taking the Architect's Master Class has been one of the few defining inflection points in my career. I have been searching for this material for years and have come up empty handed so many times. Thank you for putting this material together, for teaching it and for pushing our profession (and passion) towards a legitimate engineering discipline. I look forward to hearing from you on the forums and in upcoming clinics.
Cris Zamora
Senior Architect and Project Lead
Seamless
Salt Lake City, UT

--------------------------------------------------------------------------------

 
  

© 2012 IDesign, Inc. All rights reserved. | Hosted by OrcsWeb.

Tools Used

Fiddler:
Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.
Fiddler is freeware and can debug traffic from virtually any application that supports a proxy, including Internet Explorer, Google Chrome, Apple Safari, Mozilla Firefox, Opera, and thousands more. You can also debug traffic from popular devices like Windows Phone, iPod/iPad, and others.
To debug applications you've written in Java, .NET, or using WinHTTP

Presentation skills

http://focs.wordpress.com/2007/09/12/9-tips-how-to-give-a-technical-presentation/

Practice a lot, dont read , say it from your heart, speak slowly and clearly,
each presentation have a climax and a start up.

web.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />
    <!--<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />-->
    <sectionGroup name="common">
      <section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
    </sectionGroup>
    <section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog"/>
    <sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />  
  </configSections>
  <common>
    <logging>
      <factoryAdapter type="Common.Logging.NLog.NLogLoggerFactoryAdapter, Common.Logging.NLog">
        <arg key="configType" value="INLINE" />
      </factoryAdapter>
    </logging>
  </common>
  <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <targets>
      <target name="logfile" xsi:type="File" fileName="${basedir}/Logs/ServiceLog.txt"  layout="${date}: ${message}"/>
    </targets>
    <rules>
      <logger name="*" minlevel="Info" writeTo="logfile" />
    </rules>
  </nlog>
  <unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
    <namespace name="Medrisk.BusinessServices.WcfServices.v1" />
    <namespace name="Medrisk.BusinessServices.DataAccess" />
    <namespace name="Medrisk.BusinessServices.Business" />
    <namespace name="Microsoft.Practices.Unity" />
    <namespace name="Microsoft.Practices.Unity.Configuration" />
    <namespace name="Medrisk.BusinessServices.Business.Entities" />
    <assembly name="Medrisk.BusinessServices.WcfServices" />
    <assembly name="Medrisk.BusinessServices.DataAccess" />
    <assembly name="Medrisk.BusinessServices.Business" />
    <assembly name="Microsoft.Practices.Unity" />
    <assembly name="Microsoft.Practices.Unity.Configuration" />
    <container name="unity">
      <register type="PackageEntities" mapTo="PackageEntities" name="defaultPackageEntities">
        <lifetime type="HierarchicalLifetimeManager"></lifetime>
        <constructor>
          <param name="connectionString" value="name=PackageEntities"></param>
        </constructor>
      </register>
      <register type="IUnitOfWork" mapTo="UnitOfWork" name="defaultUnitOfWork">
        <lifetime type="HierarchicalLifetimeManager"></lifetime>
        <constructor>
          <param name="context" dependencyType="PackageEntities" dependencyName="defaultPackageEntities" />
        </constructor>
      </register>
      <register type="IPackageService" mapTo="PackageService">
        <lifetime type="HierarchicalLifetimeManager" />
        <property name="UnitOfWork" dependencyType="IUnitOfWork" dependencyName="defaultUnitOfWork" />
      </register>
    </container>
  </unity>
  <connectionStrings>
    <add name="PackageEntities" connectionString="metadata=res://*/Entities.PackageEntities.csdl|res://*/Entities.PackageEntities.ssdl|res://*/Entities.PackageEntities.msl;provider=System.Data.SqlClient;provider connection string='Data source=MRSQLDEV01;initial catalog=Medrisk;integrated security=True;multipleactiveresultsets=True;App=EntityFramework'" providerName="System.Data.EntityClient" />
  </connectionStrings>
  <system.web>
    <caching>
      <outputCacheSettings>
        <outputCacheProfiles>
          <add name="PackageQueryCacheProfile" enabled="true" duration="0" noStore="true" varyByParam=""/>
        </outputCacheProfiles>
      </outputCacheSettings>
    </caching>
    <compilation debug="true" targetFramework="4.0">
      <assemblies>
        <add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      </assemblies>
    </compilation>
    <customErrors mode="Off" />
    <identity impersonate="false" />
    <authorization>
    </authorization>
  </system.web>
  <system.webServer>
    <security>
      <access sslFlags="None" />
      <authentication>
        <iisClientCertificateMappingAuthentication enabled="false" oneToOneCertificateMappingsEnabled="true"></iisClientCertificateMappingAuthentication>
      </authentication>
    </security>
    <validation validateIntegratedModeConfiguration="false" />
    <modules>
      <remove name="UrlRoutingModule-4.0" />
      <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
    </modules>
    <handlers>
      <remove name="SimpleHandlerFactory-Integrated" />
      <add name="SimpleHandlerFactory-Integrated" path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode" />
    </handlers>
  </system.webServer>
  <system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true">
      <serviceActivations>
        <add factory="Medrisk.BusinessServices.WcfServices.WcfServiceFactory" service="Medrisk.BusinessServices.WcfServices.v1.PackageService" relativeAddress="v1/PackageService.svc" />
      </serviceActivations>
    </serviceHostingEnvironment>
    <behaviors>
      <endpointBehaviors>
        <behavior name="restfulBehavior">
          <webHttp helpEnabled="true" automaticFormatSelectionEnabled="true" defaultOutgoingResponseFormat="Xml" />
        </behavior>
        <behavior name="soapyBehavior">
          <wsdlExtensions location="v1/PackageService.svc" singleFile="true" />
        </behavior>
      </endpointBehaviors>
      <serviceBehaviors>
        <behavior name="productionServiceBehavior">
          <serviceMetadata httpGetEnabled="false" httpsGetEnabled="false" />
          <serviceDebug includeExceptionDetailInFaults="false" />
          <serviceAuthorization impersonateCallerForAllOperations="true" principalPermissionMode="UseAspNetRoles" />
          <serviceCredentials>
            <clientCertificate>
              <authentication mapClientCertificateToWindowsAccount="true" certificateValidationMode="PeerTrust" revocationMode="NoCheck" />
            </clientCertificate>
          </serviceCredentials>
          <auditLogging />
        </behavior>
        <behavior name="defaultServiceBehavior">         
          <serviceMetadata httpGetEnabled="true" httpsGetEnabled="false" />
          <serviceDebug includeExceptionDetailInFaults="true" />
          <auditLogging />
        </behavior>       
      </serviceBehaviors>
    </behaviors>
    <extensions>
      <behaviorExtensions>
        <add name="auditLogging" type="Medrisk.BusinessServices.WcfServices.Behaviors.CallAuditorServiceElement, Medrisk.BusinessServices.WcfServices, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
        <add name="wsdlExtensions" type="WCFExtrasPlus.Wsdl.WsdlExtensionsConfig, WCFExtrasPlus, Version=2.3.0.2, Culture=neutral, PublicKeyToken=f8633fc5451b43fc" />
      </behaviorExtensions>
    </extensions>
    <bindings>
      <basicHttpBinding>
        <binding name="secureBasicBinding">
          <security mode="Transport">
            <transport clientCredentialType="Certificate" />
          </security>
        </binding>
      </basicHttpBinding>
      <webHttpBinding>
        <binding name="secureWebBinding">
          <security mode="Transport">
            <transport clientCredentialType="Certificate" />
          </security>
        </binding>
      </webHttpBinding>
    </bindings>
    <services>
      <service behaviorConfiguration="defaultServiceBehavior" name="Medrisk.BusinessServices.WcfServices.v1.PackageService">
        <host>
        </host>
        <endpoint address="/rest" behaviorConfiguration="restfulBehavior" binding="webHttpBinding" bindingConfiguration="" name="PacakgeServiceRest.v1" bindingNamespace="http://services.medrisknet.com/business/v1" contract="Medrisk.BusinessServices.WcfServices.v1.IPackageService">
          <identity>
          </identity>
        </endpoint>
        <endpoint address="/soap" behaviorConfiguration="soapyBehavior" binding="basicHttpBinding" bindingConfiguration="" name="PackageServiceSoap.v1" bindingNamespace="http://services.medrisknet.com/business/v1" contract="Medrisk.BusinessServices.WcfServices.v1.IPackageService">
          <identity>
          </identity>
        </endpoint>
      </service>
    </services>
  </system.serviceModel> 
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="NLog" publicKeyToken="5120e14c03d0593c" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>
+++++++++++++++++++++++++++++

Unity :
Unity is a lightweight, extensible dependency injection container that supports interception, constructor injection, property injection, and method call injection. You can use Unity in a variety of different ways to help decouple the components of your applications, to maximize coherence in components, and to simplify design, implementation, testing, and administration of these applications.
Unity is a general-purpose container for use in any type of Microsoft® .NET Framework-based application. It provides all of the features commonly found in dependency injection mechanisms, including methods to register type mappings and object instances, resolve objects, manage object lifetimes, and inject dependent objects into the parameters of constructors and methods and as the value of properties of objects it resolves.
+++++++++++++++++
Common Logging

interview questions

capgemini:

1. what is durable binding.

2. how can use the https on the site but client site will use only http , what are the configurations u need to change
3.aspnet compatibilty
4. file less activation
5. reader quotes
6.what is a durable service
7. how can u calll a service from service library.
diff between service lib and wcf application
9.how can ur call wcf from sql server-- make service library call from sql clr, get the response into a table and access.
10 synoonyms
11 partial class -- can have the same signature , compilation error
12. extension methods
13.how can u make same sp run on different servers when one of the tables in one of the servers does not have a column ?
14.how do u optimeze an so?
15linq, specialilty
16.string and string builder?
17.linq and dictionary how to convert a lingq into data dictionary
18. wcf data services
19. webinvoke
20.service behaviour settings
21sql clr-- how do u use
22.how to dynamically call a web service from client--channel factory
23.use service host attribute and other on svc file
24. calling webservice from aspx site, without adding reference - proxy
25. how can u make a windows service a wcf service and a wcf service a windows service
26.wcf library uses


how does load balancing work
hwo does entity framework interact with the database
can u access web.config from java script
commandfactory pattern

1.what will u do if a web applicaiton crashes.
2.performance testing
3. unit testing if cr has come
4. shadowing ,
5. table variable, temp table
6. msg, transport security
7.throttling,
8. what if only one server is there and load is high forscalability

How can you make changes to the existing webservice, and deploy withut changing the code on the client.
 

Loading Master Pages dynamically

Loading master pages dynamically is useful in 2 situations.
1. u can enable users ot customize the apperance of the website by loading differnent master pages. u can display a menu of masterpages and allow ur users to pick thier favorite layout.

2. in co-branding.when users link to one site to another partner website, they should not be aware of travelling to a new website, u can maintain this illusion by dynamically loading differernt master pages based on a query string passed from a partner site.

Master page can only be loaded in page preinit event.
To enable this for multiple content pages, create a base page . and register it in the web configuration file.

using system;
suing system.web.ui;
using system.web.profile;
public class dynamicmasteroage:page
{
protected override void onPreInit(Eventargs e)
{ this.MasterPageFile = (string )Context.profile['MasterPageFile'];
base.OnpreInit(e);
}
}

Solution Architect Requirements

Description:
• Ability to take the functional and non-functional requirements and proposesolution that will be able to meet the requirements.
• Work with the designteam to realize the architecture by providing suggestions on design options.
• Review and validate the design decisions taken by the design teams.
• Workwith client architecture teams in - validate the non-functional requirements -discussing and providing inputs on architecture options
• Present thearchitecture and design to necessary stake holders as required. 6. Workingexperience with at least one common SDLC methods
• Understanding and experience on architectural components for a BPM Platform.This would include all the layers in the stack, viz. Presentation,Process/Rules Execution/orchestration, Integration.
• Ability to architect a BPMplatform/app from scratch or migration from an existing platform.
• Experience ofworking on one or more BPMS tools in an end-to-end BPM project.

Application Architect

Bascially check on any Software Design/Architecture book for basic understanding. You need to start with requirements to use case scenarios, then sequence diagram, system architecture design, component diagram, class diagram and database design like that.


Paper published in IEEE Software 12 (6)
November 1995, pp. 42-50
Architectural Blueprints—The “4+1” View
Model of Software Architecture
Philippe Kruchten
Rational Software Corp.
Abstract
This article presents a model for describing the architecture of software-intensive systems, based on the use
of multiple, concurrent views. This use of multiple views allows to address separately the concerns of the
various ‘stakeholders’ of the architecture: end-user, developers, systems engineers, project managers, etc.,
and to handle separately the functional and non functional requirements. Each of the five views is described,
together with a notation to capture it. The views are designed using an architecture-centered, scenariodriven,
iterative development process.
Keywords: software architecture, view, object-oriented design, software development process
Introduction
We all have seen many books and articles where one diagram attempts to capture the gist of the architecture
of a system. But looking carefully at the set of boxes and arrows shown on these diagrams, it becomes clear
that their authors have struggled hard to represent more on one blueprint than it can actually express. Are
the boxes representing running programs? Or chunks of source code? Or physical computers? Or merely
logical groupings of functionality? Are the arrows representing compilation dependencies? Or control
flows? Or data flows? Usually it is a bit of everything. Does an architecture need a single architectural
style? Sometimes the architecture of the software suffers scars from a system design that went too far into
prematurely partitioning the software, or from an over-emphasis on one aspect of software development:
data engineering, or run-time efficiency, or development strategy and team organization. Often also the
architecture does not address the concerns of all its “customers” (or “stakeholders” as they are called at
USC). This problem has been noted by several authors: Garlan & Shaw1, Abowd & Allen at CMU,
Clements at the SEI. As a remedy, we propose to organize the description of a software architecture using
several concurrent views, each one addressing one specific set of concerns.
An Architectural Model
Software architecture deals with the design and implementation of the high-level structure of the software. It
is the result of assembling a certain number of architectural elements in some well-chosen forms to satisfy
the major functionality and performance requirements of the system, as well as some other, non-functional
requirements such as reliability, scalability, portability, and availability. Perry and Wolfe put it very nicely
in this formula2, modified by Boehm:
Software architecture = {Elements, Forms, Rationale/Constraints}
Software architecture deals with abstraction, with decomposition and composition, with style and esthetics.
To describe a software architecture, we use a model composed of multiple views or perspectives. In order to
eventually address large and challenging architectures, the model we propose is made up of five main views
(cf. fig. 1):
• The logical view, which is the object model of the design (when an object-oriented design method is
used),
• the process view, which captures the concurrency and synchronization aspects of the design,
• the physical view, which describes the mapping(s) of the software onto the hardware and reflects its
distributed aspect,
2
• the development view, which describes the static organization of the software in its development
environment.
The description of an architecture—the decisions made—can be organized around these four views, and
then illustrated by a few selected use cases, or scenarios which become a fifth view. The architecture is in
fact partially evolved from these scenarios as we will see later.
Logical View Development
View
Process View Physical View
Scenarios
Programmers
Software management
System engineers
Topology
Communications
Integrators
Performance
Scalability
End-user
Functionality
Figure 1 — The “4+1” view model
We apply Perry & Wolf’s equation independently on each view, i.e., for each view we define the set of
elements to use (components, containers, and connectors) , we capture the forms and patterns that work, and
we capture the rationale and constraints, connecting the architecture to some of the requirements.
Each view is described by a blueprint using its own particular notation. For each view also, the architects
can pick a certain architectural style, hence allowing the coexistence of multiple styles in one system.
We will now look in turn at each of the five views, giving for each its purpose: which concerns is addresses,
a notation for the corresponding architectural blueprint, the tools we have used to describe and manage it.
Small examples are drawn from the design of a PABX, derived from our work at Alcatel Business System
and an Air Traffic Control system3, but in very simplified form—the intent here is just to give a flavor of
the views and their notation and not to define the architecture of those systems.
The “4+1” view model is rather “generic”: other notations and tools can be used, other design methods can
be used, especially for the and the logical and process decompositions, but we have indicated the ones we
have used with success.
3
The Logical Architecture
The Object-Oriented Decomposition
The logical architecture primarily supports the functional requirements—what the system should provide in
terms of services to its users. The system is decomposed into a set of key abstractions, taken (mostly) from
the problem domain, in the form of objects or object classes. They exploit the principles of abstraction,
encapsulation, and inheritance. This decomposition is not only for the sake of functional analysis, but also
serves to identify common mechanisms and design elements across the various parts of the system. We use
the Rational/Booch approach for representing the logical architecture, by means of class diagrams and class
templates.4 A class diagram shows a set of classes and their logical relationships: association, usage,
composition, inheritance, and so forth. Sets of related classes can be grouped into class categories. Class
templates focus on each individual class; they emphasize the main class operations, and identify key object
characteristics. If it is important to define the internal behavior of an object, this is done with state transition
diagrams, or state charts. Common mechanisms or services are defined in class utilities.
Alternatively to an OO approach, an application that is very data-driven may use some other form of logical
view, such as E-R diagrams.
Notation for the logical view
The notation for the logical view is derived from the Booch notation4. It is considerably simplified to take
into account only the items that are architecturally significant. In particular, the numerous adornments are
not very useful at this level of design. We use Rational Rose® to support the logical architecture design.
Components
Class
Parameterized
Class
Class Utility
Class category
Association
Containment,
Aggregation
Usage
Inheritance
Instanciation
Connectors
Figure 2 — Notation for the logical blueprint
Style for the logical view
The style we use for the logical view is an object-oriented style. The main guideline for the design of the
logical view is to try to keep a single, coherent object model across the whole system, to avoid premature
specialization of classes and mechanisms per site or per processor.
4
Examples of Logical blueprints
Figure 3a shows the main classes involved in the Télic PABX architecture.
Conversation
Terminal
Controller Numbering
Plan
Connection
Services
Translation
Services
Simulation
and Training
Flight
management
Air Traffic
Management
External
Interfaces
-Gateways
Aeronautical
Information
Basic
elements
Mechanisms
Services
Display &
User
Interface
Figure 3— a. Logical blueprint for the Télic PABX . b. Blueprint for an Air Traffic Control System
A PABX establishes commmunications between terminals. A terminal may be a telephone set, a trunk line
(i.e., line to central-office), a tie line (i.e., private PABX to PABX line), a feature phone line, a data line, an
ISDN line, etc. Different lines are supported by different line interface cards. The responsibility of a line
controller object is to decode and inject all the signals on the line interface card, translating card-specific
signals to and from a small, uniform set of events: start, stop, digit, etc. The controller also bears all the
hard real-time constraints. This class has many subclasses to cater for different kinds of interfaces. The
responsibility of the terminal object is to maintain the state of a terminal, and negotiate services on behalf of
that line. For example, it uses the services of the numbering plan to interpret the dialing in the selection
phase. The conversation represents a set of terminals engaged in a conversation. The conversation uses
translation services (directory, logical to physical address mapping, routes), and connection services to
establish a voice path between the terminals.
For a much bigger system, which contains a few dozen classes of architectural significance, figure 3b show
the top level class diagram of an air traffic control system, containing 8 class categories (i.e., groups of
classes).
The Process Architecture
The Process Decomposition
The process architecture takes into account some non-functional requirements, such as performance and
availability. It addresses issues of concurrency and distribution, of system’s integrity, of fault-tolerance, and
how the main abstractions from the logical view fit within the process architecture—on which thread of
control is an operation for an object actually executed.
The process architecture can be described at several levels of abstraction, each level addressing different
concerns. At the highest level, the process architecture can be viewed as a set of independently executing
logical networks of communicating programs (called “processes”), distributed across a set of hardware
resources connected by a LAN or a WAN. Multiple logical networks may exist simultaneously, sharing the
same physical resources. For example, independent logical networks may be used to support separation of
the on-line operational system from the off-line system, as well as supporting the coexistence of simulation
or test versions of the software.
A process is a grouping of tasks that form an executable unit. Processes represent the level at which the
process architecture can be tactically controlled (i.e., started, recovered, reconfigured, and shut down). In
5
addition, processes can be replicated for increased distribution of the processing load, or for improved
availability.
The software is partitioned into a set of independent tasks. A task is a separate thread of control, that can be
scheduled individually on one processing node.
We can distinguish then: major tasks, that are the architectural elements that can be uniquely addressed and
minor tasks, that are additional tasks introduced locally for implementation reasons (cyclical activities,
buffering, time-outs, etc.). They can be implemented as Ada tasks for example, or light-weight threads.
Major tasks communicate via a set of well-defined inter-task communication mechanisms: synchronous and
asynchronous message-based communication services, remote procedure calls, event broadcast, etc. Minor
tasks may communicate by rendezvous or shared memory. Major tasks shall not make assumptions about
their collocation in the same process or processing node.
Flow of messages, process loads can be estimated based on the process blueprint. It is also possible to
implement a “hollow” process architecture with dummy loads for the processes, and measure its
performance on the target system, as described by Filarey et al. in their Eurocontrol experiment.
Notation for the Process view
The notation we use for the process view is expanded from the notation originally proposed by Booch for
Ada tasking. Again the notation used focuses on the elements that are architecturally significant. (Fig. 4)
Message
Remote Procedure Call
Message, bidirectional
Event broadcast
Periodic process
adornment
Process
Unspecified
Components Connectors
Simplified
Process
(Indicates a cyclical process)
Figure 4 — Notation for the Process blueprint
We have used the Universal Network Architecture Services (UNAS) product from TRW to architect and
implement the set of processes and tasks (and their redundancies) into networks of processes. UNAS
contains a tool—the Software Architects Lifecycle Environment (SALE)—which supports such a notation.
SALE allows for the graphical depiction of the process architecture, including specifications of the possible
inter-task communication paths, from which the corresponding Ada or C++ source code is automatically
generated. The benefit of this approach to specifying and implementing the process architecture is that
changes can be incorporated easily without much impact on the application software.
Style for the process view
Several styles would fit the process view. For example, picking from Garlan and Shaw’s taxonomy1 we can
have: pipes and filters, or client/server, with variants of multiple client/single server and multiple
clients/multiple servers. For more complex systems, one could use a style similar to the process groups
approach of the ISIS system as described by K. Birman with another notation and toolset.
6
Example of a Process blueprint
Controller task
Low rate
Controller task
High rate
Main
controller
task
Controller
process
Terminal
process
Figure 5 — Process blueprint for the Télic PABX (partial)
All terminals are handled by a single terminal process, which is driven by messages in its input queues. The
controller objects are executed on one of three tasks that composes the controller process: a low cycle rate
task scans all inactive terminals (200 ms), puts any terminal becoming active in the scan list of the high
cycle rate task (10ms), which detects any significant change of state, and passes them to the main controller
task which interprets the changes and communicates them by message to the corresponding terminal. Here
message passing within the controller process is done via shared memory.
The Development Architecture
Subsystem decomposition
The development architecture focuses on the actual software module organization on the software
development environment. The software is packaged in small chunks—program libraries, or subsystems—
that can be developed by one or a small number of developers. The subsystems are organized in a hierarchy
of layers, each layer providing a narrow and well-defined interface to the layers above it.
The development architecture of the system is represented by module and subsystem diagrams, showing the
‘export’ and ‘import’ relationships. The complete development architecture can only be described when all
the elements of the software have been identified. It is, however, possible to list the rules that govern the
development architecture: partitioning, grouping, visibility.
For the most part, the development architecture takes into account internal requirements related to the ease
of development, software management, reuse or commonality, and to the constraints imposed by the toolset,
or the programming language. The development view serves as the basis for requirement allocation, for
allocation of work to teams (or even for team organization), for cost evaluation and planning, for
monitoring the progress of the project, for reasoning about software reuse, portability and security. It is the
basis for establishing a line-of-product.
Notation for the Development Blueprint
Again, a variation of the Booch notation, limiting it to the items that are architecturally significant.
7
Reference
Compilation dependency
(include, "with")
Module
Subsystem
Components Connectors
Layer
Figure 5 — Notation for the Development blueprint
The Apex Development Environment from Rational supports the definition and the implementation of the
development architecture, the layering strategy described above, and the enforcement of the design rules.
Rational Rose can draw the development blueprints at the module and subsystem level, in forward
engineering and by reverse engineering from the development source code, for Ada and C++.
Style for the Development View
We recommend adopting a layered style for the development view, defining some 4 to 6 layers of
subsystems. Each layer has a well-defined responsibility. The design rule is that a subsystem in a certain can
only depend on subsystem that are in the same layer or in layers below, in order to minimize the
development of very complex networks of dependencies between modules and allow simple release
strategies layer by layer.
Common utilities Bindings
Low-level services
Support Mechanisms:
Communication, Time, Storage,
Resource management, etc.
Aeronautical classes
ATC classes
ATC Functional areas: Flight management,
Sector Management, etc.
Man-Machine Interface
External systems
Off-line tools
Test harnesses
HardWare, OS, COTS
Basic elements
Distributed Virtual Machine
ATC Framework
HATS Components
CAATS, MAATS, etc... 5
1
2
3
4
Figure 6 — The 5 layers of Hughes Air Traffic Systems (HATS)
Example of Development architecture
Figure 6 represents the development organization in five layers of a line-of-product of Air Traffic Control
systems developed by Hughes Aircraft of Canada3. This is the development architecture corresponding to
the logical architecture shown in fig. 3b.
Layers 1 and 2 constitute a domain-independent distributed infrastructure that is common across the line of
products and shields it from variations in hardware platform, operating system, or off-the-shelf products
8
such as database management system. To this infrastructure, layer 3 adds an ATC framework to form a
domain-specific software architecture. Using this framework a palette of functionality is build in layer 4.
Layer 5 is very customer- and product-dependent, and contains most of the user-interface and interfaces
with the external systems. Some 72 subsystems are spread across of the 5 layers, containing each from 10 to
50 modules, and can be represented on additional blueprints.
The Physical Architecture
Mapping the software to the hardware
The physical architecture takes into account primarily the non-functional requirements of the system such as
availability, reliability (fault-tolerance), performance (throughput), and scalability. The software executes
on a network of computers, or processing nodes (or just nodes for short). The various elements identified—
networks, processes, tasks, and objects—need to be mapped onto the various nodes. We expect that several
different physical configurations will be used: some for development and testing, others for the deployment
of the system for various sites or for different customers. The mapping of the software to the nodes
therefore needs to be highly flexible and have a minimal impact on the source code itself.
Notation for the Physical Blueprint
Physical blueprints can become very messy in large systems, so they take several forms, with or without the
mapping from the process view.
Processor
Communication line
Communication
(non permanent)
Uni-directional communication
High bandwidth communication,
Bus
Other device
Components Connectors
Figure 7 — Notation for the Physical blueprint
UNAS from TRW provide us here with data-driven means of mapping the process architecture onto the
physical architecture allowing a large class of changes in the mapping without source code modifications.
Example of Physical blueprint
K K K K
F
Primary
F
backup
K K K K
F
Primary
F
backup
C
primary
C
backup
Figure 8 — Physical blueprint for the PABX
Figure 8 shows one possible hardware configuration for a large PABX, whereas figures 9 and 10 show
mappings of the process architecture on two different physical architectures, corresponding to a small and a
large PABX. C, F and K are three types of computers of different capacity, supporting three different
executables.
Controller
Process
Terminal
Process
Conversation
process
F
K
Figure 9 — A small PABX physical architecture with process allocation
9
Controller
Process
Terminal
Process
Conversation
process
Pseudo Central
process
F
Controller
Process
Terminal
Process
Conversation
process
Pseudo Central
process
F
Central
Process
C
K K
line cards line cards
Controller
Process
K
line cards
Back-up nodes
more K
processors
Figure 10 — Physical blueprint for a larger PABX showing process allocation
Scenarios
Putting it all together
The elements in the four views are shown to work together seamlessly by the use of a small set of important
scenarios —instances of more general use cases—for which we describe the corresponding scripts
(sequences of interactions between objects, and between processes) as described by Rubin and Goldberg6.
The scenarios are in some sense an abstraction of the most important requirements. Their design is
expressed using object scenario diagrams and object interaction diagrams4.
This view is redundant with the other ones (hence the “+1”), but it serves two main purposes:
• as a driver to discover the architectural elements during the architecture design as we will describe later
• as a validation and illustration role after this architecture design is complete, both on paper and as the
starting point for the tests of an architectural prototype.
Notation for the Scenarios
The notation is very similar to the Logical view for the components (cf. fig. 2), but uses the connectors of
the Process view for interactions between objects (cf. fig. 4). Note that object instances are denoted with
solid lines. As for the logical blueprint, we capture and manage object scenario diagrams using Rational
Rose.
Example of a Scenario
Fig. 11 shows a fragment of a scenario for the small PABX. The corresponding script reads:
1. The controller of Joe’s phone detects and validate the transition from on-hook to off-hook and sends a
message to wake up the corresponding terminal object.
2. The terminal allocates some resources, and tells the controller to emit some dial-tone.
3. The controller receives digits and transmits them to the terminal.
4. The terminal uses the numbering plan to analyze the digit flow.
5. When a valid sequence of digits has been entered, the terminal opens a conversation.
10
Joe:Controller Joe:Terminal Numbering plan
(1) Off-Hook
(2) dial tone
(3) digit
(4) digit
(5) open
conversation
:Conversation
Figure 11 — Embryo of a scenario for a local call—selection phase
Correspondence Between the Views
The various views are not fully orthogonal or independent. Elements of one view are connected to elements
in other views, following certain design rules and heuristics.
From the logical to the process view
We identify several important characteristics of the classes of the logical architecture:
• Autonomy: are the objects active, passive, protected?
-an active object takes the initiative of invoking other objects’ operations or its own operations, and has
full control over the invocation of its own operations by other objects
-a passive object never invokes spontaneously any operations and has no control over the invocation of
its own operations by other objects
- a protected object never invokes spontaneously any operations but performs some arbitration on the
invocation of its operations.
• Persistence: are the objects transient , permanent? Do they the failure of a process or processor?
• Subordination: are the existence or persistence of an object depending on another object?
• Distribution: are the state or the operations of an object accessible from many nodes in the physical
architecture, from several processes in the process architecture?
In the logical view of the architecture we consider each object as active, and potentially “concurrent,” i.e.,
behaving “in parallel” with other objects, and we pay no more attention to the exact degree of concurrency
we need to achieve this effect. Hence the logical architecture takes into account only the functional aspect
of the requirements.
However when we come to defining the process architecture, implementing each object with its own thread
of control (e.g., its own Unix process or Ada task) is not quite practical in the current state of technology,
because of the huge overhead this imposes. Moreover, if objects are concurrent, there must be some form of
arbitration for invoking their operations.
On another hand, multiple threads of control are needed for several reasons:
• To react rapidly to certain classes of external stimuli, including time-related events
• To take advantage of multiple CPUs in a node, or multiple nodes in a distributed system
• To increase the CPU utilization, by allocating the CPU to other activities while some thread of control
is suspended waiting for some other activity to complete (e.g., access to some external device, or access
to some other active object)
• To prioritize activities (and potentially improve responsiveness)
• To support system scalability (with additional processes sharing the load)
• To separate concerns between different areas of the software
• To achieve a higher system availability (with backup processes)
We use concurrently two strategies to determine the ‘right’ amount of concurrency and define the set of
processes that are needed. Keeping in mind the set of potential physical target architectures, we can proceed
either:
• Inside-out:
Starting from the logical architecture: define agent tasks which multiplex a single thread of control
11
across multiple active objects of a class; objects whose persistency or life is subordinate to an active
object are also executed on that same agent; several classes that need to be executed in mutual
exclusion, or that require only small amount of processing share a single agent. This clustering
proceeds until we have reduced the processes to a reasonably small number that still allows distribution
and use of the physical resources.
• Outside-in:
Starting with the physical architecture: identify external stimuli (requests) to the system, define client
processes to handle the stimuli and servers processes that only provide services and do not initiate
them; use the data integrity and serialization constraints of the problem to define the right set of
servers, and allocate objects to the client and servers agents; identify which objects must be distributed.
The result is a mapping of classes (and their objects) onto a set of tasks and processes of the process
architecture. Typically, there is an agent task for an active class, with some variations: several agents for a
given class to increase throughput, or several classes mapped onto a single agent because their operations
are infrequently invoked or to guarantee sequential execution.
Note that this is not a linear, deterministic process leading to an optimal process architecture; its requires a
few iterations to get an acceptable compromise. There are numerous other ways to proceed, as shown by
Birman et al.5 or Witt et al.7 for example. The precise method used to construct the mapping is outside of
the scope of this article, but we can illustrate it on a small example.
Fig. 12 shows how a small set of classes from some hypothetical air-traffic control system maybe mapped
onto processes.
The flight class is mapped onto a set of flight agents: there are many flights to process, a high rate of
external stimuli, response time is critical, the load must be spread across multiple CPUs. Moreover the
persistency and distribution aspects of the flight processing are deferred to a flight server, which is
duplicated for availability reasons.
A flight profile or a clearance are always subordinate to a flight, and although there are complex classes,
they share the processes of the flight class. Flights are distributed to several other processes, notably for to
display and external interfaces.
A sectorization class, which established a partitioning of airspace for the assignment of jurisdiction of
controllers over flights, because of its integrity constraints, can be handled only by a single agent, but can
share the server process with the flight: updates are infrequent.
Locations and airspace and other static aeronautical information are protected objects, shared among
several classes, rarely updated; they are mapped on their own server, and distributed to other processes.
12
flight
clearance profile
sectorization
location airspace
flight
profile
clearance
sectorization
location
airspace
multiple flight agents flight server
Single sectorization agent
aeronautical info
server
backup
Backup
Figure 12: Mapping from Logical to Process view
From logical to development
A class is usually implemented as a module, for example a type in the visible part of an Ada package. Large
classes are decomposed into multiple packages. Collections of closely related classes—class categories—
are grouped into subsystems. Additional constraints must be considered for the definition of subsystems,
such as team organization, expected magnitude of code (typically 5K to 20K SLOC per subsystem), degree
of expected reuse and commonality, and strict layering principles (visibility issues), release policy and
configuration management. Therefore we usually end up with a view that does not have a one to one
correspondence with the logical view.
The logical and development views are very close, but address very different concerns. We have found that
the larger the project, the greater the distance between these views. Similarly for the process and physical
views: the larger the project, the greater the distance between the views. For example, if we compare fig. 3b
and fig. 6, there is no one to one mapping of the class categories to the layers. If we take the ‘External
interfaces—Gateway’ category, its implementation is spread across several layers: communications
protocols are in subsystems in or below layer 1, general gateway mechanisms are in subsystems in layer 2,
and the actual specific gateways in layer 5 subsystems.
From process to physical
Processes and process groups are mapped onto the available physical hardware, in various configurations
for testing or deployment. Birman describes some very elaborate schemes for this mapping in the Isis
project5.
The scenarios relate mostly to the logical view, in terms of which classes are used, and to the process view
when the interactions between objects involve more than one thread of control.
13
Tailoring the Model
Not all software architecture need the full “4+1” views. Views that are useless can be omitted from the
architecture description, such as the physical view, if there is only one processor, and the process view if
there is only process or program. For very small system, it is even possible that the logical view and the
development view are so similar that they do not require separate descriptions. The scenarios are useful in
all circumstances.
Iterative process
Witt et al. indicate 4 phases for the design or an architecture: sketching, organizing, specifying and
optimizing, subdivided into some 12 steps7. They indicate that some backtracking may be needed. We think
that this approach is too “linear” for an ambitious and rather unprecedented project. Too little is known at
the end of the 4 phases to validate the architecture. We advocate a more iterative development, were the
architecture is actually prototyped, tested, measured, analyzed, and then refined in subsequent iterations.
Besides allowing to mitigate the risks associated with the architecture, such an approach has other side
benefits for the project: team building, training, acquaintance with the architecture, acquisition of tools, runin
of procedures and tools, etc. (We are speaking here of an evolutionary prototype, that slowly grows into
becoming the system, and not of throw-away, exploratory prototypes.) This iterative approach also allows
the requirements to be refined, matured, better understood.
A scenario-driven approach
The most critical functionality of the system is captured in the form of scenarios (or use cases). By critical
we mean: functions that are the most important, the raison d’être of the system, or that have the highest
frequency of use, or that present some significant technical risk that must be mitigated.
Start:
• A small number of the scenarios are chosen for an iteration based on risk and criticality. Scenarios
may be synthesized to abstract a number of user requirements.
• A strawman architecture is put in place. The scenarios are then “scripted” in order to identify major
abstractions (classes, mechanisms, processes, subsystems) as indicated by Rubin and Goldberg6 —
decomposed in sequences of pairs (object, operation).
• The architectural elements discovered are laid out on the 4 blueprints: logical, process, development,
and physical.
• This architecture is then implemented, tested, measured, and this analysis may detect some flaws or
potential enhancement.
• Lessons learned are captured.
Loop:
The next iteration can then start by:
• reassessing the risks,
• extending the palette of scenarios to consider
• selecting a few additional scenarios that will allow risk mitigation or greater architecture
coverage
Then:
• Try to script those scenarios in the preliminary architecture
• discover additional architectural elements, or sometimes significant architectural changes that
need to occur to accommodate these scenarios
• update the 4 main blueprints: logical, process, development, physical
• revise the existing scenarios based on the changes
• upgrade the implementation (the architectural prototype) to support the new extended set of
scenario.
• Test. Measure under load, in real target environment if possible.
• All five blueprints are then reviewed to detect potential for simplification, reuse, commonality.
• Design guidelines and rationale are updated.
• Capture the lessons learned.
End loop
The initial architectural prototype evolves to become the real system. Hopefully after 2 or 3 iterations, the
architecture itself become stable: no new major abstractions are found, no new subsystems or processes, no
14
new interfaces. The rest of the story is in the realm of software design, where, by the way, development may
continue using very similar methods and process.
The duration of these iterations varies considerably: with the size of the project to put in place, with the
number of people involved and their familiarity with the domain and with the method, and with the degree
of “unprecedentedness” of the system w.r.t. this development organization. Hence the duration of an
iteration may be 2-3 weeks for a small project (e.g., 10 KSLOC), or up to 6-9 months for a large command
and control system (e.g., 700 KSLOC).
Documenting the architecture
The documentation produced during the architectural design is captured in two documents:
• A Software Architecture Document, whose organization follows closely the “4+1” views (cf. fig. 13 for
a typical outline)
• A Software Design Guidelines, which captures (among other things) the most important design
decisions that must be respected to maintain the architectural integrity of the system.
Title Page
Change History
Table of Contents
List of Figures
1. Scope
2. References
3. Software Architecture
4. Architectural Goals & Constraints
5. Logical Architecture
6. Process Architecture
7. Development Architecture
8. Physical Architecture
9. Scenarios
10. Size and Performance
11. Quality
Appendices
A. Acronyms and Abbreviations
B. Definitions
C. Design Principles
Figure 13 — Outline of a Software Architecture Document
Conclusion
This “4+1” view model has been used with success on several large projects with or without some local
customization and adjustment in terminology4. It actually allowed the various stakeholders to find what they
want to know about the software architecture. Systems engineers approach it from the Physical view, then
the Process view. End-users, customers, data specialists from the Logical view. Project managers, software
configuration staff see it from the Development view.
Other sets of views have been proposed and discussed, within Rational and elsewhere, for instance by
Meszaros (BNR), Hofmeister, Nord and Soni (Siemens), Emery and Hilliard (Mitre)8, but we have found
that often these other views proposed could usually be folded into one of the 4 we described. For example a
Cost & Schedule view folds into the Development view, a Data view into the Logical view, an Execution
view into a combination of the Process and Physical view.
View Logical Process Development Physical Scenarios
Components Class Task Module,
Subsystem
Node Step,
Scripts
Connectors association,
inheritance,
containment
Rendez-vous,
Message,
broadcast,
RPC, etc.
compilation
dependency,
“with” clause,
“include”
Communication
medium,
LAN, WAN,
bus, etc.
Containers Class category Process Subsystem
(library)
Physical
subsystem
Web
15
Stakeholders End-user System
designer,
integrator
Developer,
manager
System
designer
End-user,
developer
Concerns Functionality Performance,
availability,
S/W faulttolerance,
integrity
Organization,
reuse,
portability, lineof-
product
Scalability,
performance,av
ailability
Understandability
Tool support Rose UNAS/SALE
DADS
Apex, SoDA UNAS,
Openview
DADS
Rose
Table 1 — Summary of the “4+1” view model
Acknowledgments
The “4+1” view model owes its existence to many colleagues at Rational, at Hughes Aircraft of Canada, at
Alcatel, and elsewhere. In particular I would like to thank for their contributions Ch. Thompson, A. Bell, M.
Devlin, G. Booch, W. Royce, J. Marasco, R. Reitman, V. Ohnjec, and E. Schonberg.
References
1. D. Garlan & M. Shaw, “An Introduction to Software Architecture,” Advances in Software
Engineering and Knowledge Engineering, Vol. 1, World Scientific Publishing Co. (1993).
2. D. E. Perry & A. L. Wolf, “Foundations for the Study of Software Architecture,” ACM Software
Engineering Notes, 17, 4, October 1992, 40-52.
3. Ph. Kruchten & Ch. Thompson, “An Object-Oriented, Distributed Architecture for Large Scale Ada
Systems,” Proceedings of the TRI-Ada ’94 Conference, Baltimore, November 6-11, 1994, ACM,
p.262-271.
4. G. Booch: Object-Oriented Analysis and Design with Applications, 2nd. edition, Benjamin-Cummings
Pub. Co., Redwood City, California, 1993, 589p.
5. K. P. Birman, and R. Van Renesse, Reliable Distributed Computing with the Isis Toolkit, IEEE
Computer Society Press, Los Alamitos CA, 1994.
6. K. Rubin & A. Goldberg, “Object Behavior Analysis,” CACM, 35, 9 (Sept. 1992) 48-62
7. B. I. Witt, F. T. Baker and E. W. Merritt, Software Architecture and Design—Principles, Models, and
Methods, Van Nostrand Reinhold, New-York (1994) 324p.
8. D. Garlan (ed.), Proceedings of the First Internal Workshop on Architectures for Software Systems,
CMU-CS-TR-95-151, CMU, Pittsburgh, 1995.
















Paper published in IEEE Software 12 (6)
November 1995, pp. 42-50
Architectural Blueprints—The “4+1” View
Model of Software Architecture
Philippe Kruchten
Rational Software Corp.
Abstract
This article presents a model for describing the architecture of software-intensive systems, based on the use
of multiple, concurrent views. This use of multiple views allows to address separately the concerns of the
various ‘stakeholders’ of the architecture: end-user, developers, systems engineers, project managers, etc.,
and to handle separately the functional and non functional requirements. Each of the five views is described,
together with a notation to capture it. The views are designed using an architecture-centered, scenariodriven,
iterative development process.
Keywords: software architecture, view, object-oriented design, software development process
Introduction
We all have seen many books and articles where one diagram attempts to capture the gist of the architecture
of a system. But looking carefully at the set of boxes and arrows shown on these diagrams, it becomes clear
that their authors have struggled hard to represent more on one blueprint than it can actually express. Are
the boxes representing running programs? Or chunks of source code? Or physical computers? Or merely
logical groupings of functionality? Are the arrows representing compilation dependencies? Or control
flows? Or data flows? Usually it is a bit of everything. Does an architecture need a single architectural
style? Sometimes the architecture of the software suffers scars from a system design that went too far into
prematurely partitioning the software, or from an over-emphasis on one aspect of software development:
data engineering, or run-time efficiency, or development strategy and team organization. Often also the
architecture does not address the concerns of all its “customers” (or “stakeholders” as they are called at
USC). This problem has been noted by several authors: Garlan & Shaw1, Abowd & Allen at CMU,
Clements at the SEI. As a remedy, we propose to organize the description of a software architecture using
several concurrent views, each one addressing one specific set of concerns.
An Architectural Model
Software architecture deals with the design and implementation of the high-level structure of the software. It
is the result of assembling a certain number of architectural elements in some well-chosen forms to satisfy
the major functionality and performance requirements of the system, as well as some other, non-functional
requirements such as reliability, scalability, portability, and availability. Perry and Wolfe put it very nicely
in this formula2, modified by Boehm:
Software architecture = {Elements, Forms, Rationale/Constraints}
Software architecture deals with abstraction, with decomposition and composition, with style and esthetics.
To describe a software architecture, we use a model composed of multiple views or perspectives. In order to
eventually address large and challenging architectures, the model we propose is made up of five main views
(cf. fig. 1):
• The logical view, which is the object model of the design (when an object-oriented design method is
used),
• the process view, which captures the concurrency and synchronization aspects of the design,
• the physical view, which describes the mapping(s) of the software onto the hardware and reflects its
distributed aspect,
2
• the development view, which describes the static organization of the software in its development
environment.
The description of an architecture—the decisions made—can be organized around these four views, and
then illustrated by a few selected use cases, or scenarios which become a fifth view. The architecture is in
fact partially evolved from these scenarios as we will see later.
Logical View Development
View
Process View Physical View
Scenarios
Programmers
Software management
System engineers
Topology
Communications
Integrators
Performance
Scalability
End-user
Functionality
Figure 1 — The “4+1” view model
We apply Perry & Wolf’s equation independently on each view, i.e., for each view we define the set of
elements to use (components, containers, and connectors) , we capture the forms and patterns that work, and
we capture the rationale and constraints, connecting the architecture to some of the requirements.
Each view is described by a blueprint using its own particular notation. For each view also, the architects
can pick a certain architectural style, hence allowing the coexistence of multiple styles in one system.
We will now look in turn at each of the five views, giving for each its purpose: which concerns is addresses,
a notation for the corresponding architectural blueprint, the tools we have used to describe and manage it.
Small examples are drawn from the design of a PABX, derived from our work at Alcatel Business System
and an Air Traffic Control system3, but in very simplified form—the intent here is just to give a flavor of
the views and their notation and not to define the architecture of those systems.
The “4+1” view model is rather “generic”: other notations and tools can be used, other design methods can
be used, especially for the and the logical and process decompositions, but we have indicated the ones we
have used with success.
3
The Logical Architecture
The Object-Oriented Decomposition
The logical architecture primarily supports the functional requirements—what the system should provide in
terms of services to its users. The system is decomposed into a set of key abstractions, taken (mostly) from
the problem domain, in the form of objects or object classes. They exploit the principles of abstraction,
encapsulation, and inheritance. This decomposition is not only for the sake of functional analysis, but also
serves to identify common mechanisms and design elements across the various parts of the system. We use
the Rational/Booch approach for representing the logical architecture, by means of class diagrams and class
templates.4 A class diagram shows a set of classes and their logical relationships: association, usage,
composition, inheritance, and so forth. Sets of related classes can be grouped into class categories. Class
templates focus on each individual class; they emphasize the main class operations, and identify key object
characteristics. If it is important to define the internal behavior of an object, this is done with state transition
diagrams, or state charts. Common mechanisms or services are defined in class utilities.
Alternatively to an OO approach, an application that is very data-driven may use some other form of logical
view, such as E-R diagrams.
Notation for the logical view
The notation for the logical view is derived from the Booch notation4. It is considerably simplified to take
into account only the items that are architecturally significant. In particular, the numerous adornments are
not very useful at this level of design. We use Rational Rose® to support the logical architecture design.
Components
Class
Parameterized
Class
Class Utility
Class category
Association
Containment,
Aggregation
Usage
Inheritance
Instanciation
Connectors
Figure 2 — Notation for the logical blueprint
Style for the logical view
The style we use for the logical view is an object-oriented style. The main guideline for the design of the
logical view is to try to keep a single, coherent object model across the whole system, to avoid premature
specialization of classes and mechanisms per site or per processor.
4
Examples of Logical blueprints
Figure 3a shows the main classes involved in the Télic PABX architecture.
Conversation
Terminal
Controller Numbering
Plan
Connection
Services
Translation
Services
Simulation
and Training
Flight
management
Air Traffic
Management
External
Interfaces
-Gateways
Aeronautical
Information
Basic
elements
Mechanisms
Services
Display &
User
Interface
Figure 3— a. Logical blueprint for the Télic PABX . b. Blueprint for an Air Traffic Control System
A PABX establishes commmunications between terminals. A terminal may be a telephone set, a trunk line
(i.e., line to central-office), a tie line (i.e., private PABX to PABX line), a feature phone line, a data line, an
ISDN line, etc. Different lines are supported by different line interface cards. The responsibility of a line
controller object is to decode and inject all the signals on the line interface card, translating card-specific
signals to and from a small, uniform set of events: start, stop, digit, etc. The controller also bears all the
hard real-time constraints. This class has many subclasses to cater for different kinds of interfaces. The
responsibility of the terminal object is to maintain the state of a terminal, and negotiate services on behalf of
that line. For example, it uses the services of the numbering plan to interpret the dialing in the selection
phase. The conversation represents a set of terminals engaged in a conversation. The conversation uses
translation services (directory, logical to physical address mapping, routes), and connection services to
establish a voice path between the terminals.
For a much bigger system, which contains a few dozen classes of architectural significance, figure 3b show
the top level class diagram of an air traffic control system, containing 8 class categories (i.e., groups of
classes).
The Process Architecture
The Process Decomposition
The process architecture takes into account some non-functional requirements, such as performance and
availability. It addresses issues of concurrency and distribution, of system’s integrity, of fault-tolerance, and
how the main abstractions from the logical view fit within the process architecture—on which thread of
control is an operation for an object actually executed.
The process architecture can be described at several levels of abstraction, each level addressing different
concerns. At the highest level, the process architecture can be viewed as a set of independently executing
logical networks of communicating programs (called “processes”), distributed across a set of hardware
resources connected by a LAN or a WAN. Multiple logical networks may exist simultaneously, sharing the
same physical resources. For example, independent logical networks may be used to support separation of
the on-line operational system from the off-line system, as well as supporting the coexistence of simulation
or test versions of the software.
A process is a grouping of tasks that form an executable unit. Processes represent the level at which the
process architecture can be tactically controlled (i.e., started, recovered, reconfigured, and shut down). In
5
addition, processes can be replicated for increased distribution of the processing load, or for improved
availability.
The software is partitioned into a set of independent tasks. A task is a separate thread of control, that can be
scheduled individually on one processing node.
We can distinguish then: major tasks, that are the architectural elements that can be uniquely addressed and
minor tasks, that are additional tasks introduced locally for implementation reasons (cyclical activities,
buffering, time-outs, etc.). They can be implemented as Ada tasks for example, or light-weight threads.
Major tasks communicate via a set of well-defined inter-task communication mechanisms: synchronous and
asynchronous message-based communication services, remote procedure calls, event broadcast, etc. Minor
tasks may communicate by rendezvous or shared memory. Major tasks shall not make assumptions about
their collocation in the same process or processing node.
Flow of messages, process loads can be estimated based on the process blueprint. It is also possible to
implement a “hollow” process architecture with dummy loads for the processes, and measure its
performance on the target system, as described by Filarey et al. in their Eurocontrol experiment.
Notation for the Process view
The notation we use for the process view is expanded from the notation originally proposed by Booch for
Ada tasking. Again the notation used focuses on the elements that are architecturally significant. (Fig. 4)
Message
Remote Procedure Call
Message, bidirectional
Event broadcast
Periodic process
adornment
Process
Unspecified
Components Connectors
Simplified
Process
(Indicates a cyclical process)
Figure 4 — Notation for the Process blueprint
We have used the Universal Network Architecture Services (UNAS) product from TRW to architect and
implement the set of processes and tasks (and their redundancies) into networks of processes. UNAS
contains a tool—the Software Architects Lifecycle Environment (SALE)—which supports such a notation.
SALE allows for the graphical depiction of the process architecture, including specifications of the possible
inter-task communication paths, from which the corresponding Ada or C++ source code is automatically
generated. The benefit of this approach to specifying and implementing the process architecture is that
changes can be incorporated easily without much impact on the application software.
Style for the process view
Several styles would fit the process view. For example, picking from Garlan and Shaw’s taxonomy1 we can
have: pipes and filters, or client/server, with variants of multiple client/single server and multiple
clients/multiple servers. For more complex systems, one could use a style similar to the process groups
approach of the ISIS system as described by K. Birman with another notation and toolset.
6
Example of a Process blueprint
Controller task
Low rate
Controller task
High rate
Main
controller
task
Controller
process
Terminal
process
Figure 5 — Process blueprint for the Télic PABX (partial)
All terminals are handled by a single terminal process, which is driven by messages in its input queues. The
controller objects are executed on one of three tasks that composes the controller process: a low cycle rate
task scans all inactive terminals (200 ms), puts any terminal becoming active in the scan list of the high
cycle rate task (10ms), which detects any significant change of state, and passes them to the main controller
task which interprets the changes and communicates them by message to the corresponding terminal. Here
message passing within the controller process is done via shared memory.
The Development Architecture
Subsystem decomposition
The development architecture focuses on the actual software module organization on the software
development environment. The software is packaged in small chunks—program libraries, or subsystems—
that can be developed by one or a small number of developers. The subsystems are organized in a hierarchy
of layers, each layer providing a narrow and well-defined interface to the layers above it.
The development architecture of the system is represented by module and subsystem diagrams, showing the
‘export’ and ‘import’ relationships. The complete development architecture can only be described when all
the elements of the software have been identified. It is, however, possible to list the rules that govern the
development architecture: partitioning, grouping, visibility.
For the most part, the development architecture takes into account internal requirements related to the ease
of development, software management, reuse or commonality, and to the constraints imposed by the toolset,
or the programming language. The development view serves as the basis for requirement allocation, for
allocation of work to teams (or even for team organization), for cost evaluation and planning, for
monitoring the progress of the project, for reasoning about software reuse, portability and security. It is the
basis for establishing a line-of-product.
Notation for the Development Blueprint
Again, a variation of the Booch notation, limiting it to the items that are architecturally significant.
7
Reference
Compilation dependency
(include, "with")
Module
Subsystem
Components Connectors
Layer
Figure 5 — Notation for the Development blueprint
The Apex Development Environment from Rational supports the definition and the implementation of the
development architecture, the layering strategy described above, and the enforcement of the design rules.
Rational Rose can draw the development blueprints at the module and subsystem level, in forward
engineering and by reverse engineering from the development source code, for Ada and C++.
Style for the Development View
We recommend adopting a layered style for the development view, defining some 4 to 6 layers of
subsystems. Each layer has a well-defined responsibility. The design rule is that a subsystem in a certain can
only depend on subsystem that are in the same layer or in layers below, in order to minimize the
development of very complex networks of dependencies between modules and allow simple release
strategies layer by layer.
Common utilities Bindings
Low-level services
Support Mechanisms:
Communication, Time, Storage,
Resource management, etc.
Aeronautical classes
ATC classes
ATC Functional areas: Flight management,
Sector Management, etc.
Man-Machine Interface
External systems
Off-line tools
Test harnesses
HardWare, OS, COTS
Basic elements
Distributed Virtual Machine
ATC Framework
HATS Components
CAATS, MAATS, etc... 5
1
2
3
4
Figure 6 — The 5 layers of Hughes Air Traffic Systems (HATS)
Example of Development architecture
Figure 6 represents the development organization in five layers of a line-of-product of Air Traffic Control
systems developed by Hughes Aircraft of Canada3. This is the development architecture corresponding to
the logical architecture shown in fig. 3b.
Layers 1 and 2 constitute a domain-independent distributed infrastructure that is common across the line of
products and shields it from variations in hardware platform, operating system, or off-the-shelf products
8
such as database management system. To this infrastructure, layer 3 adds an ATC framework to form a
domain-specific software architecture. Using this framework a palette of functionality is build in layer 4.
Layer 5 is very customer- and product-dependent, and contains most of the user-interface and interfaces
with the external systems. Some 72 subsystems are spread across of the 5 layers, containing each from 10 to
50 modules, and can be represented on additional blueprints.
The Physical Architecture
Mapping the software to the hardware
The physical architecture takes into account primarily the non-functional requirements of the system such as
availability, reliability (fault-tolerance), performance (throughput), and scalability. The software executes
on a network of computers, or processing nodes (or just nodes for short). The various elements identified—
networks, processes, tasks, and objects—need to be mapped onto the various nodes. We expect that several
different physical configurations will be used: some for development and testing, others for the deployment
of the system for various sites or for different customers. The mapping of the software to the nodes
therefore needs to be highly flexible and have a minimal impact on the source code itself.
Notation for the Physical Blueprint
Physical blueprints can become very messy in large systems, so they take several forms, with or without the
mapping from the process view.
Processor
Communication line
Communication
(non permanent)
Uni-directional communication
High bandwidth communication,
Bus
Other device
Components Connectors
Figure 7 — Notation for the Physical blueprint
UNAS from TRW provide us here with data-driven means of mapping the process architecture onto the
physical architecture allowing a large class of changes in the mapping without source code modifications.
Example of Physical blueprint
K K K K
F
Primary
F
backup
K K K K
F
Primary
F
backup
C
primary
C
backup
Figure 8 — Physical blueprint for the PABX
Figure 8 shows one possible hardware configuration for a large PABX, whereas figures 9 and 10 show
mappings of the process architecture on two different physical architectures, corresponding to a small and a
large PABX. C, F and K are three types of computers of different capacity, supporting three different
executables.
Controller
Process
Terminal
Process
Conversation
process
F
K
Figure 9 — A small PABX physical architecture with process allocation
9
Controller
Process
Terminal
Process
Conversation
process
Pseudo Central
process
F
Controller
Process
Terminal
Process
Conversation
process
Pseudo Central
process
F
Central
Process
C
K K
line cards line cards
Controller
Process
K
line cards
Back-up nodes
more K
processors
Figure 10 — Physical blueprint for a larger PABX showing process allocation
Scenarios
Putting it all together
The elements in the four views are shown to work together seamlessly by the use of a small set of important
scenarios —instances of more general use cases—for which we describe the corresponding scripts
(sequences of interactions between objects, and between processes) as described by Rubin and Goldberg6.
The scenarios are in some sense an abstraction of the most important requirements. Their design is
expressed using object scenario diagrams and object interaction diagrams4.
This view is redundant with the other ones (hence the “+1”), but it serves two main purposes:
• as a driver to discover the architectural elements during the architecture design as we will describe later
• as a validation and illustration role after this architecture design is complete, both on paper and as the
starting point for the tests of an architectural prototype.
Notation for the Scenarios
The notation is very similar to the Logical view for the components (cf. fig. 2), but uses the connectors of
the Process view for interactions between objects (cf. fig. 4). Note that object instances are denoted with
solid lines. As for the logical blueprint, we capture and manage object scenario diagrams using Rational
Rose.
Example of a Scenario
Fig. 11 shows a fragment of a scenario for the small PABX. The corresponding script reads:
1. The controller of Joe’s phone detects and validate the transition from on-hook to off-hook and sends a
message to wake up the corresponding terminal object.
2. The terminal allocates some resources, and tells the controller to emit some dial-tone.
3. The controller receives digits and transmits them to the terminal.
4. The terminal uses the numbering plan to analyze the digit flow.
5. When a valid sequence of digits has been entered, the terminal opens a conversation.
10
Joe:Controller Joe:Terminal Numbering plan
(1) Off-Hook
(2) dial tone
(3) digit
(4) digit
(5) open
conversation
:Conversation
Figure 11 — Embryo of a scenario for a local call—selection phase
Correspondence Between the Views
The various views are not fully orthogonal or independent. Elements of one view are connected to elements
in other views, following certain design rules and heuristics.
From the logical to the process view
We identify several important characteristics of the classes of the logical architecture:
• Autonomy: are the objects active, passive, protected?
-an active object takes the initiative of invoking other objects’ operations or its own operations, and has
full control over the invocation of its own operations by other objects
-a passive object never invokes spontaneously any operations and has no control over the invocation of
its own operations by other objects
- a protected object never invokes spontaneously any operations but performs some arbitration on the
invocation of its operations.
• Persistence: are the objects transient , permanent? Do they the failure of a process or processor?
• Subordination: are the existence or persistence of an object depending on another object?
• Distribution: are the state or the operations of an object accessible from many nodes in the physical
architecture, from several processes in the process architecture?
In the logical view of the architecture we consider each object as active, and potentially “concurrent,” i.e.,
behaving “in parallel” with other objects, and we pay no more attention to the exact degree of concurrency
we need to achieve this effect. Hence the logical architecture takes into account only the functional aspect
of the requirements.
However when we come to defining the process architecture, implementing each object with its own thread
of control (e.g., its own Unix process or Ada task) is not quite practical in the current state of technology,
because of the huge overhead this imposes. Moreover, if objects are concurrent, there must be some form of
arbitration for invoking their operations.
On another hand, multiple threads of control are needed for several reasons:
• To react rapidly to certain classes of external stimuli, including time-related events
• To take advantage of multiple CPUs in a node, or multiple nodes in a distributed system
• To increase the CPU utilization, by allocating the CPU to other activities while some thread of control
is suspended waiting for some other activity to complete (e.g., access to some external device, or access
to some other active object)
• To prioritize activities (and potentially improve responsiveness)
• To support system scalability (with additional processes sharing the load)
• To separate concerns between different areas of the software
• To achieve a higher system availability (with backup processes)
We use concurrently two strategies to determine the ‘right’ amount of concurrency and define the set of
processes that are needed. Keeping in mind the set of potential physical target architectures, we can proceed
either:
• Inside-out:
Starting from the logical architecture: define agent tasks which multiplex a single thread of control
11
across multiple active objects of a class; objects whose persistency or life is subordinate to an active
object are also executed on that same agent; several classes that need to be executed in mutual
exclusion, or that require only small amount of processing share a single agent. This clustering
proceeds until we have reduced the processes to a reasonably small number that still allows distribution
and use of the physical resources.
• Outside-in:
Starting with the physical architecture: identify external stimuli (requests) to the system, define client
processes to handle the stimuli and servers processes that only provide services and do not initiate
them; use the data integrity and serialization constraints of the problem to define the right set of
servers, and allocate objects to the client and servers agents; identify which objects must be distributed.
The result is a mapping of classes (and their objects) onto a set of tasks and processes of the process
architecture. Typically, there is an agent task for an active class, with some variations: several agents for a
given class to increase throughput, or several classes mapped onto a single agent because their operations
are infrequently invoked or to guarantee sequential execution.
Note that this is not a linear, deterministic process leading to an optimal process architecture; its requires a
few iterations to get an acceptable compromise. There are numerous other ways to proceed, as shown by
Birman et al.5 or Witt et al.7 for example. The precise method used to construct the mapping is outside of
the scope of this article, but we can illustrate it on a small example.
Fig. 12 shows how a small set of classes from some hypothetical air-traffic control system maybe mapped
onto processes.
The flight class is mapped onto a set of flight agents: there are many flights to process, a high rate of
external stimuli, response time is critical, the load must be spread across multiple CPUs. Moreover the
persistency and distribution aspects of the flight processing are deferred to a flight server, which is
duplicated for availability reasons.
A flight profile or a clearance are always subordinate to a flight, and although there are complex classes,
they share the processes of the flight class. Flights are distributed to several other processes, notably for to
display and external interfaces.
A sectorization class, which established a partitioning of airspace for the assignment of jurisdiction of
controllers over flights, because of its integrity constraints, can be handled only by a single agent, but can
share the server process with the flight: updates are infrequent.
Locations and airspace and other static aeronautical information are protected objects, shared among
several classes, rarely updated; they are mapped on their own server, and distributed to other processes.
12
flight
clearance profile
sectorization
location airspace
flight
profile
clearance
sectorization
location
airspace
multiple flight agents flight server
Single sectorization agent
aeronautical info
server
backup
Backup
Figure 12: Mapping from Logical to Process view
From logical to development
A class is usually implemented as a module, for example a type in the visible part of an Ada package. Large
classes are decomposed into multiple packages. Collections of closely related classes—class categories—
are grouped into subsystems. Additional constraints must be considered for the definition of subsystems,
such as team organization, expected magnitude of code (typically 5K to 20K SLOC per subsystem), degree
of expected reuse and commonality, and strict layering principles (visibility issues), release policy and
configuration management. Therefore we usually end up with a view that does not have a one to one
correspondence with the logical view.
The logical and development views are very close, but address very different concerns. We have found that
the larger the project, the greater the distance between these views. Similarly for the process and physical
views: the larger the project, the greater the distance between the views. For example, if we compare fig. 3b
and fig. 6, there is no one to one mapping of the class categories to the layers. If we take the ‘External
interfaces—Gateway’ category, its implementation is spread across several layers: communications
protocols are in subsystems in or below layer 1, general gateway mechanisms are in subsystems in layer 2,
and the actual specific gateways in layer 5 subsystems.
From process to physical
Processes and process groups are mapped onto the available physical hardware, in various configurations
for testing or deployment. Birman describes some very elaborate schemes for this mapping in the Isis
project5.
The scenarios relate mostly to the logical view, in terms of which classes are used, and to the process view
when the interactions between objects involve more than one thread of control.
13
Tailoring the Model
Not all software architecture need the full “4+1” views. Views that are useless can be omitted from the
architecture description, such as the physical view, if there is only one processor, and the process view if
there is only process or program. For very small system, it is even possible that the logical view and the
development view are so similar that they do not require separate descriptions. The scenarios are useful in
all circumstances.
Iterative process
Witt et al. indicate 4 phases for the design or an architecture: sketching, organizing, specifying and
optimizing, subdivided into some 12 steps7. They indicate that some backtracking may be needed. We think
that this approach is too “linear” for an ambitious and rather unprecedented project. Too little is known at
the end of the 4 phases to validate the architecture. We advocate a more iterative development, were the
architecture is actually prototyped, tested, measured, analyzed, and then refined in subsequent iterations.
Besides allowing to mitigate the risks associated with the architecture, such an approach has other side
benefits for the project: team building, training, acquaintance with the architecture, acquisition of tools, runin
of procedures and tools, etc. (We are speaking here of an evolutionary prototype, that slowly grows into
becoming the system, and not of throw-away, exploratory prototypes.) This iterative approach also allows
the requirements to be refined, matured, better understood.
A scenario-driven approach
The most critical functionality of the system is captured in the form of scenarios (or use cases). By critical
we mean: functions that are the most important, the raison d’être of the system, or that have the highest
frequency of use, or that present some significant technical risk that must be mitigated.
Start:
• A small number of the scenarios are chosen for an iteration based on risk and criticality. Scenarios
may be synthesized to abstract a number of user requirements.
• A strawman architecture is put in place. The scenarios are then “scripted” in order to identify major
abstractions (classes, mechanisms, processes, subsystems) as indicated by Rubin and Goldberg6 —
decomposed in sequences of pairs (object, operation).
• The architectural elements discovered are laid out on the 4 blueprints: logical, process, development,
and physical.
• This architecture is then implemented, tested, measured, and this analysis may detect some flaws or
potential enhancement.
• Lessons learned are captured.
Loop:
The next iteration can then start by:
• reassessing the risks,
• extending the palette of scenarios to consider
• selecting a few additional scenarios that will allow risk mitigation or greater architecture
coverage
Then:
• Try to script those scenarios in the preliminary architecture
• discover additional architectural elements, or sometimes significant architectural changes that
need to occur to accommodate these scenarios
• update the 4 main blueprints: logical, process, development, physical
• revise the existing scenarios based on the changes
• upgrade the implementation (the architectural prototype) to support the new extended set of
scenario.
• Test. Measure under load, in real target environment if possible.
• All five blueprints are then reviewed to detect potential for simplification, reuse, commonality.
• Design guidelines and rationale are updated.
• Capture the lessons learned.
End loop
The initial architectural prototype evolves to become the real system. Hopefully after 2 or 3 iterations, the
architecture itself become stable: no new major abstractions are found, no new subsystems or processes, no
14
new interfaces. The rest of the story is in the realm of software design, where, by the way, development may
continue using very similar methods and process.
The duration of these iterations varies considerably: with the size of the project to put in place, with the
number of people involved and their familiarity with the domain and with the method, and with the degree
of “unprecedentedness” of the system w.r.t. this development organization. Hence the duration of an
iteration may be 2-3 weeks for a small project (e.g., 10 KSLOC), or up to 6-9 months for a large command
and control system (e.g., 700 KSLOC).
Documenting the architecture
The documentation produced during the architectural design is captured in two documents:
• A Software Architecture Document, whose organization follows closely the “4+1” views (cf. fig. 13 for
a typical outline)
• A Software Design Guidelines, which captures (among other things) the most important design
decisions that must be respected to maintain the architectural integrity of the system.
Title Page
Change History
Table of Contents
List of Figures
1. Scope
2. References
3. Software Architecture
4. Architectural Goals & Constraints
5. Logical Architecture
6. Process Architecture
7. Development Architecture
8. Physical Architecture
9. Scenarios
10. Size and Performance
11. Quality
Appendices
A. Acronyms and Abbreviations
B. Definitions
C. Design Principles
Figure 13 — Outline of a Software Architecture Document
Conclusion
This “4+1” view model has been used with success on several large projects with or without some local
customization and adjustment in terminology4. It actually allowed the various stakeholders to find what they
want to know about the software architecture. Systems engineers approach it from the Physical view, then
the Process view. End-users, customers, data specialists from the Logical view. Project managers, software
configuration staff see it from the Development view.
Other sets of views have been proposed and discussed, within Rational and elsewhere, for instance by
Meszaros (BNR), Hofmeister, Nord and Soni (Siemens), Emery and Hilliard (Mitre)8, but we have found
that often these other views proposed could usually be folded into one of the 4 we described. For example a
Cost & Schedule view folds into the Development view, a Data view into the Logical view, an Execution
view into a combination of the Process and Physical view.
View Logical Process Development Physical Scenarios
Components Class Task Module,
Subsystem
Node Step,
Scripts
Connectors association,
inheritance,
containment
Rendez-vous,
Message,
broadcast,
RPC, etc.
compilation
dependency,
“with” clause,
“include”
Communication
medium,
LAN, WAN,
bus, etc.
Containers Class category Process Subsystem
(library)
Physical
subsystem
Web
15
Stakeholders End-user System
designer,
integrator
Developer,
manager
System
designer
End-user,
developer
Concerns Functionality Performance,
availability,
S/W faulttolerance,
integrity
Organization,
reuse,
portability, lineof-
product
Scalability,
performance,av
ailability
Understandability
Tool support Rose UNAS/SALE
DADS
Apex, SoDA UNAS,
Openview
DADS
Rose
Table 1 — Summary of the “4+1” view model
Acknowledgments
The “4+1” view model owes its existence to many colleagues at Rational, at Hughes Aircraft of Canada, at
Alcatel, and elsewhere. In particular I would like to thank for their contributions Ch. Thompson, A. Bell, M.
Devlin, G. Booch, W. Royce, J. Marasco, R. Reitman, V. Ohnjec, and E. Schonberg.
References
1. D. Garlan & M. Shaw, “An Introduction to Software Architecture,” Advances in Software
Engineering and Knowledge Engineering, Vol. 1, World Scientific Publishing Co. (1993).
2. D. E. Perry & A. L. Wolf, “Foundations for the Study of Software Architecture,” ACM Software
Engineering Notes, 17, 4, October 1992, 40-52.
3. Ph. Kruchten & Ch. Thompson, “An Object-Oriented, Distributed Architecture for Large Scale Ada
Systems,” Proceedings of the TRI-Ada ’94 Conference, Baltimore, November 6-11, 1994, ACM,
p.262-271.
4. G. Booch: Object-Oriented Analysis and Design with Applications, 2nd. edition, Benjamin-Cummings
Pub. Co., Redwood City, California, 1993, 589p.
5. K. P. Birman, and R. Van Renesse, Reliable Distributed Computing with the Isis Toolkit, IEEE
Computer Society Press, Los Alamitos CA, 1994.
6. K. Rubin & A. Goldberg, “Object Behavior Analysis,” CACM, 35, 9 (Sept. 1992) 48-62
7. B. I. Witt, F. T. Baker and E. W. Merritt, Software Architecture and Design—Principles, Models, and
Methods, Van Nostrand Reinhold, New-York (1994) 324p.
8. D. Garlan (ed.), Proceedings of the First Internal Workshop on Architectures for Software Systems,
CMU-CS-TR-95-151, CMU, Pittsburgh, 1995.