http://www.tutorialspoint.com/software_architecture_design/quick_guide.htm Copyright © tutorialspoint.com

QUICK GUIDEQUICK GUIDE

SOFTWARE ARCHITECTURE & DESIGN INTRODUCTIONSOFTWARE ARCHITECTURE & DESIGN INTRODUCTIONThe architecture of a system describes its major components, their relationships structures, and howthey interact with each other. Software architecture and design includes several contributoryfactors such as Business strategy, quality attributes, human dynamics, design, and IT environment.

We can segregate Software Architecture and Design into two distinct phases: SoftwareArchitecture and Software Design. In Architecture, nonfunctional decisions are cast andseparated by the functional requirements. In Design, functional requirements are accomplished.

Software ArchitectureArchitecture serves as a blueprint for a system. It provides an abstraction to manage the systemcomplexity and establish a communication and coordination mechanism among components. Itdefines a structured solution to meet all the technical and operational requirements, whileoptimizing the common quality attributes like performance and security.

Further, it involves a set of significant decisions about the organization related to softwaredevelopment and each of these decisions can have a considerable impact on quality,maintainability, performance, and the overall success of the final product. These decisionscomprise of −

Selection of structural elements and their interfaces by which the system is composed.

Behavior as specified in collaborations among those elements.

Composition of these structural and behavioral elements into large subsystem.

Architectural decisions align with business objectives.

Architectural styles guide the organization.

Software DesignSoftware design provides a design plan that describes the elements of a system, how they fit, andwork together to fulfill the requirement of the system. The objectives of having a design plan areas follows −

To negotiate system requirements, and to set expectations with customers, marketing, andmanagement personnel.

Act as a blueprint during the development process.

Guide the implementation tasks, including detailed design, coding, integration, and testing.

Domain analysis, requirements analysis, and risk analysis comes before architecture designphase, whereas the detailed design, coding, integration, and testing phases come after it.

Goals of ArchitectureThe primary goal of the architecture is to identify requirements that affect the structure of theapplication. A well-laid architecture reduces the business risks associated with building a technicalsolution and builds a bridge between business and technical requirements.

Some of the other goals are as follows −

Expose the structure of the system, but hide its implementation details.

Realize all the use-cases and scenarios.

Try to address the requirements of various stakeholders.

Handle both functional and quality requirements.

Reduce the goal of ownership and improve the organization’s market position.

Improve quality and functionality offered by the system.

Improve external confidence in either the organization or system.

LimitationsSoftware architecture is still an emerging discipline within software engineering. It has thefollowing limitations −

Lack of tools and standardized ways to represent architecture.

Lack of analysis methods to predict whether architecture will result in an implementationthat meets the requirements.

Lack of awareness of the importance of architectural design to software development.

Lack of understanding of the role of software architect and poor communication amongstakeholders.

Lack of understanding of the design process, design experience and evaluation of design.

Role of Software Architect

A Software Architect provides a solution that the technical team can create and design for theentire application. A software architect should have expertise in the following areas −

Design ExpertiseExpert in software design, including diverse methods and approaches such as object-oriented design, event-driven design, etc.

Lead the development team and coordinate the development efforts for the integrity of thedesign.

Should be able to review design proposals and tradeoff among themselves.

Domain ExpertiseExpert on the system being developed and plan for software evolution.

Assist in the requirement investigation process, assuring completeness and consistency.

Coordinate the definition of domain model for the system being developed.

Technology ExpertiseExpert on available technologies that helps in the implementation of the system.

Coordinate the selection of programming language, framework, platforms, databases, etc.

Methodological ExpertiseExpert on software development methodologies that may be adopted during SDLC SoftwareDevelopmentLifeCycle.

Choose the appropriate approaches for development that helps the entire team.

Deliverables of the ArchitectAn architect is expected to deliver clear, complete, consistent, and achievable set of functionalgoals to the organization. Besides, he is also responsible to provide −

A simplified concept of the system

A design in the form of the system, with at least two layers of decomposition.

A functional description of the system, with at least two layers of decomposition.

A notion of the timing, operator attributes, and the implementation and operation plans

A document or process which ensures functional decomposition is followed, and the form ofinterfaces is controlled

Hidden Role of Software ArchitectBesides, facilitating the technical work among team members, it has also some subtle roles suchas reinforce the trust relationship among team members and protect team members from theexternal forces that could distract them and bring less value to the project.

Quality AttributesQuality is a measure of excellence or the state of being free from deficiencies or defects. Qualityattributes are the system properties that are separate from the functionality of the system.

Implementing quality attributes makes it easier to differentiate a good system from a bad one.Attributes are overall factors that affect runtime behavior, system design, and user experience.

They can be classified as −

Static Quality Attributes − Reflect the structure of a system and organization, directlyrelated to architecture, design, and source code. They are invisible to end-user, but affectthe development and maintenance cost, e.g.: modularity, testability, maintainability, etc.

Dynamic Quality Attributes − Reflect the behavior of the system during its execution.They are directly related to system’s architecture, design, source code, configuration,deployment parameters, environment, and platform. They are visible to the end-user andexist at runtime, e.g. throughput, robustness, scalability, etc.

Quality ScenariosQuality scenarios specify how to prevent a fault from becoming a failure. They can be divided intosix parts based on their attribute specifications −

Source − An internal or external entity such as people, hardware, software, or physicalinfrastructure that generate the stimulus.

Stimulus − A condition that needs to be considered when it arrives on a system.

Environment − The stimulus occurs within certain conditions.

Artifact − A whole system or some part of it such as processors, communication channels,persistent storage, processes etc.

Response − An activity undertaken after the arrival of stimulus such as detect faults,recover from fault, disable event source etc.

Response measure − Should measure the occurred responses so that the requirementscan be tested.

Common Quality AttributesThe following table lists the common quality attributes a software architecture must have −

Category Quality Attribute Description

Design Qualities

Conceptual Integrity Defines the consistency andcoherence of the overall design. Thisincludes the way components ormodules are designed.

Maintainability Ability of the system to undergochanges with a degree of ease.

Reusability Defines the capability for componentsand subsystems to be suitable for usein other applications.

Interoperability Ability of a system or different systemsto operate successfully bycommunicating and exchanginginformation with other externalsystems written and run by externalparties.

Manageability Defines how easy it is for systemadministrators to manage theapplication.

Reliability Ability of a system to remainoperational over time.

Scalability Ability of a system to either handle the

Run-time Qualities load increase without impacting theperformance of the system or theability to be readily enlarged.

Security Capability of a system to preventmalicious or accidental actions outsideof the designed usages.

Performance Indication of the responsiveness of asystem to execute any action within agiven time interval.

Availability Defines the proportion of time that thesystem is functional and working. It canbe measured as a percentage of thetotal system downtime over apredefined period.

System Qualities

Supportability Ability of the system to provideinformation helpful for identifying andresolving issues when it fails to workcorrectly.

Testability Measure of how easy it is to create testcriteria for the system and itscomponents.

User Qualities Usability Defines how well the application meetsthe requirements of the user andconsumer by being intuitive.

Architecture Quality Correctness Accountability for satisfying all therequirements of the system.

Non-runtime Quality

Portability Ability of the system to run underdifferent computing environment.

Integrality Ability to make separately developedcomponents of the system workcorrectly together.

Modifiability Ease with which each software systemcan accommodate changes to itssoftware.

Business quality attributes Cost and schedule Cost of the system with respect to timeto market, expected project lifetime &utilization of legacy.

Marketability Use of system with respect to marketcompetition.

KEY PRINCIPLESKEY PRINCIPLESSoftware architecture is described as the organization of a system, where the system represents aset of components that accomplish the defined functions.

Architectural StyleThe architectural style, also called as architectural pattern, is a set of principles which shapesan application. It defines an abstract framework for a family of system in terms of the pattern ofstructural organization.

The architectural style is responsible to −

Provide a lexicon of components and connectors with rules on how they can be combined.

Improve partitioning and allow the reuse of design by giving solutions to frequently occurringproblems.

Describe a particular way to configure a collection of components amodulewithwell − definedinterfaces, reusable, andreplaceable and connectors communicationlinkbetweenmodules.

The software that is built for computer-based systems exhibit one of many architectural styles.Each style describes a system category that encompasses −

A set of component types which perform a required function by the system.

A set of connectors subroutinecall, remoteprocedurecall, datastream, andsocket that enablecommunication, coordination, and cooperation among different components.

Semantic constraints which define how components can be integrated to form the system.

A topological layout of the components indicating their runtime interrelationships.

Common Architectural DesignThe following table lists architectural styles that can be organized by their key focus area −

Category Architectural Design Description

Communication

Message bus Prescribes use of a software system that canreceive and send messages using one ormore communication channels.

Service–OrientedArchitecture SOA

Defines the applications that expose andconsume functionality as a service usingcontracts and messages.

Deployment

Client/server Separate the system into two applications,where the client makes requests to the server.

3-tier or N-tier Separates the functionality into separatesegments with each segment being a tierlocated on a physically separate computer.

Domain Domain Driven Design Focused on modeling a business domain anddefining business objects based on entitieswithin the business domain.

Structure

Component Based Breakdown the application design intoreusable functional or logical componentsthat expose well-defined communicationinterfaces.

Layered Divide the concerns of the application intostacked groups layers.

Object oriented Based on the division of responsibilities of anapplication or system into objects, eachcontaining the data and the behavior relevantto the object.

Types of ArchitectureThere are four types of architecture from the viewpoint of an enterprise and collectively, thesearchitectures are referred to as enterprise architecture.

Business architecture − Defines the strategy of business, governance, organization, andkey business processes within an enterprise and focuses on the analysis and design ofbusiness processes.

Application software architecture − Serves as the blueprint for individual applicationsystems, their interactions, and their relationships to the business processes of theorganization.

Information architecture − Defines the logical and physical data assets and datamanagement resources.

Information technology IT architecture − Defines the hardware and software buildingblocks that make up the overall information system of the organization.

Architecture Design ProcessThe architecture design process focuses on the decomposition of a system into differentcomponents and their interactions to satisfy functional and nonfunctional requirements. The keyinputs to software architecture design are −

The requirements produced by the analysis tasks.

The hardware architecture thesoftwarearchitectinturnprovidesrequirementstothesystemarchitect, whoconfiguresthehardwarearchitecture.

The result or output of the architecture design process is an architectural description. The basicarchitecture design process is composed of the following steps −

Understand the ProblemThis is the most crucial step because it affects the quality of the design that follows. Without a clearunderstanding of the problem, it is not possible to create an effective solution. In fact, manysoftware projects and products are considered as unsuccessful because they did not actually solvea valid business problem or have a recognizable return on investment ROI.

Identify Design Elements and their RelationshipsIn this phase, build a baseline for defining the boundaries and context of the system.Decomposition of the system into its main components is based on the functional requirements.The decomposition can be modeled by using a design structure matrix DSM, which shows thedependencies between design elements without specifying the granularity of the elements.

In this step, the first validation of the architecture is done by describing a number of systeminstances and this step is referred as functionality based architectural design.

Evaluate the Architecture DesignEach quality attribute is given an estimate, so in order to gather qualitative measures orquantitative data, the design is evaluated. It involves evaluating the architecture for conformanceto architectural quality attributes requirements.

If all the estimated quality attributes are as per the required standard, the architectural designprocess is finished. If not, then the third phase of software architecture design is entered:architecture transformation. However, if the observed quality attribute does not meet itsrequirements, then a new design must be created.

Transform the Architecture DesignThis step is performed after an evaluation of the architectural design. The architectural designmust be changed until it completely satisfies the quality attribute requirements. It is concernedwith selecting design solutions to improve the quality attributes while preserving the domainfunctionality.

Further, a design is transformed by applying design operators, styles, or patterns. Fortransformation, take the existing design and apply design operator such as decomposition,replication, compression, abstraction, and resource sharing.

Moreover, the design is again evaluated and the same process is repeated multiple times ifnecessary and even performed recursively. The transformations i. e. qualityattributeoptimizingsolutionsgenerally improve one or some quality attributes while they affect others negatively.

Key Architecture PrinciplesFollowing are the key principles to be considered while designing an architecture −

Build to Change Instead of Building to LastConsider how the application may need to change over time to address new requirements andchallenges, and build in the flexibility to support this.

Reduce Risk and Model to AnalyzeUse design tools, visualizations, modeling systems such as UML to capture requirements anddesign decisions. The impacts can also be analyzed. Do not formalize the model to the extent thatit suppresses the capability to iterate and adapt the design easily.

Use Models and Visualizations as a Communication and CollaborationToolEfficient communication of the design, the decisions, and ongoing changes to the design is criticalto good architecture. Use models, views, and other visualizations of the architecture tocommunicate and share the design efficiently with all the stakeholders. This enables rapidcommunication of changes to the design.

Identify and understand key engineering decisions and areas where mistakes are most oftenmade. Invest in getting key decisions right the first time to make the design more flexible and lesslikely to be broken by changes.

Use an Incremental and Iterative ApproachStart with baseline architecture and then evolve candidate architectures by iterative testing toimprove the architecture. Iteratively add details to the design over multiple passes to get the big orright picture and then focus on the details.

Key Design Principles

Following are the design principles to be considered for minimizing cost, maintenancerequirements, and maximizing extendibility, usability of architecture −

Separation of ConcernsDivide the components of system into specific features so that there is no overlapping among thecomponents functionality. This will provide high cohesion and low coupling. This approach avoidsthe interdependency among components of system which helps in maintaining the system easy.

Single Responsibility PrincipleEach and every module of a system should have one specific responsibility, which helps the user toclearly understand the system. It should also help with integration of the component with othercomponents.

Principle of Least KnowledgeAny component or object should not have the knowledge about internal details of othercomponents. This approach avoids interdependency and helps maintainability.

Minimize Large Design UpfrontMinimize large design upfront if the requirements of an application are unclear. If there is apossibility of modifying requirements, then avoid making a large design for whole system.

Do not Repeat the FunctionalityIt specifies that functionality of the components should not to be repeated and hence a piece ofcode should be implemented in one component only. Duplication of functionality within a singleapplication can make it difficult to implement changes, decrease clarity, and introduce potentialinconsistencies.

Prefer Composition over Inheritance while Reusing the FunctionalityInheritance creates dependency between children and parent classes and hence it blocks the freeuse of the child classes. In contrast, the composition provides a great level of freedom and reducesthe inheritance hierarchies.

Identify Components and Group them in Logical LayersIdentity components and the area of concern that are needed in system to satisfy therequirements. Then group these related components in a logical layer, which will help the user tounderstand the structure of the system at a high level. Avoid mixing components of different typeof concerns in same layer.

Define the Communication Protocol between LayersUnderstand how components will communicate with each other which requires a completeknowledge of deployment scenarios and the production environment.

Define Data Format for a LayerVarious components will interact with each other through data format. Do not mix the data formatsso that applications are easy to implement, extend, and maintain. Try to keep data format samefor a layer, so that various components need not code/decode the data while communicating witheach other. It reduces a processing overhead.

System Service Components should be AbstractCode related to security, communications, or system services like logging, profiling, andconfiguration should be abstracted in the separate components. Do not mix this code withbusiness logic, as it is easy to extend design and maintain it.

Design Exceptions and Exception Handling MechanismDefining exceptions in advance, helps the components to manage errors or unwanted situation inan elegant manner. The exception management will be same throughout the system.

Naming ConventionsNaming conventions should be defined in advance. They provide a consistent model that helps theusers to understand the system easily. It is easier for team members to validate code written byothers, and hence will increase the maintainability.

ARCHITECTURE MODELSARCHITECTURE MODELSSoftware architecture involves the high level structure of software system abstraction, by usingdecomposition and composition, with architectural style and quality attributes. A softwarearchitecture design must conform to the major functionality and performance requirements of thesystem, as well as satisfy the non-functional requirements such as reliability, scalability, portability,and availability.

A software architecture must describe its group of components, their connections, interactionsamong them and deployment configuration of all components.

A software architecture can be defined in many ways −

UML UnifiedModelingLanguage − UML is one of object-oriented solutions used in softwaremodeling and design.

Architecture View Model 4 + 1viewmodel − Architecture view model represents thefunctional and non-functional requirements of software application.

ADL ArchitectureDescriptionLanguage − ADL defines the software architecture formally andsemantically.

UMLUML stands for Unified Modeling Language. It is a pictorial language used to make softwareblueprints. UML was created by Object Management Group OMG. The UML 1.0 specification draftwas proposed to the OMG in January 1997. It serves as a standard for software requirementanalysis and design documents which are the basis for developing a software.

UML can be described as a general purpose visual modeling language to visualize, specify,construct, and document a software system. Although UML is generally used to model softwaresystem, it is not limited within this boundary. It is also used to model non software systems such asprocess flows in a manufacturing unit.

The elements are like components which can be associated in different ways to make a completeUML picture, which is known as a diagram. So, it is very important to understand the differentdiagrams to implement the knowledge in real-life systems. We have two broad categories ofdiagrams and they are further divided into sub-categories i.e. Structural Diagrams andBehavioral Diagrams.

Structural DiagramsStructural diagrams represent the static aspects of a system. These static aspects represent thoseparts of a diagram which forms the main structure and is therefore stable. These static parts arerepresented by classes, interfaces, objects, components and nodes.

The structural diagrams are sub-divided as showninthefollowingimage −

The following table provides a brief description of these diagrams −

Diagram Description

Class Represents the object orientation of a system. Shows how classesare statically related.

Object Represents a set of objects and their relationships at runtime andalso represent the static view of the system.

Component Describes all the components, their interrelationship, interactionsand interface of the system.

Composite structure Describes inner structure of component including all classes,interfaces of the component, etc.

Package Describes the package structure and organization. Covers classes inthe package and packages within another package.

Deployment Deployment diagrams are a set of nodes and their relationships.These nodes are physical entities where the components aredeployed.

Behavioral DiagramsBehavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspects arebasically the changing/moving parts of a system. UML has the following types of behavioraldiagrams shownintheimagegivenbelow −

The following table provides a brief description of these diagram −

Diagram Description

Use case Describes the relationships among the functionalities and theirinternal/external controllers. These controllers are known asactors.

Activity Describes the flow of control in a system. It consists of activitiesand links. The flow can be sequential, concurrent, or branched.

State Machine/state chart Represents the event driven state change of a system. Itbasically describes the state change of a class, interface, etc.Used to visualize the reaction of a system by internal/externalfactors.

Sequence Visualizes the sequence of calls in a system to perform a specificfunctionality.

Interaction Overview Combines activity and sequence diagrams to provide a controlflow overview of system and business process.

Communication Same as sequence diagram, except that it focuses on theobject’s role. Each communication is associated with a sequenceorder, number plus the past messages.

Time Sequenced Describes the changes by messages in state, condition andevents.

Architecture View ModelA model is a complete, basic, and simplified description of software architecture which iscomposed of multiple views from a particular perspective or viewpoint.

A view is a representation of an entire system from the perspective of a related set of concerns. Itis used to describe the system from the viewpoint of different stakeholders such as end-users,developers, project managers, and testers.

4+1 View ModelThe 4+1 View Model was designed by Philippe Kruchten to describe the architecture of a software–intensive system based on the use of multiple and concurrent views. It is a multiple view modelthat addresses different features and concerns of the system. It standardizes the software designdocuments and makes the design easy to understand by all stakeholders.

It is an architecture verification method for studying and documenting software architecturedesign and covers all the aspects of software architecture for all stakeholders. It provides fouressential views −

The logical view or conceptual view − It describes the object model of the design.

The process view − It describes the activities of the system, captures the concurrency andsynchronization aspects of the design.

The physical view − It describes the mapping of software onto hardware and reflects itsdistributed aspect.

The development view − It describes the static organization or structure of the software inits development of environment.

This view model can be extended by adding one more view called scenario view or use caseview for end-users or customers of software systems. It is coherent with other four views and areutilized to illustrate the architecture serving as “plus one” view, 4 + 1 view model. The followingfigure describes the software architecture using five concurrent views 4 + 1 model.

Why is it called 4+1 instead of 5?The use case view has a special significance as it details the high level requirement of a systemwhile other views details — how those requirements are realized. When all other four views arecompleted, it’s effectively redundant. However, all other views would not be possible without it.The following image and table shows the 4+1 view in detail −

Logical Process Development Physical Scenario

Description Shows thecomponent Object of systemas well as theirinteraction

Shows the processes/ Workflow rules ofsystem and howthose processescommunicate,focuses on dynamicview of system

Gives building block views of systemand describe static organization ofthe system modules

Shows theinstallation,configurationanddeployment ofsoftwareapplication

Shows thedesign iscompletebyperformingvalidationandillustration

Viewer /Stakeholder

End-User,Analysts andDesigner

Integrators &developers

Programmer and software projectmanagers

Systemengineer,operators,systemadministratorsand systeminstallers

All theviews oftheir viewsandevaluators

Consider Functionalrequirements

Non FunctionalRequirements

Software Module organization Softwaremanagementreuse, constraintoftools

Nonfunctionalrequirementregarding tounderlyinghardware

SystemConsistencyand validity

UML –Diagram

Class, State,Object,sequence,CommunicationDiagram

Activity Diagram Component, Package diagram Deploymentdiagram

Use casediagram

Architecture Description Languages ADLs

An ADL is a language that provides syntax and semantics for defining a software architecture. It isa notation specification which provides features for modeling a software system’s conceptualarchitecture, distinguished from the system’s implementation.

ADLs must support the architecture components, their connections, interfaces, and configurationswhich are the building block of architecture description. It is a form of expression for use inarchitecture descriptions and provides the ability to decompose components, combine thecomponents, and define the interfaces of components.

An architecture description language is a formal specification language, which describes thesoftware features such as processes, threads, data, and sub-programs as well as hardwarecomponent such as processors, devices, buses, and memory.

It is hard to classify or differentiate an ADL and a programming language or a modeling language.However, there are following requirements for a language to be classified as an ADL −

It should be appropriate for communicating the architecture to all concerned parties.

It should be suitable for tasks of architecture creation, refinement, and validation.

It should provide a basis for further implementation, so it must be able to add information tothe ADL specification to enable the final system specification to be derived from the ADL.

It should have the ability to represent most of the common architectural styles.

It should support analytical capabilities or provide quick generating prototypeimplementations.

OBJECT-ORIENTED PARADIGMOBJECT-ORIENTED PARADIGMThe object-oriented OO paradigm took its shape from the initial concept of a new programmingapproach, while the interest in design and analysis methods came much later. OO analysis anddesign paradigm is the logical result of the wide adoption of OO programming languages.

Development of OOOO is developed over a period of time as −

The first object–oriented language was Simula Simulationofrealsystems that was developed in1960 by researchers at the Norwegian Computing Center.

In 1970, Alan Kay and his research group at Xerox PARC created a personal computernamed Dynabook and the first pure object-oriented programming language OOPL -Smalltalk, for programming the Dynabook.

In the 1980s, Grady Booch published a paper titled Object Oriented Design that mainlypresented a design for the programming language, Ada. In the ensuing editions, he extendedhis ideas to a complete object–oriented design method.

In the 1990s, Coad incorporated behavioral ideas to object-oriented methods.

The other significant innovations were Object Modeling Techniques OMT by James Rum Baughand Object-Oriented Software Engineering OOSE by Ivar Jacobson.

Introduction to OO ParadigmOO paradigm is a significant methodology for the development of any software. Most of thearchitecture styles or patterns such as pipe and filter, data repository, and component-based canbe implemented by using this paradigm.

Basic concepts and terminologies of object–oriented systems −

ObjectAn object is a real-world element in an object–oriented environment that may have a physical or a

conceptual existence. Each object has −

Identity that distinguishes it from other objects in the system.

State that determines characteristic properties of an object as well as values of propertiesthat the object holds.

Behavior that represents externally visible activities performed by an object in terms ofchanges in its state.

Objects can be modeled according to the needs of the application. An object may have a physicalexistence, like a customer, a car, etc.; or an intangible conceptual existence, like a project, aprocess, etc.

ClassA class represents a collection of objects having same characteristic properties that exhibitcommon behavior. It gives the blueprint or the description of the objects that can be created fromit. Creation of an object as a member of a class is called instantiation. Thus, an object is aninstance of a class.

The constituents of a class are −

A set of attributes for the objects that are to be instantiated from the class. Generally,different objects of a class have some difference in the values of the attributes. Attributes areoften referred as class data.

A set of operations that portray the behavior of the objects of the class. Operations are alsoreferred as functions or methods.

Example

Let us consider a simple class, Circle, that represents the geometrical figure circle in a two–dimensional space. The attributes of this class can be identified as follows −

x–coord, to denote x–coordinate of the centery–coord, to denote y–coordinate of the centera, to denote the radius of the circle

Some of its operations can be defined as follows −

findArea, a method to calculate areafindCircumference, a method to calculate circumferencescale, a method to increase or decrease the radius

EncapsulationEncapsulation is the process of binding both attributes and methods together within a class.Through encapsulation, the internal details of a class can be hidden from outside. It permits theelements of the class to be accessed from outside only through the interface provided by the class.

PolymorphismPolymorphism is originally a Greek word that means the ability to take multiple forms. In object-oriented paradigm, polymorphism implies using operations in different ways, depending upon theinstances they are operating upon. Polymorphism allows objects with different internal structuresto have a common external interface. Polymorphism is particularly effective while implementinginheritance.

Example

Let us consider two classes, Circle and Square, each with a method findArea. Though the nameand purpose of the methods in the classes are same, the internal implementation, i.e., the

procedure of calculating an area is different for each class. When an object of class Circle invokesits findArea method, the operation finds the area of the circle without any conflict with the findAreamethod of the Square class.

Relationships

In order to describe a system, both dynamic behavioral and static logical specification of a systemmust be provided. The dynamic specification describes the relationships among objects e.g.message passing. And static specification describe the relationships among classes, e.g.aggregation, association, and inheritance.

Message PassingAny application requires a number of objects interacting in a harmonious manner. Objects in asystem may communicate with each other by using message passing. Suppose a system has twoobjects − obj1 and obj2. The object obj1 sends a message to object obj2, if obj1 wants obj2 toexecute one of its methods.

Composition or AggregationAggregation or composition is a relationship among classes by which a class can be made up ofany combination of objects of other classes. It allows objects to be placed directly within the bodyof other classes. Aggregation is referred as a “part–of” or “has–a” relationship, with the ability tonavigate from the whole to its parts. An aggregate object is an object that is composed of one ormore other objects.

AssociationAssociation is a group of links having common structure and common behavior. Associationdepicts the relationship between objects of one or more classes. A link can be defined as aninstance of an association. The Degree of an association denotes the number of classes involvedin a connection. The degree may be unary, binary, or ternary.

A unary relationship connects objects of the same class.A binary relationship connects objects of two classes.A ternary relationship connects objects of three or more classes.

InheritanceIt is a mechanism that permits new classes to be created out of existing classes by extending andrefining its capabilities. The existing classes are called the base classes/parent classes/super-classes, and the new classes are called the derived classes/child classes/subclasses.

The subclass can inherit or derive the attributes and methods of the super-class es provided thatthe super-class allows so. Besides, the subclass may add its own attributes and methods and maymodify any of the super-class methods. Inheritance defines a “is – a” relationship.

Example

From a class Mammal, a number of classes can be derived such as Human, Cat, Dog, Cow, etc.Humans, cats, dogs, and cows all have the distinct characteristics of mammals. In addition, eachhas its own particular characteristics. It can be said that a cow “is – a” mammal.

OO AnalysisIn object-oriented analysis phase of software development, the system requirements aredetermined, the classes are identified, and the relationships among classes are acknowledged.The aim of OO analysis is to understand the application domain and specific requirements of thesystem. The result of this phase is requirement specification and initial analysis of logical structureand feasibility of a system.

The three analysis techniques that are used in conjunction with each other for object-orientedanalysis are object modeling, dynamic modeling, and functional modeling.

Object ModelingObject modeling develops the static structure of the software system in terms of objects. Itidentifies the objects, the classes into which the objects can be grouped into and the relationshipsbetween the objects. It also identifies the main attributes and operations that characterize eachclass.

The process of object modeling can be visualized in the following steps −

Dynamic ModelingAfter the static behavior of the system is analyzed, its behavior with respect to time and externalchanges needs to be examined. This is the purpose of dynamic modeling.

Dynamic Modeling can be defined as “a way of describing how an individual object responds toevents, either internal events triggered by other objects, or external events triggered by theoutside world.”

The process of dynamic modeling can be visualized in the following steps −

Functional ModelingFunctional Modeling is the final component of object-oriented analysis. The functional modelshows the processes that are performed within an object and how the data changes, as it movesbetween methods. It specifies the meaning of the operations of an object modeling and the actionsof a dynamic modeling. The functional model corresponds to the data flow diagram of traditionalstructured analysis.

The process of functional modeling can be visualized in the following steps −

Object-Oriented DesignAfter the analysis phase, the conceptual model is developed further into an object-oriented modelusing object-oriented design OOD. In OOD, the technology-independent concepts in the analysismodel are mapped onto implementing classes, constraints are identified, and interfaces aredesigned, resulting in a model for the solution domain. The main aim of OO design is to developthe structural architecture of a system.

The stages for object–oriented design can be identified as −

OO Design can be divided into two stages − Conceptual design and Detailed design.

Conceptual design

In this stage, all the classes are identified that are needed for building the system. Further, specificresponsibilities are assigned to each class. Class diagram is used to clarify the relationships amongclasses, and interaction diagram are used to show the flow of events. It is also known as high-leveldesign.

Detailed design

In this stage, attributes and operations are assigned to each class based on their interactiondiagram. State machine diagram are developed to describe the further details of design. It is alsoknown as low-level design.

Design PrinciplesFollowing are the major design principles −

Principle of Decoupling

It is difficult to maintain a system with a set of highly interdependent classes, as modification inone class may result in cascading updates of other classes. In an OO design, tight coupling can beeliminated by introducing new classes or inheritance.

Ensuring Cohesion

A cohesive class performs a set of closely related functions. A lack of cohesion means — a classperforms unrelated functions, although it does not affect the operation of the whole system. Itmakes the entire structure of software hard to manage, expand, maintain, and change.

Open-closed Principle

According to this principle, a system should be able to extend to meet the new requirements. Theexisting implementation and the code of the system should not be modified as a result of a systemexpansion. In addition, the following guidelines have to be followed in open-closed principle −

For each concrete class, separate interface and implementations have to be maintained.

In a multithreaded environment, keep the attributes private.

Minimize the use of global variables and class variables.

DATA FLOW ARCHITECTUREDATA FLOW ARCHITECTUREIn data flow architecture, the whole software system is seen as a series of transformations onconsecutive pieces or set of input data, where data and operations are independent of each other.In this approach, the data enters into the system and then flows through the modules one at a timeuntil they are assigned to some final destination outputoradatastore.

The connections between the components or modules may be implemented as I/O stream, I/Obuffers, piped, or other types of connections. The data can be flown in the graph topology withcycles, in a linear structure without cycles, or in a tree type structure.

The main objective of this approach is to achieve the qualities of reuse and modifiability. It issuitable for applications that involve a well-defined series of independent data transformations orcomputations on orderly defined input and output such as compilers and business data processingapplications. There are three types of execution sequences between modules−

Batch sequentialPipe and filter or non-sequential pipeline modeProcess control

Batch SequentialBatch sequential is a classical data processing model, in which a data transformation subsystemcan initiate its process only after its previous subsystem is completely through −

The flow of data carries a batch of data as a whole from one subsystem to another.

The communications between the modules are conducted through temporary intermediatefiles which can be removed by successive subsystems.

It is applicable for those applications where data is batched, and each subsystem readsrelated input files and writes output files.

Typical application of this architecture includes business data processing such as bankingand utility billing.

AdvantagesNormally, Batch Sequential provides simpler divisions on subsystems. Each subsystem can be anindependent program working on input data and producing output data.

DisadvantagesDoes not provide concurrency and interactive interface rather it provides high latency and lowthroughput. Further, external control is required for the implementation.

Pipe and Filter ArchitectureThis approach lays emphasis on the incremental transformation of data by successive component.In this approach, the flow of data is driven by data and the whole system is decomposed intocomponents of data source, filters, pipes, and data sinks.

The connections between modules are data stream which is first-in/first-out buffer that can bestream of bytes, characters, or any other type of such kind. The main feature of this architecture isits concurrent and incremented execution.

FilterA filter is an independent data stream transformer or stream transducers. It transforms the data ofthe input data stream, processes it, and writes the transformed data stream over a pipe for thenext filter to process. It works in an incremental mode, in which it starts working as soon as dataarrives through connected pipe. There are two types of filters − active filter/ and passive filter.

Active filter

Active filter lets connected pipes to pull data in and push out the transformed data. It operates withpassive pipe, which provides read/write mechanisms for pulling and pushing. This mode is used inUNIX pipe and filter mechanism.

Passive filter

Passive filter lets connected pipes to push data in and pull data out. It operates with active pipe,which pulls data from a filter and pushes data into the next filter. It must provide read/writemechanism.

AdvantagesIt has following advantages −

Provides concurrency and high throughput for excessive data processing.

Provides reusability and simplifies system maintenance.

Provides modifiability and low coupling between filters.

Provides simplicity by offering clear divisions between any two filters connected by pipe.

Provides flexibility by supporting both sequential and parallel execution.

DisadvantagesIt has some of the following disadvantages −

Not suitable for dynamic interactions.

A low common denominator is needed for transmission of data in ASCII formats.

Overhead of data transformation between filters.

Does not provide a way for filters to cooperatively interact to solve a problem.

Difficult to configure this architecture dynamically.

PipePipes are stateless and they carry binary or character stream which exist between two filters. It canmove a data stream from one filter to another. Pipes use a little contextual information and retainno state information between instantiations.

Process Control ArchitectureIt is a type of data flow architecture where data is neither batched sequential nor pipelined stream.The flow of data comes from a set of variables, which controls the execution of process. Itdecomposes the entire system into subsystems or modules and connects them.

Types of SubsystemsA process control architecture would have a processing unit for changing the process controlvariables and a controller unit for calculating the amount of changes.

A controller unit must have the following elements −

Controlled Variable − Controlled Variable provides values for the underlying system andshould be measured by sensors. For example, speed in cruise control system.

Input Variable − Measures an input to the process. For example, temperature of return airin temperature control system

Manipulated Variable − Manipulated Variable value is adjusted or changed by thecontroller.

Process Definition − It includes mechanisms for manipulating some process variables.

Sensor − Obtains values of process variables pertinent to control and can be used as afeedback reference to recalculate manipulated variables.

Set Point − It is the desired value for a controlled variable.

Control Algorithm − It is used for deciding how to manipulate process variables.

Application AreasProcess control architecture is suitable in the following domains −

Embedded system software design, where the system is manipulated by process controlvariable data.

Applications, which aim is to maintain specified properties of the outputs of the process atgiven reference values.

Applicable for car-cruise control and building temperature control systems.

Real-time system software to control automobile anti-lock brakes, nuclear power plants, etc.

DATA-CENTERED ARCHITECTUREDATA-CENTERED ARCHITECTUREIn data-centered architecture, the data is centralized and accessed frequently by othercomponents, which modify data. The main purpose of this style is to achieve integrality of data.Data-centered architecture consists of different components that communicate through shareddata repositories. The components access a shared data structure and are relatively independent,in that, they interact only through the data store.

The most well-known examples of the data-centered architecture is a database architecture, inwhich the common database schema is created with data definition protocol – for example, a setof related tables with fields and data types in an RDBMS.

Another example of data-centered architectures is the web architecture which has a common dataschema i. e. meta − structureoftheWeb and follows hypermedia data model and processes communicatethrough the use of shared web-based data services.

Types of ComponentsThere are two types of components −

A central data structure or data store or data repository, which is responsible for providingpermanent data storage. It represents the current state.

A data accessor or a collection of independent components that operate on the central datastore, perform computations, and might put back the results.

Interactions or communication between the data accessors is only through the data store. Thedata is the only means of communication among clients. The flow of control differentiates thearchitecture into two categories as Repository Architecture Style and BlackboardArchitecture Style. A brief detail about both the categories is given below −

Repository Architecture StyleIn Repository Architecture Style, the data store is passive and the clients softwarecomponentsoragents ofthe data store are active, which control the logic flow. The participating components check thedata-store for changes.

A client sends a request to the system to perform actions e. g. insertdata. The computationalprocesses are independent and triggered by incoming requests. If the types of transactions in aninput stream of transactions trigger selection of processes to execute, then it is traditionaldatabase or repository architecture, or passive repository. This approach is widely used in DBMS,library information system, the interface repository in CORBA, compilers, and CASE computeraidedsoftwareengineering environments.

AdvantagesRepository Architecture Style has following advantages −

Provides data integrity, backup and restore features.

Provides scalability and reusability of agents as they do not have direct communication witheach other.

Reduces overhead of transient data between software components.

DisadvantagesBecause of being more vulnerable to failure and data replication or duplication, RepositoryArchitecture Style has following disadvantages −

High dependency between data structure of data store and its agents.

Changes in data structure highly affect the clients.

Evolution of data is difficult and expensive.

Cost of moving data on network for distributed data.

Blackboard Architecture StyleIn Blackboard Architecture Style, the data store is active and its clients are passive. Therefore thelogical flow is determined by the current data status in data store. It has a blackboard component,acting as a central data repository, and an internal representation is built and acted upon bydifferent computational elements.

Further, a number of components that act independently on the common data structure are storedin the blackboard. In this style, the components interact only through the blackboard. The data-store alerts the clients whenever there is a data-store changes. The current state of the solution isstored in the blackboard and processing is triggered by the state of the blackboard.

When changes occur in the data, the system sends the notifications known as trigger and data tothe clients. This approach is found in certain AI applications and complex applications, such asspeech recognition, image recognition, security system, and business resource managementsystems etc.

If the current state of the central data structure is the main trigger of selecting processes toexecute, the repository can be a blackboard and this shared data source is an active agent.

A major difference with traditional database systems is that the invocation of computationalelements in a blackboard architecture is triggered by the current state of the blackboard, and notby external inputs.

Parts of Blackboard ModelThe blackboard model is usually presented with three major parts −

Knowledge Sources KSKnowledge Sources, also known as Listeners or Subscribers are distinct and independent units.They solve parts of a problem and aggregate partial results. Interaction among knowledge sourcestakes place uniquely through the blackboard.

Blackboard Data StructureThe problem-solving state data is organized into an application-dependent hierarchy. Knowledgesources make changes to the blackboard that lead incrementally to a solution to the problem.

ControlControl manages tasks and checks the work state.

AdvantagesBlackboard Model provides concurrency that allows all knowledge sources to work in parallel asthey independent of each other. Its scalability feature facilitates easy steps to add or updateknowledge source. Further, it supports experimentation for hypotheses and reusability ofknowledge source agents.

DisadvantagesThe structural change of blackboard may have a significant impact on all of its agents, as closedependency exists between blackboard and knowledge source. Blackboard model is expected toproduce approximate solution; however, sometimes, it becomes difficult to decide when toterminate the reasoning.

Further, this model suffers some problems in synchronization of multiple agents, therefore, it faceschallenge in designing and testing of the system.

HIERARCHICAL ARCHITECTUREHIERARCHICAL ARCHITECTUREHierarchical architecture views the whole system as a hierarchy structure, in which the softwaresystem is decomposed into logical modules or subsystems at different levels in the hierarchy. Thisapproach is typically used in designing system software such as network protocols and operatingsystems.

In system software hierarchy design, a low-level subsystem gives services to its adjacent upperlevel subsystems, which invoke the methods in the lower level. The lower layer provides morespecific functionality such as I/O services, transaction, scheduling, security services, etc. Themiddle layer provides more domain dependent functions such as business logic and coreprocessing services. And, the upper layer provides more abstract functionality in the form of userinterface such as GUIs, shell programming facilities, etc.

It is also used in organization of the class libraries such as .NET class library in namespacehierarchy. All the design types can implement this hierarchical architecture and often combinewith other architecture styles.

Hierarchical architectural styles is divided as −

Main-subroutineMaster-slave

Virtual machine

Main-subroutineThe aim of this style is to reuse the modules and freely develop individual modules or subroutine.In this style, a software system is divided into subroutines by using top-down refinement accordingto desired functionality of the system.

These refinements lead vertically until the decomposed modules is simple enough to have itsexclusive independent responsibility. Functionality may be reused and shared by multiple callersin the upper layers.

There are two ways by which data is passed as parameters to subroutines, namely −

Pass by Value − Subroutines only use the past data, but can’t modify it.

Pass by Reference &minu; Subroutines use as well as change the value of the datareferenced by the parameter.

AdvantagesSignificant advantages of Main-subroutine are — it is easy to decompose the system based onhierarchy refinement. Further, it can be also used in a subsystem of object oriented design.

DisadvantagesMain-subroutine has some disadvantages such as tight coupling may cause more ripple effects ofchanges. Secondly, it contains globally shared data, so it is also vulnerable.

Master-SlaveThis approach applies the 'divide and conquer' principle and supports fault computation andcomputational accuracy. It is a modification of the main-subroutine architecture that providesreliability of system and fault tolerance.

In this architecture, slaves provide duplicat services to the master, and the master chooses aparticular result among slaves by a certain selection strategy. The slaves may perform the samefunctional task by different algorithms and methods or totally different functionality. It includesparallel computing in which all the slaves can be executed in parallel.

The implementation of the Master-Slave pattern follows five steps −

Step 1 − Specify how the computation of the task can be divided into a set of equal sub-tasks and identify the sub-services that are needed to process a sub-task.

Step 2 − Specify how the final result of the whole service can be computed with the help ofthe results obtained from processing individual sub-tasks.

Step 3 − Define an interface for the sub-service identified in step 1. It will be implementedby the slave and used by the master to delegate the processing of individual sub-tasks.

Step 4 − Implement the slave components according to the specifications developed in theprevious step.

Step 5 − Implement the master according to the specifications developed in step 1 to 3.

ApplicationsSuitable for applications where reliability of software is critical issue.Widely applied in the areas of parallel and distributed computing.

AdvantagesFaster computation and easy scalability.Provides robustness as slaves can be duplicated.Slave can be implemented differently to minimize semantic errors.

DisadvantagesCommunication overhead.Not all problems can be divided.Hard to implement and portability issue.

Virtual Machine ArchitectureVirtual Machine architecture pretends some functionality, which is not native to the hardwareand/or software on which it is implemented. A virtual machine is built upon an existing system andprovides a virtual abstraction, a set of attributes, and operations.

In virtual machine architecture, the master uses the ‘same’ subservice’ from the slave andperforms functions such as split work, call slaves, and combine results. It allows developers tosimulate and test platforms, which have not yet been built, and simulate "disaster'' modes thatwould be too complex, costly, or dangerous to test with the real system.

In most cases, a virtual machine splits a programming language or application environment froman execution platform. The main objective is to provide portability. Interpretation of a particularmodule via a Virtual Machine may be perceived as −

The interpretation engine chooses an instruction from the module being interpreted.

Based on the instruction, the engine updates the virtual machine’s internal state and theabove process is repeated.

The following figure shows the architecture of a standard VM infrastructure on a single physicalmachine.

The hypervisor, also called the virtual machine monitor, runs on the host OS and allocatesmatched resources to each guest OS. When the guest makes a system-call, the hypervisorintercepts and translates it into the corresponding system-call supported by the host OS. Thehypervisor controls each virtual machine access to the CPU, memory, persistent storage, I/Odevices, and the network.

ApplicationsVirtual machine architecture is suitable in the following domains −

Suitable for solving a problem by simulation or translation if there is no direct solution.

Sample applications include interpreters of microprogramming, XML processing, scriptcommand language execution, rule-based system execution, Smalltalk and Java interpretertyped programming language.

Common examples of virtual machines are interpreters, rule-based systems, syntactic shells,and command language processors.

AdvantagesBecause of having the features of portability and machine platform independency, it has followingadvantages −

Simplicity of software development.Provides flexibility through the ability to interrupt and query the program.Simulation for disaster working model.Introduce modifications at runtime.

DisadvantagesSlow execution of the interpreter due to the interpreter nature.There is a performance cost because of the additional computation involved in execution.

Layered Style

In this approach, the system is decomposed into a number of higher and lower layers in ahierarchy, and each layer has its own sole responsibility in the system.

Each layer consists of a group of related classes that are encapsulated in a package, in a deployedcomponent, or as a group of subroutines in the format of method library or header file.

Each layer provides service to the layer above it and serves as a client to the layer below i.e.request to layer i +1 invokes the services provided by the layer i via the interface of layer i. Theresponse may go back to the layer i +1 if the task is completed; otherwise layer i continuallyinvokes services from layer i -1 below.

ApplicationsLayered style is suitable in the following areas −

Applications that involve distinct classes of services that can be organized hierarchically.

Any application that can be decomposed into application-specific and platform-specificportions.

Applications that have clear divisions between core services, critical services, and userinterface services, etc.

AdvantagesIt has following advantages −

Design based on incremental levels of abstraction.

Provides enhancement independence as changes to the function of one layer affects at mosttwo other layers.

Separation of the standard interface and its implementation.

Implemented by using component-based technology which makes the system much easier toallow for plug-and-play of new components.

Each layer can be an abstract machine deployed independently which support portability.

Easy to decompose the system based on the definition of the tasks in a top-down refinementmanner

Different implementations withidenticalinterfaces of the same layer can be used interchangeably

DisadvantagesSince, many applications or systems are not easily structured in a layered fashion, so it hasfollowing disadvantages −

Lower runtime performance since a client’s request or a response to client must go throughpotentially several layers.

There are also performance concerns on overhead on the data marshaling and buffering byeach layer.

Opening of interlayer communication may cause deadlocks and “bridging” may cause tightcoupling.

Exceptions and error handling is an issue in the layered architecture, since faults in one layermust spread upwards to all calling layers

INTERACTION-ORIENTED ARCHITECTUREINTERACTION-ORIENTED ARCHITECTUREThe primary objective of interaction-oriented architecture is to separate the interaction of userfrom data abstraction and business data processing. The interaction-oriented software

architecture decomposes the system into three major partitions −

Data module − Data module provides the data abstraction and all business logic.

Control module − Control module identifies the flow of control and system configurationactions.

View presentation module − View presentation module is responsible for visual or audiopresentation of data output and it also provides an interface for user input.

Interaction-oriented architecture has two major styles − Model-View-Controller MVC andPresentation-Abstraction-Control PAC. Both MVC and PAC propose three componentsdecomposition and are used for interactive applications such as web applications with multipletalks and user interactions. They are different in their flow of control and organization. PAC is anagent-based hierarchical architecture but MVC does not have a clear hierarchical structure.

Model-View-Controller MVCMVC decomposes a given software application into three interconnected parts that help inseparating the internal representations of information from the information presented to oraccepted from the user.

Module Function

Model Encapsulation the underlying data and business logic

Controller Respond to user action and direct the application flow

View Formats and present the data from model to user.

ModelModel is a central component of MVC that directly manages the data, logic, and constraints of anapplication. It consists of data components, which maintain the raw application data andapplication logic for interface.

It is an independent user interface and captures the behavior of application problem domain.Model is the domain-specific software simulation or implementation of the application's centralstructure.

If there is change in its state, it gives notification to its associated view to produce updated output,and the controller to change the available set of commands.

ControllerA controller accepts an input and converts it into commands for the model or view. It acts as aninterface between the associated models and views and the input devices.

Controller can send commands to the model to update the model’s state and to its associated viewto change the view’s presentation of the model. Likewise, as shown in the picture given below, itconsists of input processing components, which handle input from the user by modifying themodel.

ViewView can be used to represent any output of information in graphical form such as diagram orchart. It consists of presentation components which provide the visual representations of data.

Views request information from their model and generate an output representation to the user.Multiple views of the same information are possible, such as a bar chart for management and atabular view for accountants.

MVC - IIt is a simple version of MVC architecture where the system is divided into two sub-systems −

The Controller-View − The controller-view acts as input /output interface and processing isdone.

The Model − The model provides all the data and domain services.

MVC-I Architecture

The model module notifies controller-view module of any data changes so that any graphics datadisplay will be changed accordingly. The controller also takes appropriate action upon thechanges.

The connection between controller-view and model can be designed in a pattern asshownintheabovepicture of subscribe-notify whereby the controller-view subscribes to model andmodel notifies controller-view of any changes.

MVC - IIMVC–II is an enhancement of MVC-I architecture in which the view module and the controllermodule are separate. The model module plays an active role as in MVC-I by providing all the corefunctionality and data supported by database.

The view module presents data while controller module accepts input request, validates inputdata, initiates the model, the view, their connection, and also dispatches the task.

MVC-II Architecture

MVC ApplicationsMVC applications are effective for interactive applications where multiple views are needed for asingle data model and easy to plug-in a new or change interface view.

MVC applications are suitable for applications where there are clear divisions between themodules so that different professionals can be assigned to work on different aspects of suchapplications concurrently.

Advantages

Because of having multiple MVC vendor framework toolkits, it has following advantages −

Multiple views synchronized with same data model.

Easy to plug-in new or replace interface views.

Used for application development where graphics expertise professionals, programmingprofessionals, and data base development professionals are working in a designed projectteam.

Disadvantages

Not suitable for agent-oriented applications such as interactive mobile and roboticsapplications.

Multiple pairs of controllers and views based on the same data model make any data modelchange expensive.

The division between the View and the Controller is not clear in some cases.

Presentation-Abstraction-Control PACIn PAC, the system is arranged into a hierarchy of many cooperating agents triads. It was developedfrom MVC to support the application requirement of multiple agents in addition to interactiverequirements.

Each agent has three components −

The presentation component − Formats the visual and audio presentation of data.

The abstraction component − Retrieves and processes the data.

The control component − Handles the task such as the flow of control and communicationbetween the other two components.

The PAC architecture is similar to MVC, in the sense that presentation module is like view moduleof MVC. The abstraction module looks like model module of MVC and the control module is like thecontroller module of MVC, but they differ in their flow of control and organization.

There are no direct connections between abstraction component and presentation component ineach agent. The control component in each agent is in charge of communications with otheragents.

The following figure shows a block diagram for a single agent in PAC design.

PAC with Multiple AgentsAs shown in the following image, in PACs consisting of multiple agents, the top-level agent providescore data and business logics. The bottom level agents define detailed specific data andpresentations. The intermediate level or middle level agent acts as coordinator of low-levelagents.

Each agent has its own specific assigned job. For some middle level agents the interactivepresentations are not required, so they do not have a presentation component. The controlcomponent is required for all agents through which all the agents communicate with each other.

Applications

Effective for an interactive system where the system can be decomposed into manycooperating agents in a hierarchical manner.

Effective when the coupling among the agents is expected to be loose so that changes on anagent does not affect others.

Effective for distributed system where all the agents are distantly distributed and each ofthem has its own functionalities with data and interactive interface.

Suitable for applications with rich GUI components where each of them keeps its own currentdata and interactive interface and needs to communicate with other components.

AdvantagesSupport for multi-tasking and multi-viewing

Support for agent reusability and extensibility

Easy to plug-in new agent or change an existing one

Support for concurrency where multiple agents are running in parallel in different threads ordifferent devices or computers

DisadvantagesOverhead due to the control bridge between presentation and abstraction and thecommunication of controls among agents.

Difficult to determine the right number of agents because of loose coupling and highindependence among agents.

DISTRIBUTED ARCHITECTUREDISTRIBUTED ARCHITECTUREIn distributed architecture, components are presented on different platforms and severalcomponents can cooperate with one another over a communication network in order to achieve aspecific objective or goal.

Concept of Distributed ArchitectureA distributed system can be demonstrated by the client-server architecture, which forms the basefor multi-tier architectures; alternatives are the broker architecture such as CORBA, and theService-Oriented Architecture SOA. In this architecture, information processing is not confined to asingle machine rather it is distributed over several independent computers.

There are several technology frameworks to support distributed architectures, including .NET,J2EE, CORBA, .NET Web services, AXIS Java Web services, and Globus Grid services. Middleware isan infrastructure that appropriately supports the development and execution of distributed

applications. It provides a buffer between the applications and the network.

It sits in the middle of system and manages or supports the different components of a distributedsystem. Examples are transaction processing monitors, data convertors and communicationcontrollers, etc.

Middleware as an infrastructure for distributed system −

Basis of Distributed ArchitectureThe basis of a distributed architecture is its transparency, reliability, and availability.

The following table lists the different forms of transparency in a distributed system −

Transparency Description

Access Hides the way in which resources are accessed and the differencesin data platform.

Location Hides where resources are located.

Technology Hides different technologies such as programming language and OSfrom user.

Migration / Relocation Hide resources that may be moved to another location which are inuse.

Replication Hide resources that may be copied at several location.

Concurrency Hide resources that may be shared with other users.

Failure Hides failure and recovery of resources from user.

Persistence Hides whether a resource software is in memory or disk.

AdvantagesIt has following advantages −

Resource sharing − Sharing of hardware and software resources.

Openness − Flexibility of using hardware and software of different vendors.

Concurrency − Concurrent processing to enhance performance.

Scalability − Increased throughput by adding new resources.

Fault tolerance − The ability to continue in operation after a fault has occurred.

DisadvantagesIts disadvantages are −

Complexity − They are more complex than centralized systems.

Security − More susceptible to external attack.

Manageability − More effort required for system management.

Unpredictability − Unpredictable responses depending on the system organization andnetwork load.

Centralized System vs. Distributed System

Criteria Centralized system Distributed System

Economics Low High

Availability Low High

Complexity Low High

Consistency Simple High

Scalability Poor Good

Technology Homogeneous Heterogeneous

Security High Low

Client-Server ArchitectureThe client-server architecture is the most common distributed system architecture whichdecomposes the system into two major subsystems or logical processes −

Client − This is the first process that issues a request to the second process i.e. the server.

Server − This is the second process that receives the request, carries it out, and sends areply to the client.

In this architecture, the application is modelled as a set of services those are provided by serversand a set of clients that use these services. The servers need not to know about clients, but theclients must know the identity of servers.

Client-server Architecture can be classified into two models based on the functionality of the client−

Thin-client modelIn thin-client model, all the application processing and data management is carried by the server.The client is simply responsible for running the GUI software. It is used when legacy systems aremigrated to client server architectures in which legacy system acts as a server in its own right witha graphical interface implemented on a client.

However, A major disadvantage is that it places a heavy processing load on both the server andthe network.

Thick/Fat-client modelIn thick-client model, the server is in-charge of the data management. The software on the clientimplements the application logic and the interactions with the system user. It is most appropriatefor new client-server systems where the capabilities of the client system are known in advance.

However, it is more complex than a thin client model especially for management, as all clientsshould have same copy/version of software application.

AdvantagesSeparation of responsibilities such as user interface presentation and business logicprocessing.

Reusability of server components and potential for concurrency

Simplifies the design and the development of distributed applications

It makes it easy to migrate or integrate existing applications into a distributed environment.

It also makes effective use of resources when a large number of clients are accessing a high-performance server.

DisadvantagesLack of heterogeneous infrastructure to deal with the requirement changes.Security complications.Limited server availability and reliability.Limited testability and scalability.Fat clients with presentation and business logic together.

Multi-Tier Architecture n − tierArchitecture

Multi-tier architecture is a client–server architecture in which the functions such as presentation,application processing, and data management are physically separated. By separating anapplication into tiers, developers obtain the option of changing or adding a specific layer, insteadof reworking the entire application. It provides a model by which developers can create flexibleand reusable applications.

The most general use of multi-tier architecture is the three-tier architecture. A three-tierarchitecture is typically composed of a presentation tier, an application tier, and a data storagetier and may execute on a separate processor.

Presentation TierPresentation layer is the topmost level of the application by which users can access directly suchas webpage or Operating System GUI GraphicalUserinterface. The primary function of this layer is totranslate the tasks and results to something that user can understand. It communicates with othertiers so that it places the results to the browser/client tier and all other tiers in the network.

Application Tier BusinessLogic,LogicTier, orMiddleTierApplication tier coordinates the application, processes the commands, makes logical decisions,evaluation, and performs calculations. It controls an application’s functionality by performingdetailed processing. It also moves and processes data between the two surrounding layers.

Data TierIn this layer, information is stored and retrieved from the database or file system. The informationis then passed back for processing and then back to the user. It includes the data persistence

mechanisms databaseservers, fileshares, etc. and provides API ApplicationProgrammingInterface to theapplication tier which provides methods of managing the stored data.

Advantages

Better performance than a thin-client approach and is simpler to manage than a thick-clientapproach.

Enhances the reusability and scalability − as demands increase, extra servers can be added.

Provides multi-threading support and also reduces network traffic.

Provides maintainability and flexibility

Disadvantages

Unsatisfactory Testability due to lack of testing tools.More critical server reliability and availability.

Broker Architectural StyleBroker Architectural Style is a middleware architecture used in distributed computing tocoordinate and enable the communication between registered servers and clients. Here, objectcommunication takes place through a middleware system called an object request broker softwarebus.

However, client and the server do not interact with each other directly. Client and server have adirect connection to its proxy, which communicates with the mediator-broker. A server providesservices by registering and publishing their interfaces with the broker and clients can request theservices from the broker statically or dynamically by look-up.

CORBA CommonObjectRequestBrokerArchitecture is a good implementation example of the brokerarchitecture.

Components of Broker Architectural StyleThe components of broker architectural style are discussed through following heads −

Broker

Broker is responsible for coordinating communication, such as forwarding and dispatching theresults and exceptions. It can be either an invocation-oriented service, a document or message -oriented broker to which clients send a message.

Broker is responsible for brokering the service requests, locating a proper server, transmittingrequests, and sending responses back to clients. It also retains the servers’ registration informationincluding their functionality and services as well as location information.

Further, it provides APIs for clients to request, servers to respond, registering or unregisteringserver components, transferring messages, and locating servers.

Stub

Stubs are generated at the static compilation time and then deployed to the client side which isused as a proxy for the client. Client-side proxy acts as a mediator between the client and thebroker and provides additional transparency between them and the client; a remote objectappears like a local one.

The proxy hides the IPC inter − processcommunication at protocol level and performs marshaling ofparameter values and un-marshaling of results from the server.

Skeleton

Skeleton is generated by the service interface compilation and then deployed to the server side,which is used as a proxy for the server. Server-side proxy encapsulates low-level system-specificnetworking functions and provides high-level APIs to mediate between the server and the broker.

Further, it receives the requests, unpacks the requests, unmarshals the method arguments, callsthe suitable service, and also marshals the result before sending it back to the client.

Bridge

A bridge can connect two different networks based on different communication protocols. Itmediates different brokers including DCOM, .NET remote, and Java CORBA brokers.

Bridges are optional component, which hides the implementation details when two brokersinteroperate and take requests and parameters in one format and translate them to anotherformat.

Broker implementation in CORBA

CORBA is an international standard for an Object Request Broker – a middleware to managecommunications among distributed objects defined by OMG objectmanagementgroup.

Service-Oriented Architecture SOAA service is a component of business functionality that is well-defined, self-contained,independent, published, and available to be used via a standard programming interface. Theconnections between services are conducted by common and universal message-orientedprotocols such as the SOAP Web service protocol, which can deliver requests and responsesbetween services loosely.

Service-oriented architecture is a client/server design which support business-driven IT approachin which an application consists of software services and software service consumers alsoknownasclientsorservicerequesters.

Features of SOAA service-oriented architecture provides the following features −

Distributed Deployment − Expose enterprise data and business logic as loosely, coupled,discoverable, structured, standard-based, coarse-grained, stateless units of functionalitycalled services.

Composability − Assemble new processes from existing services that are exposed at adesired granularity through well defined, published, and standard complaint interfaces.

Interoperability − Share capabilities and reuse shared services across a networkirrespective of underlying protocols or implementation technology.

Reusability − Choose a service provider and access to existing resources exposed asservices.

SOA Operation

The following figure illustrates how does SOA operate −

Advantages

Loose coupling of service–orientation provides great flexibility for enterprises to make use ofall available service recourses irrespective of platform and technology restrictions.

Each service component is independent from other services due to the stateless servicefeature.

The implementation of a service will not affect the application of the service as long as theexposed interface is not changed.

A client or any service can access other services regardless of their platform, technology,vendors, or language implementations.

Reusability of assets and services since clients of a service only need to know its publicinterfaces, service composition.

SOA based business application development are much more efficient in terms of time andcost.

Enhances the scalability and provide standard connection between systems.

Efficient and effective usage of ‘Business Services’.

Integration becomes much easier and improved intrinsic interoperability.

Abstract complexity for developers and energize business processes closer to end users.

COMPONENT-BASED ARCHITECTURECOMPONENT-BASED ARCHITECTUREComponent-based architecture focuses on the decomposition of the design into individualfunctional or logical components that represent well-defined communication interfaces containingmethods, events, and properties. It provides a higher level of abstraction and divides the probleminto sub-problems, each associated with component partitions.

The primary objective of component-based architecture is to ensure component reusability. Acomponent encapsulates functionality and behaviors of a software element into a reusable andself-deployable binary unit. There are many standard component frameworks such as COM/DCOM,JavaBean, EJB, CORBA, .NET, web services, and grid services. These technologies are widely usedin local desktop GUI application design such as graphic JavaBean components, MS ActiveXcomponents, and COM components which can be reused by simply drag and drop operation.

Component-oriented software design has many advantages over the traditional object-orientedapproaches such as −

Reduced time in market and the development cost by reusing existing components.

Increased reliability with the reuse of the existing components.

What is a Component?A component is a modular, portable, replaceable, and reusable set of well-defined functionalitythat encapsulates its implementation and exporting it as a higher-level interface.

A component is a software object, intended to interact with other components, encapsulatingcertain functionality or a set of functionalities. It has an obviously defined interface and conformsto a recommended behavior common to all components within an architecture.

A software component can be defined as a unit of composition with a contractually specifiedinterface and explicit context dependencies only. That is, a software component can be deployedindependently and is subject to composition by third parties.

Views of a ComponentA component can have three different views − object-oriented view, conventional view, andprocess-related view.

Object-oriented view

A component is viewed as a set of one or more cooperating classes. Each problem domain class analysis and infrastructure class design are explained to identify all attributes and operations thatapply to its implementation. It also involves defining the interfaces that enable classes tocommunicate and cooperate.

Conventional view

It is viewed as a functional element or a module of a program that integrates the processing logic,the internal data structures that are required to implement the processing logic and an interfacethat enables the component to be invoked and data to be passed to it.

Process-related view

In this view, instead of creating each component from scratch, the system is building from existingcomponents maintained in a library. As the software architecture is formulated, components areselected from the library and used to populate the architecture.

A user interface UI component includes grids, buttons referred as controls, and utilitycomponents expose a specific subset of functions used in other components.

Other common types of components are those that are resource intensive, not frequentlyaccessed, and must be activated using the just-in-time JIT approach.

Many components are invisible which are distributed in enterprise business applications andinternet web applications such as Enterprise JavaBean EJB, .NET components, and CORBAcomponents.

Characteristics of ComponentsReusability − Components are usually designed to be reused in different situations indifferent applications. However, some components may be designed for a specific task.

Replaceable − Components may be freely substituted with other similar components.

Not context specific − Components are designed to operate in different environments andcontexts.

Extensible − A component can be extended from existing components to provide newbehavior.

Encapsulated − A A component depicts the interfaces, which allow the caller to use itsfunctionality, and do not expose details of the internal processes or any internal variables orstate.

Independent − Components are designed to have minimal dependencies on othercomponents.

Principles of Component−Based DesignA component-level design can be represented by using some intermediary representation e. g. graphical, tabular, ortext − based that can be translated into source code. The design of datastructures, interfaces, and algorithms should conform to well-established guidelines to help usavoid the introduction of errors.

It has following salient features −

The software system is decomposed into reusable, cohesive, and encapsulated componentunits.

Each component has its own interface that specifies required ports and provided ports; eachcomponent hides its detailed implementation.

A component should be extended without the need to make internal code or designmodifications to the existing parts of the component.

Depend on abstractions component do not depend on other concrete components, whichincrease difficulty in expendability.

Connectors connected components, specifying and ruling the interaction amongcomponents. The interaction type is specified by the interfaces of the components.

Components interaction can take the form of method invocations, asynchronous invocations,broadcasting, message driven interactions, data stream communications, and other protocolspecific interactions.

For a server class, specialized interfaces should be created to serve major categories ofclients. Only those operations that are relevant to a particular category of clients should bespecified in the interface.

A component can extend to other components and still offer its own extension points. It is theconcept of plug-in based architecture. This allows a plugin to offer another plugin API.

Component-Level Design Guidelines

It creates a naming conventions for components that are specified as part of the architecturalmodel and then refines or elaborates as part of the component-level model.

Attains architectural component names from the problem domain and ensures that theyhave meaning to all stakeholders who view the architectural model.

Extracts the business process entities that can exist independently without any associateddependency on other entities.

Recognizes and discover these independent entities as new components.

Uses infrastructure component names that reflect their implementation-specific meaning.

Models any dependencies from left to right and inheritance from top baseclass to bottom derivedclasses.

Model any component dependencies as interfaces rather than representing them as a directcomponent-to-component dependency.

Conducting Component-Level DesignIt recognizes all design classes that correspond to the problem domain as defined in the analysismodel and architectural model.

This design has following important features −

Recognizes all design classes that correspond to the infrastructure domain.

Describes all design classes that are not acquired as reusable components, and specifiesmessage details.

Identifies appropriate interfaces for each component and elaborates attributes and definesdata types and data structures required to implement them.

Describes processing flow within each operation in detail by means of pseudo code or UMLactivity diagrams.

Describes persistent data sources databasesandfiles and identifies the classes required tomanage them.

Develops and elaborates behavioral representations for a class or component. This can bedone by elaborating the UML state diagrams created for the analysis model and byexamining all use cases that are relevant to the design class.

Elaborates deployment diagrams to provide additional implementation detail.

Demonstrates the location of key packages or classes of components in a system by usingclass instances and designating specific hardware and operating system environment.

The final decision can be made by using established design principles and guidelines.Experienced designers consider all ormost of the alternative design solutions before settlingon the final design model.

AdvantagesEase of deployment − As new compatible versions become available, it is easier to replaceexisting versions with no impact on the other components or the system as a whole.

Reduced cost − The use of third-party components allows you to spread the cost ofdevelopment and maintenance.

Ease of development − Components implement well-known interfaces to provide definedfunctionality, allowing development without impacting other parts of the system.

Reusable − The use of reusable components means that they can be used to spread thedevelopment and maintenance cost across several applications or systems.

Modification of technical complexity − A component modifies the complexity throughthe use of a component container and its services.

Reliability − The overall system reliability increases since the reliability of each individualcomponent enhances the reliability of the whole system via reuse.

System maintenance and evolution − Easy to change and update the implementationwithout affecting the rest of the system.

Independent − Independency and flexible connectivity of components. Independentdevelopment of components by different group in parallel. Productivity for the softwaredevelopment and future software development.

USER INTERFACEUSER INTERFACEUser interface is the first impression of a software system from the user’s point of view. Thereforeany software system must satisfy the requirement of user.

Functions and Features of UIUser Interface UI mainly performs two functions −

Accepting the user’s inputDisplaying the output

User interface plays a crucial role in any software system. It is possibly the only visible aspect of asoftware system as −

Users will initially see the architecture of software system’s external user interface withoutconsidering its internal architecture.

A good user interface must attract the user to use the software system without mistakes. Itshould help the user to understand the software system easily without misleadinginformation. A bad UI may cause market failure against the competition of software system.

UI has its syntax and semantics. The syntax comprises component types such as textual, icon,button etc. and usability summarizes the semantics of UI. The quality of UI is characterized byits look and feel syntax and its usability semantics.

There are basically two major kinds of user interface − a) Textual b) Graphical.

Software in different domains may require different style of its user interface for e.g.calculator need only a small area for displaying numeric numbers, but a big area forcommands, A web page needs forms, links, tabs, etc.

Graphical User InterfaceA graphical user interface is the most common type of user interface available today. It is a veryuser friendly because it makes use of pictures, graphics, and icons - hence why it is called'graphical'.

It is also known as a WIMP interface because it makes use of −

Windows − A rectangular area on the screen where the commonly used applications run.

Icons − A picture or symbol which is used to represent a software application or hardwaredevice.

Menus − A list of options from which the user can choose what they require.

Pointers − A symbol such as an arrow which moves around the screen as user moves themouse. It helps user to select objects.

Design of User InterfaceIt starts with task analysis which understands the user’s primary tasks and problem domain. It

should be designed in terms of User’s terminology and outset of user’s job rather thanprogrammer’s.

Proper or good UI design works from the user’s capabilities and limitations not the machines. Whiledesigning the UI, knowledge of the nature of the user's work and environment is also critical.

Elements of UITo perform user interface analysis, the practitioner needs to study and understand four elements−

The users who will interact with the system through the interface

The tasks that end users must perform to do their work

The content that is presented as part of the interface

The work environment in which these tasks will be conducted

Levels of UI DesignThe task to be performed and then can be divided, which are assigned to the user or machine,based on knowledge of the capabilities and limitations of each.

The design of a user interface is often divided into four different levels −

The conceptual level − It describes the basic entities considering the user's view of thesystem and the actions possible upon them.

The semantic level − It describes the functions performed by the system i.e. description ofthe functional requirements of the system, but does not address how the user will invoke thefunctions.

The syntactic level − It describes the sequences of inputs and outputs required to invokethe functions described.

The lexical level − It determines how the inputs and outputs are actually formed fromprimitive hardware operations.

Steps of UI DesignUser interface design is an iterative process, where all the iteration explains and refines theinformation developed in the preceding steps. General steps for user interface design −

Defines user interface objects and actions operations.

Defines events useractions that will cause the state of the user interface to change.

Indicates how the user interprets the state of the system from information provided throughthe interface.

Describe each interface state as it will actually look to the end user.

User Interface Development ProcessIt follows a spiral process as shown in the following diagram −

Interface analysis

It concentrates or focuses on users, tasks, content, and work environment who will interact with thesystem. Defines the human - and computer-oriented tasks that are required to achieve systemfunction.

Interface design

It defines a set of interface objects, actions, and their screen representations that enable a user toperform all defined tasks in a manner that meets every usability objective defined for the system.

Interface construction

It starts with a prototype that enables usage scenarios to be evaluated and continues withdevelopment tools to complete the construction.

Interface validation

It focuses on the ability of the interface to implement every user task correctly, accommodate alltask variations, to achieve all general user requirements, and the degree to which the interface iseasy to use and easy to learn.

User Interface ModelsWhen a user interface is analyzed and designed following four models are used −

User profile model

Created by a user or software engineer, which establishes the profile of the end-users of thesystem based on age, gender, physical abilities, education, motivation, goals, andpersonality.

Considers syntactic and semantic knowledge of the user and classifies users as novices,knowledgeable intermittent, and knowledgeable frequent users.

Design model

Created by a software engineer which incorporates data, architectural, interface, andprocedural representations of the software.

Derived from the analysis model of the requirements and controlled by the information inthe requirements specification which helps in defining the user of the system.

Implementation model

Created by the software implementers who work on look and feel of the interface combinedwith all supporting information books, videos, helpfiles that describes system syntax andsemantics.

Serves as a translation of the design model and attempts to agree with the user's mentalmodel so that users then feel comfortable with the software and use it effectively.

User's mental model

Created by the user when interacting with the application. It contains the image of thesystem that users carry in their heads.

Often called the user's system perception and correctness of the description depends uponthe user’s profile and overall familiarity with the software in the application domain.

Design Considerations of User Interface

User centeredA user interface must be a user-centered product which involves users throughout a product’sdevelopment lifecycle. The prototype of a user interface should be available to users andfeedback from users, should be incorporated into the final product.

Simple and IntuitiveUI provides simplicity and intuitiveness so that it can be used quickly and effectively withoutinstructions. GUI are better than textual UI, as GUI consists of menus, windows, and buttons and isoperated by simply using mouse.

Place Users in ControlDo not force users to complete predefined sequences. Give them options—to cancel or to saveand return to where they left off. Use terms throughout the interface that users can understand,rather than system or developer terms.

Provide users with some indication that an action has been performed, either by showing them theresults of the action, or acknowledging that the action has taken place successfully.

TransparencyUI must be transparent that helps users to feel like they are reaching right through computer anddirectly manipulating the objects they are working with. The interface can be made transparent bygiving users work objects rather than system objects. For example, users should understand thattheir system password must be at least 6 characters, not how many bytes of storage a passwordmust be.

Use progressive disclosureAlways provide easy access to common features and frequently used actions. Hide less commonfeatures and actions and allow users to navigate them. Do not try to put every piece of informationin one main window. Use secondary window for information that is not key information.

ConsistencyUI maintains the consistency within and across product, keep interaction results the same, UIcommands and menus should have the same format, command punctuations should be similarand parameters should be passed to all commands in the same way. UI should not have behavior’sthat can surprise the users and should include the mechanisms that allows users to recover fromtheir mistakes.

IntegrationThe software system should integrate smoothly with other applications such as MS notepad andMS-Office. It can use Clipboard commands directly to perform data interchange.

Component OrientedUI design must be modular and incorporate component oriented architecture so that the design ofUI will have the same requirements as the design of the main body of the software system. Themodules can easily be modified and replaced without affecting of other parts of the system.

CustomizableThe architecture of whole software system incorporates plug-in modules, which allow manydifferent people independently extend the software. It allows individual users to select from

various available forms in order to suit personal preferences and needs.

Reduce Users’ Memory LoadDo not force users to have to remember and repeat what the computer should be doing for them.For example, when filling in online forms, customer names, addresses, and telephone numbersshould be remembered by the system once a user has entered them, or once a customer recordhas been opened.

User interfaces support long-term memory retrieval by providing users with items for them torecognize rather than having to recall information.

SeparationUI must be separated from the logic of the system through its implementation for increasingreusability and maintainability.

ARCHITECTURE TECHNIQUESARCHITECTURE TECHNIQUESIterative & Incremental ApproachIt is an iterative and incremental approach consisting of five main steps that helps to generatecandidate solutions. This candidate solution can further be refined by repeating these steps andfinally create an architecture design that best fits our application. At the end of the process, wecan review and communicate our architecture to all interested parties.

It is just one possible approach. There are many other more formal approaches that defining,reviewing, and communicating your architecture.

Identify Architecture GoalIdentify the architecture goal that forms the architecture and design process. Flawless and definedobjectives emphasize on the architecture, solve the right problems in the design and helps todetermine when the current phase has completed, and ready to move to the next phase.

This step includes the following activities −

Examples of architecture activities include building a prototype to get feedback on the order-processing UI for a Web application, building a customer order-tracking application, and designingthe authentication, and authorization architecture for an application in order to perform a securityreview.

Key ScenariosThis step puts emphasis on the design that matters the most. A scenario is an extensive andcovering description of a user's interaction with the system.

Key scenarios are those that are considered the most important scenarios for the success of yourapplication. It helps to make decisions about the architecture. The goal is to achieve a balanceamong the user, business, and system objectives. For example, user authentication is a key

scenario because they are an intersection of a quality attribute security with important functionality howauserlogsintoyoursystem.

Application OverviewBuild an overview of application, which makes the architecture more touchable, connecting it toreal-world constraints and decisions. It consists of the following activities −

Identify Application Type

Identify application type whether it is a mobile application, a rich client, a rich internet application,a service, a web application, or some combination of these types.

Identify Deployment Constraints

Choose an appropriate deployment topology and resolve conflicts between the application and thetarget infrastructure.

Identify Important Architecture Design Styles

Identify important architecture design styles such as client/server, layered, message-bus, domain-driven design, etc. to improve partitioning and promotes design reuse by providing solutions tofrequently recurring problems. Applications will often use a combination of styles.

Identify the Relevant Technologies

Identify the relevant technologies by considering the type of application we are developing, ourpreferred options for application deployment topology and architectural styles. The choice oftechnologies will also be directed by organization policies, infrastructure limitations, resourceskills, and so on.

Key Issues or Key HotspotsWhile designing an application, hot spots are the zones where mistakes are most often made.Identify key issues based on quality attributes and crosscutting concerns. Potential issues includethe appearance of new technologies and critical business requirements.

Quality attributes are the overall features of your architecture that affect run-time behavior,system design, and user experience. Crosscutting concerns are the features of our design thatmay apply across all layers, components, and tiers.

These are also the areas in which high-impact design mistakes are most often made. Examples ofcrosscutting concerns are authentication and authorization, communication, configurationmanagement, exception management and validation, etc.

Candidate SolutionsAfter defining the key hotspots, build the initial baseline architecture or first high level design andthen start to fill in the details to generate candidate architecture.

Candidate architecture includes the application type, the deployment architecture, thearchitectural style, technology choices, quality attributes, and crosscutting concerns. If thecandidate architecture is an improvement, it can become the baseline from which new candidatearchitectures can be created and tested.

Validate the candidate solution design against the key scenarios and requirements that havealready defined, before iteratively following the cycle and improving the design.

We may use architectural spikes to discover the specific areas of the design or to validate newconcepts. Architectural spikes are a design prototype, which determine the feasibility of a specificdesign path, reduce the risk, and quickly determine the viability of different approaches. Testarchitectural spikes against key scenarios and hotspots.

Architecture ReviewArchitecture review is the most important task in order to reduce the cost of mistakes and to find

and fix architectural problems as early as possible. It is a well-established, cost-effective way ofreducing project costs and the chances of project failure.

Review the architecture frequently at major project milestones, and in response to othersignificant architectural changes.

The main objective of an architecture review is to determine the feasibility of baseline andcandidate architectures, which verify the architecture correctly.

Links the functional requirements and the quality attributes with the proposed technicalsolution. It also helps to identify issues and recognize areas for improvement

Scenario-based evaluations are a dominant method for reviewing an architecture design whichfocuses on the scenarios that are most important from the business perspective, and which havethe greatest impact on the architecture.

Following are common review methodologies −

Software Architecture Analysis Method SAAM − It is originally designed for assessingmodifiability, but later was extended for reviewing architecture with respect to qualityattributes.

Architecture Tradeoff Analysis Method ATAM − It is a polished and improved version ofSAAM, which reviews architectural decisions with respect to the quality attributesrequirements, and how well they satisfy particular quality goals.

Active Design Review ADR − It is best suited for incomplete or in-progress architectures,which more focus on a set of issues or individual sections of the architecture at a time, ratherthan performing a general review.

Active Reviews of Intermediate Designs ARID − It combines the ADR aspect of reviewingin-progress architecture with a focus on a set of issues, and the ATAM and SAAM approach ofscenario-based review focused on quality attributes.

Cost Benefit Analysis Method CBAM − It focuses on analyzing the costs, benefits, andschedule implications of architectural decisions.

Architecture Level Modifiability Analysis ALMA − It estimates the modifiability ofarchitecture for business information systems BIS.

Family Architecture Assessment Method FAAM − It estimates information system familyarchitectures for interoperability and extensibility.

Communicating the Architecture DesignAfter completing the architecture design, we must communicate the design to the otherstakeholders, which include development team, system administrators, operators, businessowners, and other interested parties.

There are several following well-known methods for describing architecture to others: −

4 + 1 ModelThis approach uses five views of the complete architecture. Among them, four views (the logicalview, the process view, the physical view, and the development view) describe thearchitecture from different approaches. A fifth view shows the scenarios and use cases for thesoftware. It allows stakeholders to see the features of the architecture that specifically interestthem.

Architecture Description Language ADLThis approach is used to describe software architecture prior to the system implementation. Itaddresses the following concerns − behavior, protocol, and connector.

The main advantage of ADL is that we can analyze the architecture for completeness, consistency,ambiguity, and performance before formally beginning use of the design.

Agile ModelingThis approach follows the concept that “content is more important than representation.” It ensuresthat the models created are simple and easy to understand, sufficiently accurate, detailed, andconsistent.

Agile model documents target specific customers and fulfill the work efforts of that customer. Thesimplicity of the document ensures that there is active participation of stakeholders in themodeling of the artifact.

IEEE 1471IEEE 1471 is the short name for a standard formally known as ANSI/IEEE 1471-2000,“Recommended Practice for Architecture Description of Software-Intensive Systems.” IEEE 1471enhances the content of an architectural description, in particular, giving specific meaning tocontext, views, and viewpoints.

Unified Modeling Language UMLThis approach represents three views of a system model. The functional requirements view functionalrequirementsofthesystemfromthepointofviewoftheuser, includingusecases; the static structural view objects, attributes, relationships, andoperationsincludingclassdiagrams; and the dynamic behavior view collaborationamongobjectsandchangestotheinternalstateofobjects, includingsequence, activity, andstatediagrams.Processing math: 100%