Unit II

The old way and the new:

The principles of conventional s/w engineering Principles of modern s/w management Transitioning to an iterative process

Life cycle phases:

Engineering and production stages Inception phases Elaboration phases Construction phases Transition phases

Unit II

Artifacts of the process:

The

artifacts sets Management artifacts Engineering artifacts Programmatic artifacts

Model based s/w architectures:

A

management perspective A technical perspective

The Principles of Conventional Software Engineering

Make quality #1.

Quality must be quantified and mechanism put into place to motivate its achievement.
Techniques that have been demonstrated to increase quality include involving the customer, prototyping, simplifying design, conducting inspections, and hiring the best people. No matter how hard you try to learn users needs during the requirements phase, the most effective way to determine real needs is to give users a product and let them play with it.

High-quality software is possible.

Give products to customers early.

The Principles of Conventional Software Engineering

Determine the problem before writing the requirements.

When faced with what they believe is a problem, most engineers rush to offer a solution. Before you try to solve a problem, be sure to explore all the alternatives and dont be blinded by the obvious solution. After the requirements are agreed upon, you must examine a variety of architectures and algorithms. You certainly do not want to use an architecture simply because it was used in the requirements specification.

Evaluate design alternatives.

The Principles of Conventional Software Engineering

Use an appropriate process model.

Each project must select a process that makes the most sense for that project on the basis of corporate culture, willingness to take risks, application area, volatility of requirements, and the extent to which requirements are well understood.
Our industrys eternal thirst for simple solutions to complex problems has driven many to declare that the best development method is one that uses the same notation through-out the life cycle. Why should software engineers use Ada for requirements, design, and code unless Ada were optimal for all these phases

Use different languages for different phases.

The Principles of Conventional Software Engineering

Minimize intellectual distance.

To minimize intellectual distance, the softwares structure should be as close as possible to the realworld structure.
An undisciplined software engineer with a tool becomes a dangerous, undisciplined software engineer. It is far easier to make a working program run than it is to make a fast program work. Dont worry about optimization during initial coding.

Put techniques before tools.

Get it right before you make it faster.

The Principles of Conventional Software Engineering

Inspect code.

Inspecting the detailed design and code is a much better way to find errors than testing.

Good management is more important than good technology.

The best technology will not compensate for poor management, and a good manager can produce great results even with meager resources. Good management motivates people to do their best, but there are no universal right styles of management.

The Principles of Conventional Software Engineering

People are the key to success.

Highly skilled people with appropriate experience, talent, and training are key. The right people with insufficient tools, languages, and process will succeed. The wrong people with appropriate tools, languages, and process will probably fail.
Just because everybody is doing something does not make it right for you. It may be right, but you must carefully assess its applicability to your environment. Object orientation, measurement, reuse, process improvement, CASE, prototyping-all these might increase quality, decrease cost, and increase user satisfaction. The potential of such techniques is often oversold, and benefits are by no means guaranteed or universal.

Follow with care.

The Principles of Conventional Software Engineering

Take responsibility.

When a bridge collapses we ask, what did the engineers do wrong? Even when software fails, we rarely ask this. The fact is that in any engineering discipline, the best methods can be used to produce awful designs, and the most antiquated methods to produce elegant design.
It is possible the customer would tolerate 90% of the functionality delivered late if they could have 10% of it on time. The more functionality (or performance) you provide a user, the more functionality (or performance) the user wants.

Understand the customers priorities.

The more they see, the more they need.

The Principles of Conventional Software Engineering

Plan to throw one away.

One of the most important critical success factors is whether or not a product is entirely new. Such brand-new applications, architectures, interfaces, or algorithms rarely work the first time.
The architectures, components, and specification techniques you use must accommodate change. I have often heard software engineers say, I have finished the design. All that is left is the documentation.

Design for change.

Design without documentation is not design.

The Principles of Conventional Software Engineering

Use tools, but be realistic.

Software tools make their users more efficient.

Many programmers love to create programs with tricksconstructs that perform a function correctly, but in an obscure way. Show the world how smart you are by avoiding tricky code. Information-hiding is a simple, proven concept that results in software that is easier to test and much easier to maintain. Coupling and cohesion are the best ways to measure softwares inherent maintainability and adaptability.

Avoid tricks.

Encapsulate.

Use coupling and cohesion.

The Principles of Conventional Software Engineering

Use the McCabe complexity measure.

Although there are many metrics available to report the inherent complexity of software, none is as intuitive and easy to use as Tom McCabes.
Software developers should never be the primary testers of their own software.

Dont test your own software.

Analyze causes for errors.

It is far more cost-effective to reduce the effect of an error by preventing it than it is to find and fix it. One way to do this is to analyze the causes of errors as they are detected.

The Principles of Conventional Software Engineering

Realize that softwares entropy increases.

Any software system that undergoes continuous change will grow in complexity and become more and more disorganized.
Measuring a project solely by person-months makes little sense. Your employees will do much better if you have high expectations for them.

People and time are not interchangeable.

Expert excellence.

The Principles of Modern Software Management

Base the process on an architecture-first approach: central design element.

Design and integration first, then production and test

Establish an iterative life-cycle process: the risk management element.

Risk control through ever-increasing function, performance, quality

Transition design methods to emphasize component-based development: the technology element

Object-oriented methods, rigorous notations, visual modeling

Establish a change management environment: the control element.

Metrics, trends, process instrumentation

Enhance change freedom through tools that

The Principles of Modern Software Management

Capture design artifacts in rigorous, model based notation

A model-based approach supports the evolution of semantically rich graphical and textual design notations,

Instrument the process for objective quality control and progress assessment

Life-cycle assessment of the progress and quality of all intermediate product must be integrated into the process.

Use a demonstration-based approach to assess intermediate artifacts

Transitioning from whether the artifact is an early prototype or baseline architecture into an executable demonstration of relevant provides more tangible understanding of the design tradeoffs, early integration and earlier elimination of architectural defects.

The Principles of Modern Software Management

Plan intermediate releases in groups of usage scenarios with evolving levels of detail
It

is essential that s/w management process drive toward continuous demonstrations within the operational context of the system.

Establish a configurable process that economically scalable

No

single process is suitable for all s/w developments. The process must ensure that there is economy of scale and ROI (Return On Interest)

The Most important five Principles of Modern Software Management

Architecture-first approach

The central design element

Iterative life-cycle process

The risk management element The technology element

Component-based development

Change management environment

The control element

Round-trip engineering

The automation element

The old way waterfall model

Waterfall process includes the following step of execution:

Requirement

first Custom development Avoidance of change Adhoc tools.

Requiremen ts Analysis Design

Coding
Testing Maintenanc e

The New way Iterative Process

Iterative process includes the following step of execution:

Architecture

first. Component-based development. Change management. Round-trip engineering.

The New way Iterative Process and resolve 2. Indentify

Progress 1. Determine objectives risks Risk analysi s

Requiremen ts plan

Review

Risk Operational analysi prototype Concept Prototype s of Prototype 2 Concept of operation 1 Detailed Requiremen requiremen design ts ts Developmen Verification t plan Cod & validation e Test plan Verification Integration & validation Release Test implementatio n

Risk analysi s

Modern process approach for solving conventional problems Risk involved Impact Resolution risk
1. Late breakage and excessive scarp
2. Attrition of key personnel 3. Inadequate development resources 4. Adversarial stakeholder 5. Necessary technology insertion

Quality, cost and schedule

Quality, cost and schedule Cost and schedule Cost and schedule Cost and schedule

Risk confronting process

Early iteration Round-trip engineering Demonstration based overview Architecture-first approach Component-based approach Iterative development Use case modeling

6. Requirement creep

Cost and schedule

7. Analysis paralysis
8. Inadequate performance

Schedule
Quality

Demonstration based review

Demonstration based performance assessment

Transitioning to an iterative process

In the conventional waterfall model, each stage of the development process is dependent on completion of the previous stage. Modern approaches generally require that an initial version of the system be rapidly constructed early in the development process, with an emphasis on addressing the high risk areas, stabilizing the basic architecture, and refining the driving requirements. s/w development then proceeds as a series of iterations, building on the core architecture until the desired levels of functionality, performance and robustness is achieved. A benchmark of the expected benefits of process improvement can be obtained from the process

Transitioning to an iterative process

These exponent parameters of COCOMO II model are:

Application

predictedness Process flexibility Architecture risk resolution Team cohesion s/w process maturity

Life-Cycle Phases

Life-Cycle Phases
Engineering

and Production Stages Inception Phase Elaboration Phase Construction Phase Transition Phase

Life-Cycle Phases

Two stages of the life-cycle :

engineering stage driven by smaller teams doing design and synthesis activities The production stage driven by larger teams doing construction, test, and deployment activities
The

LIFE-CYCLE ASPECT Risk reduction

ENGINEERING STAGE EMPHASIS Schedule, technical feasibility

PRODUCTION STAGE EMPHASIS Cost

Products
Activities Assessment Economics Management

Architecture baseline
Analysis, design, planning Demonstration, inspection, analysis Resolving diseconomies of scale Planning

Product release baselines

Implementation, testing Testing Exploiting economics of scale Operations

Life-Cycle Phases

The four phases of lifecycle process are loosely mapped to the conceptu Framework of the spiral model is as shown in the following figure.
Engineering Stage
Inception Elaboration

Production Stage
Construction Transition

Idea

Architecture

Beta Releases

Products

Life-Cycle Phases

Inception Phase
Overriding goal to achieve concurrence among stakeholders on the life-cycle objectives Essential activities :

Formulating the scope of the project (capturing the requirements and operational concept in an information repository) Synthesizing the architecture (design trade-offs, problem space ambiguities, and available solution-space assets are evaluated) Planning and preparing a business case (alternatives for risk management, iteration planes, and cost/schedule/profitability trade-offs are evaluated)

Life-Cycle Phases

Elaboration Phase
During

the elaboration phase, an executable architecture prototype is built Essential activities :

Elaborating

the vision (establishing a high-fidelity understanding of the critical use cases that drive architectural or planning decisions) Elaborating the process and infrastructure (establishing the construction process, the tools and process automation support) Elaborating the architecture and selecting components (lessons learned from these activities may result in redesign of the architecture)

Life-Cycle Phases

Construction Phase
During the
All

construction phase :

remaining components and application features are integrated into the application. All features are thoroughly tested
Essential

activities :

Resource

management, control, and process optimization Complete component development and testing against evaluation criteria Assessment of the product releases against acceptance criteria of the vision

Life-Cycle Phases

Transition Phase
The transition phase is entered when baseline is mature enough to be deployed in the end-user domain This phase could include beta testing, conversion of operational databases, and training of users and maintainers Essential activities :

Synchronization and integration of concurrent construction into consistent deployment baselines Deployment-specific engineering (commercial packaging and production, field personnel training) Assessment of deployment baselines against the complete vision and acceptance criteria in the requirements set

Life-Cycle Phases

Evaluation Criteria :
Is the user satisfied? Are actual resource expenditures versus planned expenditures acceptable?

Each of the four phases consists of one or more iterations in which some technical capability is produced in demonstrable form and assessed against a set of the criteria The transition from one phase to the nest maps more to a significant business decision than to the completion of specific software activity.

Artifacts of the Process

Conventional s/w projects are focused on the sequential development of s/w artifacts(interrelated information).
Build the requirements Construct a design model traceable to the requirements Build an implementation traceable to the design model Compile and test the implementation for deployment

This process can work for small-scale, purely custom developments in which the design representation, implementation representation and deployment representation are closely aligned. This approach doesnt work for most of todays

Artifacts of the Process

In order to manage the development of a complete s/w system, distinct collections of information and is organized into artifact sets. Set represent a complete aspect of the system where as artifact represents interrelated information that is developed and reviewed as a single entry. The artifacts of the process are organized into 5 sets:
Management set Requirement set Design set Implementation set

Engineering set

Artifacts of the Process

Engineering Set

Requirements Set
1.Vision document 2.Requirements model(s)

Design Set
1.Design model(s) 2.Test model 3.Software architecture description

Implementation Set
1.Source code baselines 2.Associated compiletime files 3.Component executables

Deployment Set
1.Integrated product executable baselines 2.Associated run-time files 3.User manual

Management Set Planning Artifacts

1.Work breakdown structure 2.Bussines case 3.Release specifications 4.Software development plan

Operational Artifacts
5.Release descriptions 6.Status assessments 7.Software change order database 8.Deployment documents 9.Enviorement

The Management Set:

It captures the artifacts associated with process planning and execution. These artifacts use ad hoc notation including text, graphics, or whatever representation is required to capture the contracts among project personnel (project manager, architects, developers, testers, marketers, administrators), stakeholders (funding authority, user, s/w project manager, organization manager). Management artifacts are evaluated, assessed and measured through a combination of following:

Relevant stakeholder review. Analysis of changes between the current version of the artifacts and previous versions. Major milestone demonstrations of the balance among all artifacts.

The Engineering Sets

The primary mechanism for evaluating the evolving quality of each artifact is the transitioning of information from set to set, thereby maintaining a balance of understanding among the following sets:
Requirement Design

set

set Implementation set Deployment set

The Engineering Sets

Requirement set:
The requirement set is the primary engineering context for evaluating the other three engineering artifact sets and is the basis for test cases. Requirements artifacts are evaluated, assessed, and measured through a combination of the following:

Analysis of consistency with the release specifications of the management set. Analysis of consistency between the vision and the requirements models. Mapping against the design, implementation, and deployment sets to evaluate the consistency and completeness and the semantic balance between information in the different sets. Analysis of changes between the current version of requirements artifacts and previous versions. Subjective review of other dimensions of quality.

The Engineering Sets

Design set:

UML notations are used to engineer the design models for the solutions. The design set contains varying levels abstraction and enough structural and behavioral information to determine a bill of materials. The design model information can be clearly and in many cases, automatically translated into a subset of the implementation and deployment set artifacts. The design set are evaluated, assessed, and measured through a combination of the following:

Analysis of the internal consistency and quality of the design model. Analysis of consistency with the requirements models. Translation into implementation and deployment sets and notations to evaluate the consistency and completeness and semantic balance between information in the sets. Analysis of changes between the current and previous versions of the design model.

The Engineering Sets

Implementation set:

The implementation set include source code that represents the tangible implementations of components and any executables necessary for stand-alone testing of components. Executables are the primitive parts that are needed to construct the end product, including custom components, application programming interfaces (APIs) of commercial components. Implementation set artifacts can also be translated into a subset of the deployment set. Requirements artifacts are evaluated, assessed, and measured through a combination of the following:

Analysis of consistency with the design models. Translation into deployment set notations. Assessment of component source or executable files against relevant evaluation criteria through inspection, analysis, demonstration, or testing. Execution of stand alone component test cases that automatically compare expected results with actual results. Analysis of changes between the current version of the implementation set and previous versions. Subjective review of other dimensions of quality.

The Engineering Sets

Deployment Set:

The deployment set includes user deliverables and machine language notations, executable s/w and the build scripts, installation scripts, and executable target specific data necessary to use the product in its target environment. Deployment sets are evaluated, assessed, and measured through a combination of the following:

Testing against the usage scenarios and quality attributes defined in the requirements set to evaluate the consistency and completeness and the semantic balance between information in the two sets. Testing the partitioning, replication, and allocation strategies in mapping components of the implementation set to physical resources of the deployment system. Testing against the defined usage scenarios in the user manual such as installation, user oriented dynamic reconfiguration, mainstream usage and anomaly management. Analysis of changes between the current version and the previous versions Subjective review of the other dimensions of quality.

Artifacts of the Process

Each artifact set uses different notations to capture the relevant artifacts. Management set notations (ad hoc text, graphics, use case notation)

Captures the plans, process, objectives and acceptance criteria.

Requirements notations (structured text and UML models)

Capture the engineering context and the operational concept. Capture the engineering blueprints (architectural design, component design).

Design notations (in UML)

Implementation notations (s/w languages)

Capture the building blocks of the solution in human readable formats.

Artifacts of the Process

Each artifact set is the predominant development of one phase of the life cycle while the other sets take on check and balance roles. Requirements are the focus of the inception phase. Design are the focus of the elaboration phase. Implementation are the focus of the construction phase. Deployment are the focus of the transition phase. Management artifacts are constant level across the life cycle.

Lifecycle focus on artifact sets

Inception Elaboration Construction Transition

Management

Requirement s

Desig n Implementati on

Deployment

Implementation Set Vs Deployment Set

The separation of the implementation set (source code) from the deployment set (executable code) are very different concerns with each set. The structure of the information delivered to the user (testing people) is very different from the structure of the source code implementation. Engineering decisions have impact on the quality of the deployment set but are unclear in the design and implementation sets. That includes:

Implementation Set Vs Deployment Set

Dynamically reconfigurable parameters such as buffer sizes, color palettes, number of servers, number of simultaneous clients, data files, run-time parameters. Effects of compiler/link optimizations such as space optimization versus speed optimization. Performance under certain allocation strategies such as centralized versus distributed, primary and shadow threads, dynamic load balancing. Virtual machine constraints like file descriptors, garbage collection, heap size, maximum record size, disk file rotations. Process-level concurrency issues such as deadlock and race conditions

Artifact Evolution over the Life Cycle

Each state of development represents a certain amount of precision in the final system description. Early in the lifecycle, precision is low and the representation is generally high. At any point in the lifecycle, the five sets will be in different states of completeness. They should be at compatible levels of detail and reasonably traceable to one another. Performing detailed traceability and consistency analyses early in the life cycle i.e. when precision is low and changes are

Artifact Evolution over the Life Cycle

Each phase of development focuses on a particular artifact set. At the end of each phase, the overall system state will have progressed on all sets, as shown in the fig.
Engineering Stage Inception Elaboration Production Stage Construction Transition

implementatio n Deployment

implementatio n Deployment

implementatio n Deployment

Manageme nt

Manageme nt

Manageme nt

Management

Design Implementatio n Deployment

Requirements

Requiremen ts Design

Requiremen ts Design

Requiremen ts Design

Artifact Evolution over the Life Cycle

Inception phase:
It

mainly focuses on critical requirements, usually with a secondary focus on an initial deployment view, little implementation and high-level focus on the design architecture but not on design detail.

Elaboration phase:
It

include generation of an executable prototype, involves subsets of development in all four sets. A portion of all four sets must be evolved to some level of completion before an architecture baseline can be established.

Artifact Evolution over the Life Cycle

Construction phase:

Its main focus on design and implementation. In early stage, the main focus is on the depth of the design artifacts, later in construction, realizing the design in source code and individually tested components. This stage should drive the requirements, design, and implementation sets almost to completion. Substantial work is also done on the deployment set, at least to test one or a few instances of the programmed system through alpha or beta releases.
The main focus is on achieving consistency and completeness of the deployment set in the context of another set. Residual defects are resolved, and feedback from alpha, beta and system testing is incorporated.

Transition phase:

Management Artifacts
The management set includes several artifacts :

Work Breakdown Structure

A WBS is the means of budgeting and collecting costs. The software project manager must have insight into project costs and how they are expended. The project manager must monitor and control a projects financial performance in terms of cost accountability and stability at the levels of the the structure to be achieved. If the WBS is structured improperly, it can drive the

Management Artifacts

Business Case

It provides all the information necessary to determine whether the project is worth investing in. It details the expected revenue, expected cost, technical and management plans and backup data necessary to demonstrate the risk and realism of the plan. The main purpose is to transform the vision into economic value for an accurate ROI
I. II. Context i.e. domain, market, scope Technical approach A. Feature set achievement plan B. Quality achievement plan C. Engineering trade-offs and technical risks. III. Management approach A. Schedule and risk management B. Objective measure of success IV. Evolutionary appendixes A. Cost estimate B. Revenue estimate C. Bases of estimates

Management Artifacts

Release Specifications: Typical release specification outline :

I. II. Iteration content Measurable objectives A. Evaluation criteria B. Follow-through approach III. Demonstration plan A. Schedule of activities B. Team responsibilities IV. Operational scenarios (use cases demonstrated) A. Demonstration procedures B. Traceability to vision and business case

Two important forms of requirements:

Vision statement (or user need) - which captures the contract between the development group and the buyer. Evaluation criteria defined as management-oriented requirements, which may be represented by use cases, use case realizations or structured text

Management Artifacts

Software Development Plan

is the defining document for the projects process. It must comply with the contract, comply with the organization standards, evolve along with the design and requirements.
It

Release Descriptions
The

description of the results of each including performance against each evaluation criteria in the corresponding specification is detailed in the descriptions.

release of the release release

Management Artifacts

Status Assessments

It provides periodic snapshots of project status, including s/w project managers risk assessment such as review of resources, personnel staffing, financial data, technical progress, milestone plans and results, project scope and follow-through, quality indicator and management indicators. The objective is to satisfy the expectations of all the stakeholders consistently.
The fundamental primitive of an iterative development process is managing change because of which the productivity of a project increases. The change management data have been elevated to firstclass management artifacts need automation.

Software change order database

Management Artifacts

Deployment
Depending on the project it could include several document subsets for transitioning the product into operational status. It could also include computer system operations manuals, software installation manuals, plans and procedures for cutover etc.

Environment
A robust development environment must support automation of the development process. It should include:

requirements management visual modeling Document automation

Engineering Artifacts

In general review, there are three engineering artifacts : Vision document:

It supports the contract between the funding authority and the development organization. It is written from the users perspective, focusing on the essential features of the system. It should contain at least two appendixes :

the first appendix should describe the operational concept using use cases, the second should describe the change risks inherent in the vision statement.

Architecture Description :

it is extracted from the design model and includes views of the design, implementation, and deployment sets sufficient to

Engineering Artifacts

I.

Typical architecture description outline :

III.

II.

Architecture overview A. Objectives B. Constraints C. Freedoms Architecture views A. Design view B. Process view C. Component view D. Deployment view

Architectural interactions A. Operational concept under primary scenarios B. Operational concept under secondary scenario C. Operational concept under anomalous scenari Architecture performance Rationale, trade-offs, and other substantiation

IV. IV.

Engineering Artifacts

Software User Manual:

It

should include installation procedures, usage procedures and guidance, operational constraints, and a user interface description. It should be written by members of the test team, who are more likely to understand the users perspective than the development team. It also provides a necessary basis for test plans and test cases, and for construction of automated test suites.

Pragmatic artifacts

An effective approach that encourage on-line review of information by using smart browsing and navigation tools are called as pragmatic artifacts. This approach can eliminate huge, unproductive sources of scrap later on and provides continuous review, not periodic review. The issues raised by this approach are as follows:

People want to review information but dont understand the language of the artifact People want to review the info but dont have access to the tools. Human-readable engineering artifacts should use rigorous notations that are complete, consistence and used in a self documenting manner. Useful documentation is self-defining. It is documentation that gets used.

Model-Based Software Architectures

Software architecture is the central design problem in complex s/w system with complexity. The ultimate goal of the engineering stage is to converge on a stable architecture baseline. It is a collection of information across all the engineering sets. Architectures are described by extracting the essential information from the design models. A model is relatively independent abstraction of a system. A view is a subset of a model that abstracts a specific relevant perspective. The s/w architectures has two perspectives:

A Management Perspective A Technical Perspective

A Management Perspective

From a management perspective, there are three different aspects of an architecture :

An architecture (the intangible design concept) is the design of software system, as opposed to design of a component. An architecture baseline (the tangible artifacts) is a slice of information across the engineering artifact sets sufficient to satisfy all stakeholders that the vision can be achieved within the parameters of the business case (cost, profit, time, people). An architecture description (a human-readable representation of an architecture) is an organizes subsets of information extracted from the design set

A Management Perspective

The importance of software architecture can be summarized as follows:

Architecture representations provide a basis for balancing the trade-offs between the problem space and the solution space. Poor architectures and immature processes are often given as reasons for project failures. A mature process, an understanding of the primary requirements, and a demonstrable architecture are important prerequisites for predictable planning. Architecture development and process definition are the intellectual steps that map the problem to a solution without violating the constraints.

A Technical Perspective

S/w architecture includes the structure of s/w systems, their behavior, and the patterns that guide these elements, their collaborations, and their composition. An architecture framework is defined in terms of views is the abstraction of the UML models in the design set, where as architecture view is an abstraction of the design model, include full breadth and depth of information.

A Technical Perspective

Most of the real-world systems require four types of views:

Design: describes architecturally significant structures and functions of the design model. Process: describes concurrency and control thread relationships among the design, component and deployment view. Component: describes the structure of the implementation set. Deployment: describes the structure of the deployment set.

The design view is almost necessary in every system where as the other 4 views can be added to work with the complexity of the system at hand. The following figure summarizes the artifacts of design

A Technical Perspective
Requiremen t Design implementati on Deployment The requirement set may include UML models for problem space
The design set includes all UML designs models describing the solution space The design, Process and Use case models provides a visualization of the logical and behavioral aspects of the design. The component model provides a visualization of the implementation set. The deployment model provides a visualization of the deployment set.

Design complexity identifies different models

Use Case Model

Design Model

Process Model

Component Model

Deployment Model

A Technical Perspective
Architecture Description Document

An architecture is described through several views, which are extracts of design models that capture the significant structures, collaborations, and behaviors.

Design view Process view Use case view Component view Deployment view Other views (optional)

Use Case View

Design View

Process View

Component View

Deployment View

Architecture, an organized and abstracted view into the design models

A Technical Perspective

The use case view describes how the systems critical use cases are realized by elements of the design model. It is modeled statically using case diagrams, and dynamically using any of the UML behavioral diagrams. The design view addresses the basic structure and the functionality of the solution. The process view addresses the run-time collaboration issues involved in executing the architecture on a distributed deployment model, including the logical software network topology, inter process communication and state management. The component view describes the architecturally significant elements of the implementation set and addresses the software source code realization of the system from perspective of the project's integrators and developers. The deployment view addresses the executable realization of the system, including the allocation of logical processes in the distribution view to physical resources of the