santoshspoudel: UML

Chapter 7

Model-Based software Architectures

Introductory Comments

❑ Software Architecture - essential to building software systems, as is ALL architecture.

■ When we speak about Architecture (not software)

❑ can apply stable laws of physics and mathematics.

■ Software Architecture

❑ not governed by complete laws of math;

❑ no irrefutable first principles.

❑ At best, many heuristics and vague guidelines

❑ Goodness measurable only in certain situations

Introductory Comments

❑So, what do practitioners do??

❑ With no established theory, software architects must rely on experiences and trial and error in formulating software architectures.

❑ We recognize that the transition to an iterative process, where the early stages emphasize and promote architecture through evolution through prototyping and demonstration has proven to be the way to proceed.

Introductory Comments

❑ Years ago, early systems had a very simple architecture. had informal software architectures.

■ Block diagrams; Hierarchy charts; Structure charts; IPO charts; Many tools at the detail level - for program design; not much at the architectural level...

❑ Nowadays, with the complexity of modern systems, we have many models and views to explain the many viewpoints of many different perspectives of modern software development.

■ Need to show higher level views from different perspectives of different stakeholders - since there are now so many.

❑ "A 'model' is a relatively independent abstraction of a system. A view is a subset of a model that abstracts a specific, relevant perspective.

Architecture: A Management Perspective

❑ The most critical technical product of a software project is its architecture: the infrastructure, control, and data interfaces that permit software components to cooperate as a system and software designers to cooperate efficiently as a team."

❑ With the complexity of modern systems, a basis of communications is essential, and 'inter-project communications' (different groups; different viewpoints) must be established and precise.

Management Perspective

❑ Three different aspects of an architecture:

❑ 1. An architecture - that is, the design of a software system as opposed to a component. (intangible design concept)

■ Includes all engineering necessary to specify the materials needed (buy, reuse, custom, costs of construction...)

❑ 2. An architecture baseline - (tangible artifacts) - a slice of information across engineering artifacts sufficient to satisfy all stakeholders that the vision (function and quality) can be achieved with in the parameters of the business case (cost, profit, time, people, technology, ...)

■ Note: an architecture baseline contains more than just an architecture description.

Management Perspective

❑ 3. An architecture description - human-readable representation of the architecture, which is one of the components of an architecture baseline.

■ Is an organized subset of information extracted from the design set model(s).

■ More detailed; 'contains additional info in the models.

■ Indicates how the intangible concept is realized via the tangible artifacts.

❑ Note that architecture takes on different meanings in different domains!

❑ Levels of granularity can vary widely and depend largely on what is needed by stakeholders at that 'level' and what concerns they need to resolve.

Importance of Software Architecture

❑ “Achieving a stable architecture represents a significant Project milestone at which the critical make/buy decisions should have been resolved. This life-cycle event represents a transition from the engineering stage of a project, characterized by discovery and resolution of numerous unknowns, to the production stage, characterized by management to a predictable development plan."

❑ Architecture and process encapsulate many of the important (high payoff or high risk) communications among individuals, teams, organizations and stakeholders.

Importance of Software Architecture

❑ Poorly conceived architectures (and hence poor inter-process communications) and a process that is not a mature one (not well defined, taught, supported by management, and implemented by development teams, especially with established histories...) are often reasons for project failure.

❑ A process that is mature, a good understanding of all the primary requirements, and the development of an architecture that is demonstratable are essential requirements predictable planning - fundamental to management.

❑ Architecture development and process definition are the jntellectual steps that man the problem to a solution without violating the constraints; they require human intervention and cannot be automated.

Architecture: A Technical Perspective.

❑ Although progress has been made, there is still a lack of agreement on definitions and principles.

❑ From Kruchten:

❑ "Software architecture encompasses the structure of software systems (the selection of elements and the composition of elements into progressively larger subsystems), their behavior (collaborations among elements), and the patterns that guide these elements, their collaborations, and their composition." (underlining and bold is mine).

❑ An architectural framework is defined in terms of views that are abstractions of the UML models in the design set.

■ (Think of the 4+1 Architectural View of the RUP)

❑ The Design Model includes the full breadth and depth of information.

❑ An architectural view (again, think of the five in the 4+1 architectural views of RUP) is an abstraction of the design model;

■ That is, a higher-evel view of more detailed artifacts/activities...

■ it contains only the architecturally significant information.

❑ Most real-world systems require four views:

■ Design, process, component, and deployment.

❑ RUP added the Use Case View as 'driving' all the views and overall architecture.

■ Let's look at the purposes of these views...

Models and Views — again

❑ To keep our terminology straight:

❑ A 'model' is a relatively independent abstraction of a system. (We can thus develop models - in general depicting / describing whatever it is we need to describe.) BUT a VIEW:

❑ A view is a subset of a model that abstracts a specific, relevant perspective.

❑ Remember, a view is developed to support a specific viewpoint or perspective or to support certain needs that certain groups of stakeholder have.

■ As stated, it is a tailored subset of a model - to capture a relevant perspective.

■ We have logical views, component views, deployment views,...

Views and their Purposes

❑ Design View (logical view in RUP) describes the architecturally significant structures and functions of the design model.

❑ Process View: describes concurrency and control thread relationships among the design, component, and deployment views.

❑ Component View: describes the structure of the implementation set (Implementation View in RUP)

❑ Deployment View: describes the structure of the deployment set.

❑ Recall: each of these views is developed to support certain needs of stakeholders.

■ Design View (logical view in RUP) is developed to support analysts, programmers, architects, etc. Component View (Implementation View in RUP) is developed to support construction (programming and test) etc.

The Necessity of Views

❑ Design view is clearly essential. All systems need this view.

■ Others are needed as necessary...

■ Distributed systems need a process view and a deployment view;

■ Large systems that might have custom and commercial components probably also need a component view.

The Design Set

❑ The design set will include all UML design models describing the solution space. (Big Cookie!!) ❑ Depending on the complexity of a system itself, several models or partitions of other models (views) may need to be developed.

■ Use case, design (logical), and process models provide for visualization of the logical and behavioral aspects of the system.

■ Component view provides visualization of the implementation set; deployment model provides visualization of the deployment set.

The Design Set

❑ Note that 'architecture: is an organized and abstracted view into design models.....

❑ An architecture is captured through many views, which are extracts of design models and capture the significant structures, collaborations, and behaviors.

❑ The architectural description, then, of a system is captured via portions of each model;

■ Part of the design model (design view) addresses architecture;

■ Part of the process model (process view) addresses architecture (as needed)

■ Part of the component model (implementation view) is part of the architectural view, etc.

■The views are extracts of design models that capture significant structures, collaborations, and behaviors.

Architecture

❑ The architectural descriptions are always kept electronically, but also maintained in a printable version. These engineering and architectural views are defined as collections of UML diagrams unlike text and basic graphics models of years past.

❑ (Be careful: management may still want these. Educate them where possible...)

Architecture - Many Faces

❑ Descriptions of architecture is many things to many people in different application domains. ❑ And, these take on many different forms.

❑ Ideally, they can remain electronic, but ...

❑ So, given all this, and recognizing that the descriptions can vary a great deal, what constitutes a good architecture baseline?

■ That is, what is a good 'critical mass' of models / views in general?

■ Remember, we are after content that is architecturally-significant....

Heuristics for an Architectural Baseline

❑ "Requirements: critical use cases, system-level quality objectives, and priority relationships among features and qualities.

❑ "Design: names, attributes, structures, behaviors, groupings, and relationships of significant classes and components.

❑ "Implementation: source component inventory and bill of materials (number name, purpose, cost) of all primitive components

❑ "Deployment: executable components sufficient to demonstrate the critical use cases and the risk associated with achieving the system qualities."

Architectural Baseline - Comments

❑ Project success is often dependent upon a architectural description in an architectural-first approach (like RUP).

❑ Essential to the question of 'balance.'

■ (what is 'in' the architecture and what is not)

■ Key word: 'balance:

❑ Note that the architectural baseline is a subset of the architectural description, which is totally contained in the Design Set.

The Old and the New

❑Conventional systems did not distinguish between the two (architectural description and architectural baseline)

■ No rigorous notations (normally block diagrams and text)

■ Little tie in to other engineering artifact sets for validation

❑ Iterative development - an "architecture baseline is a partial realization of the architecture description that is sufficient to provide tangible evidence that the architecture is valid in the context of the requirements and plans."

❑ This is, thus, the major 'deliverable' of the Elaboration phase, and hopefully we can readily see why this is so.

Architectural Baseline

❑ Degree of detail and forms depends many factors.

❑ Very skilled people developing a limited application may need only UML diagrams whereas a command-and-control system that is large scale and highly distributed will clearly require more details to validate a solid baseline!

Concluding Remarks

❑ Note that the transition from engineering into production should not take place unless a stable architecture baseline is established.

❑ Thus relevant stakeholders must agree that the original vi ion (supported by the requirements and and architecture) and represented in the design set and partially implemented in the implementation and deployment sets) can be achieved with a highly predictable cost and schedule.

❑ Verification requires briefings and executable prototypes that demonstrate the evolving capabilities.
❑ These will show the maturity of the process.

Chapter 8

Workflows of the Process

Overview

❑ Introduction

❑ Software Process Workflows

❑ Iteration Workflows

Introduction

❑We like sequential activities.

§ ❑ We basically perform activities sequentially because it is easy to understand, plan and proceed.

§ In Teams must operate in parallel.

❑ Requires synchronization, cross-checking, homogenized, merged, and integrated

■ Managing these workflows is a primary source of management complexity.

Old Way for Tracking Workflow: Sequential Activities

❑In the past, projects 'progressed' via sequential progress through fixed activities (requirement, design, coding, testing etc).

❑ Successful projects-had boundaries not rigid; non-adversarial stakeholders.

❑ Unsuccessful projects had rigid boundaries. All activities had to be completed before pressing on.

§ Much work spent on details (such as completing- a manual...) while slighting important development t. engineering activities.

New Way for Tracking Workflow: State of the Project

We now avoid naming life-cycle phases after the predominant activities.

Now we track the 'state' of development within phases (inception, elaboration, construction, transition), recognizing that activities and artifacts evolve and eventually become stable.

❑ avoiding a discrete set of lock-step activities and cut-off / due dates.

O The 'state' of a project can be tracked via the minor milestones (end of each iteration).

Software Process Workflows

❑ We have spoken about fundamental sets of artifacts and the phases in which they are largely produced - recognizing the evolution of these artifacts.

❑We now need to look inside the phases and the iterations - micro-level.

❑Interestingly, within these boundaries, we will use the term workflow, and talk about a thread of cohesive activities that are mostly sequential.

❑ The-Workflows will be mapped to the product artifacts and to the teams.

❑So, let's look at high-level workflows.

Activity Levels across the life cycle phases (1 of 7)

Management workflow

■ Level of Activities; Has a reasonably constant level of activity.

§ Artifacts include

❑ Business Case

❑ Software Development Plan

❑ Status assessments

❑ Vision

❑ Work Breakdown structure

■ Life Cycle Phase Emphasis

❑ Inception - prepare business case and vision

❑ Elaboration - Plan development

❑ Construction - Monitor and control development

❑ Transition - Monitor and control deployment

Activity Levels across the life cycle phases (2 of 7)

Environment workflow

❑ Level of Activities: Reasonably medium level activity in inception; quite low in Construction and Transition (should already be well established and operational); high level of activity in Elaboration, development environment and change management database are obtained, installed and configured for use.

■A robust Environment is essential.

❑ Artifacts

■ Environment

■ Software Change Order database

❑ Life Cycle Phase Emphasis

■ Inception - define development environment and change mgmt infrastructure

§ Elaboration - install development environment; establish change mgmt database

§ Construction - maintain development environment; maintain software change order database

§ Transition - Transition maintenance environment and software change ' order database.

Activity Levels across the life cycle phases (3 of 7)

Requirements workflow

Level of Activities: (analyzing problem space and evolving requirement) Very low level (does not mean NO activity...) in construction and transition. Higher level in Inception, especially toward the end of Inception. In fact, activities of Requirements effort are highest at the end of inception and the start of Elaboration and continuing at a high (but lower) level in Elaboration.

❑ Artifacts:

■ Requirements set

■ Release Specifications

■ Vision Documents

❑ Life Cycle Phase Emphasis

■ Inception - define operational concept

■ Elaboration - Define architecture objectives

■ Construction - Define iteration objectives

■ Transition - refine release objectives.

Activity Levels across the life cycle phases (4 of 7)

Design workflow

❑ Levels of activities - (model the solution and evolving the architecture and design artifacts)

▪ Builds like a symmetrical mountain from inception steadily upward and peaking in Elaboration and gradually diminishing during Construction.

❑ Artifacts

§ Design set

§ Architecture Description

❑ Life Cycle Phase Emphasis

§ Inception - formulate architecture concept

§ Elaboration - Achieve architecture baseline

§ Construction - Design components

§ Transition - Refine architecture and components

Activity Levels across the life cycle phases (5 of 7)

Implementation workflow

❑ Levels of activities - (Programming the components and evolving the implementation and deployment artifacts)

■ Low activity in Inception, medium activity during Elaboration, very high activity during Construction, and tapering off during Transition.

❑ Artifacts

■ Implementation set

§ Deployment set

❑ Life Cycle Phase Emphasis

§ Inception - Support architecture prototype

§ Elaboration - Produce architecture baseline

§ Construction - Produce complete component

§ Transition - Maintain components

Activity Levels across the life cycle phases (6 of 7)

Assessment - from workflow to core discipline as Test

❑ Levels of activities - (assessing the trends in process and product quality)

• Builds from very low in Inception to higher (but low levels) in Elaboration, to very very high in Construction and continuing at this height into Transition and gradually becoming lower level of activity.

§ Artifacts

o Release Specifications

o Release Descriptions

o User manual

o Deployment Set

❑ Life Cycle Phase Emphasis

■ Inception - Assess plans, vision, prototypes

■ Elaboration - Assess architecture

■ Construction - Assess interim releases

■ Transition - Assess product releases

Activity Levels across the life cycle phases (7 of 7)

❑ Deployment - from workflow to core discipline.

❑ Levels of activities - (Transitioning the end products to the user) Very low level during Inception. Medium level during Elaboration, low during Construction, and pretty high level of activity during Transition phase.

❑ Artifacts

■ Deployment Set

❑ Life Cycle Phase Emphasis

■ Inception - Analyze user community

■ Elaboration - Define use manual

■ Construction - Prepare transition materials

■ Transition - Transition product to user

Modern Process Framework

❑These levels of activities and the artifacts produced represent one of the key signatures of a modern process framework and provide a viewpoint from which to discuss four of the key principles discussed earlier.

1. Architecture-first approach

"Extensive requirements analysis, design, implementation, and assessment activities are performed before the construction phase (phase), when full-scale implementation (core discipline or workflow) is the focus.

This early life-cycle focuses on implementing and testing the architecture must precede full-scale development and testing of all the components and must precede the downstream focus on completeness and quality of the entire breadth of the Product features."

2. Iterative life-cycle process.

"Each phase portrays at least two iterations of each workflow. This default is intended to be descriptive, not prescriptive. Some projects may require only one iteration in a phase; others may require several iterations. The point is that the activities and -artifacts of any given workflow (now, core discipline) may require more than one pass to achieve adequate results."

3. Round-trip Engineering

"Raising the environment activities to a first-class workflow (now, Core Supporting Discipline) is critical. The environment is the tangible embodiment of the project's process, methods, and notations for producing the artifacts."

4. Demonstration-based Approach

Implementation and assessment activities are initiated early in the life cycle, reflecting the emphasis on constructing executable subsets of the evolving architecture."

Recall, each iteration contains assessment at its conclusion.

Iteration Workflows

❑ "An iteration consists of a loosely sequential set of activities in various proportions depending on where the iteration is located in the development cycle."

❑ Contents of an iteration is determined by 'iteration planning' based on critical use cases and high risk items -decreasing in priority as we progress across the development cycle.

❑Those artifacts necessary to support the implementation of these use cases / scenarios are developed, assessed, and integrated into the evolving system.

Iteration content - by Core Discipline

‘Management,is concerned with the content of the iterations, assigning work, and the.contents of anticipated releases.

Environment is concerned primarily with maintaining the software change database - tracking, prioritizing, addressing any changes that arise.

Requirements; is concerned with looking carefully at the baseline plan, architecture, and requirement set artifacts that are needed to fully expand the use cases that need to be demonstrated at the end of this iteration - as well as their evaluation criteria.

❑Design - is concerned with developing the design model and test model by evolving the baseline architecture and design set artifacts against the evaluation criteria for a specific iteration; Also need to update the design set artifacts in response to the activities within this iteration.

Implementation: addresses either developing (from scratch), customizing, or acquiring (purchase, reuse) new components and to test and integrate these component into to current architectural baseline.

Assessment: concerned with evaluating the results of each iteration to insure compliance with evaluation criteria and to identify rework needed before deployment of this release or allocated to the next iteration; also, assess -the results for this iteration so as to improve the next iteration's procedure.

Deployment: concerned with transmitting the release-either internally or to an external organization for exercise.

Conclusion

Many activities occur at the same time. Recall the model of the RUP: requirements are not all done at a single setting; rather, design, implementation, test, etc. all occur to a greater or lesser degree each iteration depending on which iteration we're in.

Early iterations in Inception and Elaboration focus on project management, requirements, and design - and assessment activities.

Iterations in Construction, focus on design, implementation, and assessment.

In Transition focus on assessment and deployment.

Iteration Contents - Conclusion

All iterations include continuous assessment of risk, controlling the baselines of each artifact, and assessing/archiving the demonstrated results that illustrate:

Understanding of requirements

Satisfying design features and performance, and

Consistently reviewing the plan for any changes that may occur.

Iteration Contents - Conclusion

❑In practice, the various sequences and overlaps among iteration become more complex.

❑ Note: an iteration represents the state of the overall architecture and the complete deliverable system. An increment represents the current work in progress that will be combined with the preceding iteration to form the next iteration.

❑ Figure 8.4. Note that when an increment is completed, it corresponds to the end of an iteration also. Converse is not true.

Chapter 9

Design

I. Introduction

2. The role of design in software development life cycle

3. Artifacts

4. Worker

5. Workflow

1. Introduction

The purpose of design are to

1. Acquire an in-depth understanding of issues regarding nonfunctional requirements and constraints related to programming languages, component reuse, Operating systems, distribution and concurrency technologies, database technologies, user-interface technologies, transaction management technologies and others.

2. Create an appropriate input to and point of departure for subsequent implementation activities by capturing requirements on individual subsystems, interfaces, and classes.

3. Be able to decompose implementation work into more manageable pieces handled by different development teams, possibly concurrently.

4. Capture major interfaces between subsystems.

5. Be able to visualize and reason about the design by using a common notation.

6. Create a seamless abstraction of the system's implementation.

Analysis Model and Design Model (Table 9.i, pp.219)

Analysis Model	Design Model
Conceptual model, because it is an abstraction of the system and avoids implementation issues.	Physical model, because it is a blueprint of the implementation
Design generic (applicable several designs)	Not generic, but specific for an implementation
Three (conceptual) stereotypes on classes: «control>>;«entity>>, and <<boundary>>	Any number of (physical stereotypes on classes, depending on implementation languages
Less formal	More formal
Less expensive to develop(1:5 ratio to design)	More expensive to develop (5:1 ratio to analysis)
Few layers Dynamic (but not much focus on sequence	Many layers, Dynamic (much focus on sequence)
Outlines the design of the system, including its architecture,	Manifests the design of the system, including its architecture (one of its views)
Primarily created by "leg work," in workshops and the like	Primarily created by "visual programming" in round-trip engineering environment
May not be maintained throughout the complete software life cycle	Should be maintained throughout the complete software life cycle
Defines a structure that is an essential input to shaping the system - including creating the design model.	Shapes the system while trying to preserve the structure defined by the analysis model as much as possible

The Workers and Artifacts (fig 9.1, pp. 216)

· Architect: responsible for Design Model, Deployment Model, and Architecture Description.

· Use-case Engineer: responsible for Use-case Realization -Design.

· Component Engineer: responsible for Design Class, Design Subsystems and Interface.

2. The role of Design in the Software Life Cycle

· Design is the focus during the end of elaboration and the beginning of construction iterations. It contributes to a sound and stable architecture and creates a blueprint for the implementation model. Since the design model is very close to implementation, it is natural to keep and maintain the design model through the complete software life cycle.

3. Artifacts: Design Model

The design model is a hierarchy of design subsystems containing design classes, use-case realizations-design, and interface. (Fig 9.3, pp21.8)

3. Artifacts: Design Class

A design class is a seamless abstraction of a class or similar construct in the system's implementation.

Artifacts: Design Class

The language used to specify a design class is the same as the programming language. (Using the chosen language syntax)

The visibility of attributes and operations of a design class is often specified.

The relationships between design classes should have straightforward meanings (generalization/inheritance; associations and aggregations/class attributes) when the class is implemented.

The methods of a design class should have straightforward mappings to the corresponding methods in the implementation of the class.

3. Artifacts: Design Class

A design class can postpone the handling of some requirements to subsequent implementation activities.

A design class is often given a stereotype that is seamlessly mapped to a construct in the given programming language (Example: Visual Basic <<form>>, <<user control>>).

A design class can realize interfaces if it makes sense to do so in the programming language. (Example: Java client class)

A design class can be active, implying that objects of the class maintain their own thread of control, or not active, implying that their objects "run” in the address space and under the control of other active object.

4. Workers: Architect

· The architect is responsible for the integrity of the design and deployment models, ensuring that the models are correct, consistent, and readable. (Fig 9.13, pp 229)

· The architect is also responsible for the architecture of the design and deployment models.

· The architect is not responsible for the continue development and maintenance of the artifacts within the design model. (They are the responsibilities of the use-case engineer and component engineer.)

4. Workers Use-Case Engineer

· A use-case engineering is responsible for the integrity of the user-case realization, ensuring that they fulfill the requirements made on them, this includes making all, textual descriptions and diagrams describing the use-case realization readable and suitable for their purpose.

· The use-case engineer is not responsible for the design classes, subsystems, and relationships employed in the use-ease realization (they are the corresponding component engineer's responsibilities.)

4. Workers: Component Engineer

The component engineer defines and maintains the operations, methods, attributes, relationships, and implementation requirements of the design classes.

The component engineer also maintain the integrity of the subsystems. This includes making sure that their contents are correct, that their dependencies on other subsystems, and/or interfaces are correct and minimized, and that they correctly realize the interface.

5. Workflow: Architecture Design

1. Architect: Architecture Design (Fig 9.17, pp232)

Input: Use-Case Model:

Supplementary Requirements;

Analysis Model:

Architecture Description (view of the analysis model)

Output: Sub system (outlined)

Interface (outlined)

Design Class (outlined)

Deployment Model

Architecture Description

(View of tine design and deployment model)