INF305 Notes (Pressman)

7/28/2019 INF305 Notes (Pressman)

1/57

INF305

Yellow = answered textbook questions Blue = unanswered questions

Chapter 3 Process Models

Prescriptive process models prescribe a set of process elements:

Framework activities, tasks, work products, quality assurance

Generic framework activities:

Communication Planning Modeling Construction Deployment

Linear process model:

1. Waterfall model (Classic life cycle)

Systematic, linear, sequential approach

For projects with these characteristics:

o The problem is well understood (well-defined requirements)

o The delivery date is realistico Major changes in requirements are unlikely

For when work flows in a reasonably linear fashion

The linear nature can lead to blocking states, where you have

to wait for other team members to complete dependent tasks

Inappropriate model for todays fast-paced changing software

Problems:

o Real projects rarely follow a sequential flow

o The customer has to state all requirements explicitly

o Working version of the program appears late in the project

Software projects that would be amenable to the waterfall model:

o Awell-understood modification to an existing programo A straightforwardimplementation of a numerical calculation

orbusiness rule, even if it is complexo A constrained enhancement to an existing program

Incremental process models:

For when requirements are well-defined, and a limited set of software

functionality must be provided quickly, and then refined later.

2. Incremental model

Combines elements of the waterfall model applied iteratively

Linear sequences each produce deliverable increments of software

The first increment is usually a core product, used by customers

Each increment focuses on the delivery of an operational product

Good when staffing is unavailable for a complete implementation

Increments can be planned tomanage technical risks

Software projects amenable to the incremental model:

o A project that has significant functionality that must be

delivered in a very tight time frame (Add on extras later)

1


2/57

3. RAD model

An incremental model that emphasizes a short development cycle

A high-speed adaptation of thewaterfall model, where rapiddevelopment is achieved by using component-based construction

For when requirements are understood and scope is constrained

For when business applications can be modularized

A fully functional system is constructed in a very short time

Each major function is addressed by a separate RAD teamand thenintegrated to form a whole

To achieve rapid development, this model assumes the existence

of: a project that can bemodularizedin a manner that allowsmajor functionality to be deliveredwithin 60-90 days (Thisisnt always the case sometimes timelines can be longer)

Drawbacks:

For large projects, RAD requires sufficient human resources todevelop the increments in parallel

Projects will fail if people dont commit to rapid activities

If a system cant be modularized, you cant build components Might not work if high performance is an issue

Might not be appropriate when technical risks are high

Evolutionary process models:

For when core requirements are well understood and a limited version

of the product must be introduced, which will evolve over time.

Iterative, and can easily accommodate product requirement changes.

4. Prototyping

For when the customer defines a set of general objectives

For when the developer is unsure of the form of the software

Can be used as a standalone process model, but is more commonly

used as a technique that can be implemented within other models

The prototype helps to identify software requirements

It should be discarded (at least in part)

Problems with prototyping:

o The customer sees a working version and wants to keep it

o Developers may become comfortable with inefficient choices

Software projects amenable to the prototyping model:

o Ones which involve human-machine interaction and/or heavy

computer graphicso Ones where results can easily be examinedwithout real-time

interaction (e.g. command-driven systems using mathematical

algorithms) i.e. not embedded software!

Process adaptations required if the prototype will evolve into a

deliverable system / product:

o More rigorous design rules and SQA procedures must beapplied from the beginning

2


3/57

o The prototype must be designed with extensibility in mindand be implemented using a programming environment that is

amenable to production system development

o The prototype is initially a mechanism for identifying

requirements, and thenbecomes the framework for extensionsthat will cause it to evolve into a production system

5. Spiral model

Combines the iterative nature of prototyping with the controlled

and systematic aspects of the waterfall model

Rapid development of increasingly complete versions of software

Software is developed in a series of evolutionary releases

Each framework activity represents 1 segment of the spiral path

Risk-driven model: risk evaluation during each iteration

Anchor point milestones are noted for each evolutionary pass

This model can apply throughout the life of the software

Good for developing large-scale systems and software

Not good if you have a fixed budget, because project cost isrevised as each circuit is completed

Prototyping reduces risks, and can be applied at any stage

Problems:

o May be hard to convince customers that its controllable

o Demands considerable risk assessment and expertise

o Problems if a major risk is not uncovered and managed

What happens to the software as you move outwards along the

spiral process flow:

o The product moves towards a more complete state

o The level of abstraction at which work is performed is

reduced (i.e. implementation-specific work accelerates aswe move further from the origin)

6. Concurrent development model

Represented as a series of framework activities, software

engineering actions & tasks, and their associated states

All activities exist concurrently but reside in different states

What the states represent and how they come into play:

o The different parts of a project (framework activities)

will be at different stages of completeness (e.g. under

development, awaiting changes, done), so you can say

that all activities are being performed concurrentlyo The challenge is to manage the concurrency and to be able

to assess the status of the project

A series of events are defined that will trigger transitions

from state to state for each of the software activities / tasks

This model is applicable to all types of software development

Often used for the development of client/server applications

Provides an accurate picture of the current state of the project

3


4/57

Weaknesses of process models:

Prototyping poses a problem to project planning because of the

uncertain number of cycles required to construct the product

Evolutionary processes dont establish the maximum speed of the

evolution

Software processes should be focused on flexibility and

extensibility rather than on high quality

Specialized process models:

For when a narrowly defined software engineering approach is chosen.

7. Component-based development model

Incorporates many characteristics of the spiral model, but

composes applications from prepackaged software components

Works best when object technologies are available for support

These steps are implemented using an evolutionary approach:

1. Available products are evaluated for the application domain

2. Component integration issues are considered3. A software architecture is designed

4. Components are integrated into the architecture

5. Comprehensive testing is conducted to ensure functionality

Benefit: Leads to software reuse

Software projects amenable to the component-based model:

o Ones where COTS components are available

o If the interfaces for the available components are

compatible with the architecture of the system to be built

8. Formal methods model

Formal mathematical specification of computer software

Ambiguity, incompleteness, and inconsistency are easily found

Offers the promise of defect-free software

Reasons why it is not widely used:

o Time-consuming and expensive

o Extensive training

o Difficult to use the models to communicate with customers

Good for safety-critical software (aircraft avionics, medical)

9. Aspect-oriented software development

Software has localized features, functions, and information These localized characteristics are modeled as components and

then constructed within the context of a system architecture

Discuss the meaning of crosscutting concerns:

o Concerns (e.g. security, fault tolerance) that cut across

multiple system functions, features and information

Aspectual requirements define those crosscutting concerns that

have impact across the software architecture

Aspects = localizing the expression of a crosscutting concern

4


5/57

10. The Unified Process

Recognizes the importance of customer communication (use cases)

Emphasizes the important role of software architecture

Suggests an iterative, incremental process flow

The difference between the UP and UML:

o UML = a modeling notation and languageo UP = a process framework in which UML may be applied as

part of SE activities

Phases of the Unified Process:

1. Inception

Customer communication and planning activities

Identify software requirements, propose a rough architecture,

and plan for the iterative, incremental nature of the project

Use cases describe fundamental business requirements

Work product: Use case model

2. Elaboration

Customer communication and modeling activities

Refines and expands the preliminary use-cases

Expands architectural representation to include 5 views of the

software: Use-case model, analysis model, design model,

implementation model, and deployment model

Work products: analysis model, design model

3. Construction

Develop the software that will make each use-case operational

Unit tests are designed and executed for each component

Work products: implementation, deployment, and test models

4. Transition

Encompasses later stages of construction & 1st part of deployment

Beta testing by end-users to discover defects & deficiencies

Support information is created (user manuals)

Work product: the software increment

(5.) Production

Coincides with deployment

On-going use of the software is monitored, support of the

operating environment is provided, and defect reports and

requests for changes are submitted and evaluated

Workflows distributed across the UP phases:

The difference between a UP phase and a UP workflow:

o A workflow is distributedacross all UP phases andidentifies the tasks required to accomplish an action andthework products produced

5


6/57

Inception Elaboration Construction Transition

Requirements Use casemodel

Analysis Analysismodel

Design Design model

Implement ImplementationmodelDeployment

model

Test Test model

Is it possible to combine process models?

o Yes, since they all perform the same set of generic

framework activities

What happens when we emphasize development speed over product

quality:

o The advantage of developing software in which quality isgood enough is that it will meet the deadline

o The disadvantage is that it may require more testing,

design and implementation rework

Chapter 4 An agile view of process

Agility

An agile team can respond appropriately to changes

The skills of the team members and their ability to collaborate

is at the core for the success of the project Dynamic, content specific, change embracing, and growth oriented

Encourages team structures and attitudes that ease communication

Emphasizes rapid delivery of operational software and de-

emphasizes the importance of intermediate work products

Adopts the customer as a part of the development team

Recognizes that a project plan must be flexible

Can be applied to any software process

4 values of agile software development:

1. Individuals and interactions over processes and tools2.Working software over comprehensive documentation3. Customer collaboration over contract negotiation4. Responding to change over following a plan

Situations in which the 4 values can get a software team into

trouble:

1. A project may fail because the processes & tools are poor

2. Documentation helps maintaining applications years later

3. Negotiation helps avoid unrealistic expectations

6


7/57

4. A chaotic project environment (no plan) can lead to failure

12 principles for achieving agility:

1. Main priority: early & continuous delivery of valuable software

2. Welcome changing requirements, even late in development

3. Deliver working software frequently

4. Business people & developers must work together daily

5. Build projects around motivated individuals

6. Face-to-face conversation with the development team

7. Working software is the primary measure of progress

8. Agile processes promote sustainable development

9. Continuous attention to technical excellence and good design

10. Simplicity is essential

11. The best architectures, requirements, and designs emerge from

self-organizing teams

12. At regular intervals, the team reflects on how to become more

effective, then tunes and adjusts its behavior accordingly

Select one agility principle and try to determine whether each

of the process models in this chapter exhibits the principle:

o Welcome changing requirements, even late in development

Change, with agile processes, is essential for competitive

advantage, so all the models exhibit this principle

Try to come up with another agility principle that would help a

software engineering team become even more maneuverable:

o A team should know whose skills suit a particular project

and get these people on their project

o Communication is the key: The customer and developer

should communicate regularly, even if separated

Agile processAny agile software process is characterized by 3 key assumptions:

1. It is difficult to predict which software requirements will

persist and which will change (priorities also change)2. For many types of software, design and construction are

interleaved, and it is difficult to predict how much design is

necessary before construction is used to prove the design

3. Analysis, design, construction, and testing are not as

predictable (from a planning point of view) as we might like

A process that can manage unpredictability must be adaptable

It must adapt incrementally, using customer feedback

An incremental development strategyshould be instituted

Software increments (e.g. prototypes) must be delivered in short

time periods so that adaptation keeps pace with change

Why does an iterative process make it easier to manage change?

Is every agile process iterative? Is it possible to complete a

project in just one iteration and still be agile? Explain.

7


8/57

o An iterative approach enables customers to evaluate

regularly, provide feedback, and influence the required

changes. (The software team manages change by focusing on a

defined increment and postponing any changes until the next

increment). All agile processes are iterative. If a project

were completed in just one iteration it would not be agile

because frequent software delivery is a key characteristic

of agile development.

Why do requirements change so much?

o It is difficult to predict in advance which requirements

will persist and which will change

o It is difficult to predict how customer priorities will

change as the project proceeds

o It is difficult for customers to verbalize their software

needs until they see a working prototype

Describe agility for software projects:

o Agility can be applied to any software process. The processmust be designed in a way that allows the project team to

Adapt tasks and to streamline them

Conduct planning in a way that understands the

fluidity of an agile development approach

Eliminate all but the most essential work products

Emphasize an incremental delivery strategy that gets

software to the customer as rapidly as feasible

Most agile process models recommend face-to-face communication.

Yet today, members of a software team and their customers may be

geographically separated from one another. Do you think thisimplies that geographical separation is something to avoid? Can

you think of ways to overcome this problem?

o Physical proximity is not always possible. Face-to-face

communication can be achieved with low-cost video

conferencing, Web-based discussion groups and other

electronic means. These are not as powerful as physical

proximity, but they can achieve much the same result.

Human factors:

Key traits that must exist among the people on the software team:

CompetenceSkill and knowledge of the process must be taught to the members

Common focus

Focus on the goal of delivering a working increment on time

Collaboration

Team members must collaborate with one another, with the

customer, and with business managers to accomplish tasks

Decision-making ability

The team is given decision-making authority for project issues

8


9/57

Fuzzy problem-solving ability

Deal with ambiguity and change, learning lessons from the past

Mutual trust and respect

A jelled team is strongly knit (whole > parts)

Self-organization

The team organizes

1. itself for the work to be done

2. the process to best accommodate the environment3. the work schedule to best achieve delivery of the increment

o Advantage: improves collaboration and boosts team morale

Agile process models

1. Extreme programming (XP)

Uses an OO approach as its preferred development paradigm

Planning

Stories describe required features & functionality of software

Each story is written by the customer & placed on an index card

The customer assigns a value (priority) to the story

Members of the XP team assess each story and assign a cost

(measured in development weeks)

If the story requires more than 3 weeks, the customer must split

the story into smaller ones

Customers and the XP team decide how to group stories into the

next release (the next increment)

Once a commitment is made for a release, the team orders thestories that will be developed in one of three ways:

o All stories will be implemented immediately

o The stories with highest value will be implemented firsto The riskiest stories will be implemented first

After the 1st release, the team computesproject velocity (thenumber of customer stories implemented during the 1st release)

Project velocity can then be used to:

o Help estimate delivery dates & schedule for other releases

o Determine whether an over-commitment has been made for all

stories across the entire development project

As work proceeds, the customer can add, change, split, or

eliminate stories, and the team modifies its plans accordingly

An XP story that describes the favorites feature of browsers:

o Each URL that I intend to revisit can be stored in a

favorite places file. I should be able to name and group

URLs by categories that I define, store a favorite place in

a particular category, order the URLs in any way I like and

recall the favorite places file at any time from the

browser menu. I should be able to list all favorite places

as a categorized list in my browser window. I can select a

favorite place using my mouse. Once selected, the browser

will establish a link to that URL and display the website.

9


10/57

Design

A simple design is always preferred over a complex one

The design provides implementation guidance for a story

(The design of extra functionality is discouraged)

CRCcards identify and organize the OO classes that are relevant

If a difficult design problem is encountered, create a prototype

Spike solution = the prototype that is implemented & evaluated

The only work products are CRC cards and spike solutions

Refactoring = improving the code design after its been written

Design occurs both before and after coding commences (Refactor!)Coding

Develop unit tests to exercise each story before coding

When the code is complete, it can be unit tested immediately

Pair programming = having two people work together at onecomputer to create code for a story, for quality assurance

As pair programmers complete their work, their code is integratedwith the work of others, to uncover errors early

This continuous integration provides a smoke testing environmentTesting

Tests should be automated to be executed easily & repeatedly

Regression testing strategy whenever code is modified/refactored

As the individual unit tests are organized into a universal

testing suite, integration and validation testing of the systemcan occur on a daily basis

This provides the team with a continual indication of progress

Acceptance tests / customer tests = ones specified by customersand focus on overall features (stories) that are visible

2. Adaptive Software Development (ASD)

Focuses on human collaboration and team self-organization

Speculation

The project is initiated & adaptive cycle planning is conducted

Adaptive cycle planning uses the customers mission statement,

project constraints, and basic requirements to define the set of

release cycles that will be required

Collaboration

Motivated people work together in a way that multiplies their

talent and creative output beyond their absolute numbers

People working together must trust one another to

o Criticize without animosity

o Assist without resentment

o Work as hard / harder as they do

o Have the skill set to contribute to the work at hand

o Communicate problems in ways that lead to effective action

Learning

ASD teams learn in 3 ways:

1. Focus groups

10


11/57

The customer / users provide feedback on software increments

2. Formal technical reviews

ASD team members review the software components developed

3. Postmortems

The team becomes introspective, addressing its own performance

3. Dynamic Systems Development Method (DSDM)

Building systems which meet tight time constraints by usingincremental prototyping in a controlled project environment

Iterative process, but only enough work is required for each

increment to facilitate movement to the next increment

The remaining detail can be completed later

Feasibility study (additional)

Establishes the basic business requirements & constraints

Assesses whether the application is a viable candidate for DSDM

Business study (additional)

Establishes the functional & information requirements

Defines the basic application architecture and identifies the

maintainability requirements for the application

Functional model iteration (iterative)

Produces a set of incremental prototypes for demonstration

(All DSDM prototypes are intended to evolve into deliverables)

Additional requirements are gathered by eliciting feedback from

users as they exercise the prototype

Design & build iteration (iterative)

Revisits prototypes built during the functional model iteration

to ensure that each will provide operational business value

(The previous activity & this one can occur concurrently)

Implementation (iterative) The latest software increment is placed into operation

Note that the increment may not be 100% complete, and changes

may be requested as the increment is put into place

DSDM work continues by returning to the function model iteration

4. Scrum

Small working teams are organized to maximize communication &

knowledge, and minimize overhead

The process must be adaptable to technical & business changes

Frequent software increments Work and people are partitioned

Constant testing and documentation

A product is declared done whenever required

Requirements analysis design evolution delivery

Software process patterns define some development activities:

o Backlog

Prioritized list of project requirements / features

Items can be added to the backlog at any time

11


12/57

o Sprints

Work units that are required to achieve a requirement

defined in the backlog that must fit into a time-box

During the sprint, the backlog items it uses are frozen

o Scrum meetings

Short daily meetings where these key questions are asked:

1. What did you do since the last team meeting?

2. What obstacles are you encountering

3. What do you plan to accomplish by the next meeting?

A scrum master assesses the responses from each person

The meetings help the team uncover potential problems early

These daily meetings lead to knowledge socialization

o Demos

Increment delivered to the customer so that functionality

can be demonstrated and evaluated

The demo maynt contain all planned functionality, but only

the functions delivered within the established time-box

A sample Scrum pattern:

Pattern Scrum meeting

Intent To answer three key questions using an abbreviated meetingformat that is conducted daily

Type Task pattern

Initialcontext

1. The project should have been initiated and a backlog

developed

2. Sprints should be underway

3. All members of the Scrum team should agree to meet in a

pre-specified location each day for the scrum meeting

4. A team leader should be defined

Problem It is often difficult for members of the team tounderstand the status of the project and the status of

work being conducted by each member of the team. When

meetings are conducted, they are often too time-consuming

and ineffective.

Solution Short meetings are held daily and the 3 key questions areasked and answered by all team members

Resultingcontext

At the conclusion of the meeting, each person has answered

the questions noted in the solution

Relatedpatterns

Backlog preparation

Conducting a sprint

Known uses/ examples

Scrum meetings are conducted throughout every Scrum

project and are an important element of communication

5. Crystal

An approach that puts a premium onmaneuverability

Primary goal: delivering useful, working software

Secondary goal: setting up for the next game

To achieve maneuverability, there is a set of methodologies to

choose from, which all have core elements in common

12


13/57

Reflection workshops are conducted before, during, and after anincrement is delivered

Why Crystal is called a family of agile methods:

o The Crystal approach emphasizes collaboration and

communication among people who have varying degrees of

interest in the software project. The method is also

tolerant of varying team cultures and can accommodate both

informal and formal SE approaches. Crystal family isactually a set of sample agile processes that have been

proved effective for different types of projects. The

intent is to allow agile teams to select the member of the

Crystal family that is most appropriate for their project.

6. Feature Driven Development (FDD)

A feature is a client-valued function that can be implemented

in two weeks or less

Benefits of the emphasis on the definition of features:

o Because features are small, users can describe them more

easily and better review them, and their design & code areeasier to inspect effectively

o Features can be organized into a hierarchy

o The team develops operational features every two weeks

o Project planning, scheduling, and tracking are driven by

the feature hierarchy, rather than an arbitrarily adopted

software engineering task set

Five framework activities (processes):

1. Develop an overall model

2. Build a features list

3. Plan by feature

4. Design by feature5. Build by feature

FDD provides greater emphasis onproject management guidelinesand techniques than many other agile methods

To determine if software increments are properly scheduled, FDD

defines 6 milestones: design walkthrough, design, design

inspection, code, code inspection, promote to build

Use the FDD feature template to define a feature set for a Web

browser, and develop a set of features for the feature set:

(action) the (result) (by | for | of | to) a(n) (object)

Examples:Specify a URL for a website

Display the content of a website

Fill in the content of a Web form

Show all URLs for favorite places

7. Agile Modeling (AM)

With large systems, scope and complexity must be modeled so thato All can better understand what needs to be accomplished

13


14/57

o The problem can be partitioned effectively among the people

o Quality can be assessed at every step during engineering

AM = a methodology for modeling & documentation of software in a

light-weight manner: Agile models are barely good, not perfect

AM provides guidance to practitioners during analysis & design

An agile team must have the courage to make decisions andhumility to recognize that they dont have all the answers

Principles that make AM unique:o Model with a purpose

Have a specific goal before creating the model

o Use multiple models

Each model should present a different aspect of the system

o Travel light

Keep only the models that will provide long-term value

o Content is more important than representation

Modeling should impart information to its intended audience

o Know the models and the tools you use to create them

Understand the strengths & weaknesses of each model & tool

o Adapt locallyAdapt the modeling approach to the needs of the agile team

Build a table that maps the generic framework activities into

the activities defined for each agile process:

Generic: XP ASD Scrum

Communi-

cation

Plan (user stories) Speculation

Collaboration

Requirements

Planning Plan (commit to a

specific increment)

Speculation

(adaptive cycle

planning)

Analysis

Modeling Design (refactoring,spike solutions)

Collaboration(mini-specs)

Design

Construc-

tion

Code (pair programming)

Test (unit testing)

Learning (learn

as you develop

components)

Evolution

Deployment Test (acceptance

testing, customer tests)

Learning Delivery

Generic: FDD DSDM

Communication Develop an overall model

Build a features list

(features are groupedinto sets)

Plan by feature

Feasibility study (basic

requirements)

Business study (functional& info requirements)

Planning

Modeling Design by feature

(design package)

Build by feature

(completed function)

Functional model iteration

(prototypes)

Design & build iteration

(revisit prototypes)

Construction

Deployment Implementation

14


15/57

Chapter 5 Software engineering practice

Software engineering practiceThe essence of practice

1. Understand the problem (communication & analysis)

Who are the stakeholders?

What data, features, etc are needed to solve the problem?

Can the problem be compartmentalized?

Can an analysis model be created?

2. Plan a solution (modeling & software design)

Have you seen similar problems before?

Has a similar problem been solved? (Are elements reusable?)

Can subprograms be defined?

Can a design model be created?

3. Carry out the plan (code generation)

Is source code traceable to the design model?

Has the design and code been reviewed?

4. Examine the result for accuracy (testing & quality assurance)

Has a reasonable testing strategy been implemented?

Has the software been validated against all requirements?

7 Core principles

Summarize David Hookers 7 principles for software development:

1. Software exists to provide value to its users

2. Keep it simple

3. Maintain the vision

4. What you produce, others will consume (maintain)

5. Be open to the future dont design yourself into a corner

6. Plan ahead for reuse

7. Think before you act

Other technical essentials that can be recommended for SE:

o The need to test software thoroughly to find errorso The need to use automated tools to facilitate developmento The need tomeasure the product to improve quality

Other management essentials that might be recommended for SE:

o Continuous & effective communication with stakeholderso Implementation of an agile mindseto A set ofmanagement & technical practices that enable the

team to define a road map as it travels towards its goal

1. Communication practices1. Listen

2. Prepare before you communicate (e.g. an agenda)

3. Someone should facilitate the activity

4. Face-to-face communication is best

5. Take notes and document decisions

15


16/57

6. Strive for collaboration

7. Stay focused, modularize your discussion

8. If something is unclear, draw a picture

9. Move on after you agree / disagree / if something is unclear

10. Negotiation works best when both parties win

Prepare a set of guidelines that focus solely on facilitation:

o Understand thebusiness domaino Know who the stakeholders are and what goals each haso Establish a defined requirements-gatheringmechanismo Create a method for recording requirementso Establish a way toprioritize needs

How should communication preparation manifest itself in the

early work that you do? What work products might result?

o Research thebusiness domain that the software will addresso Understand the stakeholders who will specify requirementso Develop a defined strategy for requirements gathering

o Understand the goals for each of the stakeholderso Understand that negotiation will occur

How does agile communication differ from traditional SE

communication? How is it similar?

o

Why it is necessary to move on:

o Sometimes people cant come to an agreement on some

project-related issue, so rather than iterating endlessly,

it is best to move on to achieve communication agility,

leaving the topic for later

2. Planning practices1. Understand the scope of the project

2. Involve the customer in the planning activity

3. Recognize that planning is iterative

4. Estimate (effort, cost, task duration) based on what you know

5. Consider risk as you define the plan (make contingency plans)

6. Be realistic (People make mistakes and dont work all day)

7. Adjust granularity as you define the plan

8. Define how you intend to ensure quality (FTR, pair programming)

9. Describe how you intend to accommodate change

10. Track the plan frequently and make adjustments as required

What granularity means in the context of a project schedule:

o Granularity refers to the level of detail that isintroduced as a project plan is developed

o Fine granularity plan: detail, planned over a short timeo Coarse granularity plan:broadwork tasks over long periods

o Granularity goes fine coarse as the timeline moves on

16


17/57

3. Modeling practiceAnalysis modeling

1. The information domain (data in-out flows & stores) of a problem

must be represented and understood

2. The functions that the software performs must be defined

3. The behavior of the software must be represented

4. The models that depict information, function, and behavior must

be partitioned to uncover detail in a layered fashion

5. The analysis task should move from essential information towards

implementation detail

What three domains are considered during analysis modeling?

o Informational, functional, and behavioral domains

Design modeling1. Design should be traceable to the analysis model

2. Always consider the architecture of the system to be built

3. Design of data is as NB as design of processing functions

4. Interfaces (internal & external) must be designed with care

5. User interface design should be tuned to the needs of the user

6. Components should be highly cohesive

7. Components should be loosely coupled

8. Design representations (models) should be easy to understand

9. The design should be developed iteratively, striving for greater

simplicity with each iteration

Why models are important in SE work:

o Models help us gain a better understanding of the actualentity to be built. Analysis models represent customer

requirements, and design models provide a concretespecification for the construction of the software.

4. Construction practiceCoding principles and conceptsPreparation principles:

1. Understand the problem youre trying to solve

2. Understand basic design principles and concepts

3. Pick a suitable programming language

4. Select a suitable programming environment

5. Create a set of unit tests for when your component code is done

Coding principles:

1. Constrain your algorithms by adhering to structured programming2. Select data structures that will meet the needs of the design

3. Create interfaces that are consistent with the architecture

4. Keep conditional logic as simple as possible

5. Create nested loops in a way that makes them easily testable

6. Select meaningful variable names and follow coding standards

7. Write code that is self-documenting

8. The visual layout (new lines, indents) should aid understanding

17


18/57

Validation principles:

1. Conduct a code walkthrough when appropriate

2. Perform unit tests and correct errors youve uncovered

3. Refactor the code

Testing principles1. All tests should be traceable to customer requirements

2. Tests should be planned long before testing begins

3. Pareto principle: 80% of errors will be found in 20% of code

4. Testing should progress from in the small to in the large

5. Exhaustive testing is not possible

What is a successful test?

o One that has a high chance of finding an undiscovered error

5. Deployment

Deployment encompasses three actions:

o Delivery

o Support

o Feedback1. Customer expectations for the software must be managed

2. A complete delivery package should be assembled and tested

3. A support regime must be established before the software is

delivered

4. Appropriate instructional materials must be provided to users

5. Buggy software should be fixed first, delivered later

Why feedback is important to the software team:

o Feedback provides the software team with important guidance

that results in modifications to the functions, features,

and approach taken for the next increment

18


19/57

Chapter 7 Requirements engineering

Requirements engineering tasks1. Inception

Most projects begin when a business need is identified

Stakeholders from the business community

o define a business case for the idea

o identify the breadth & depth of the marketo do a rough feasibility analysis

o identify a working description of the projects scope

Software engineers ask a set of context-free questions to get a

basic understanding of the problem, people, and type of solution

Feasibility analysis within the context of inception:

o Feasibility analysis identifies a working description of

the projects scope and assesses whether or not that scopecan be achievedwithin the context of management andtechnical constraints. It defines abusiness case for an

idea and identifies the breadth & depth of the market.

2. Elicitation

Why requirements elicitation is difficult:

Problems of scope

o The system boundary is ill-defined

Problems of understanding

o The customers are not completely sure what is needed

o They dont know the capabilities & limitations of computers

o They dont have a full understanding of the problem domain

o They have trouble communicating their needs

o They omit information that is believed to be obvious

o They specify requirements that are ambiguous or untestable

Problems of volatility

o The requirements change over time

3. Elaboration

The info from inception & elicitation is expanded & refined

Driven by the creation and refinement of user scenarios that

describe how the user will interact with the system

Each user scenario is parsed to extract analysis classes

Attributes & methods of each analysis class are identified

Relationships between classes are identified UML diagrams End-result of elaboration: an analysis model that defines the

informational, functional, and behavioral domain of the problem

4. Negotiation

Possible conflicts:

o Customers may ask for more than can be achieved

o Different users may propose conflicting requirements

Users must rank requirements and discuss conflicts in priority

Risks associated with each requirement are analyzed

19


20/57

Rough estimates of development effort are made and used to

assess the impact of each requirement on project costs and time

Using an iterative approach, requirements are eliminated,

combined, and/or modified so that each party is satisfied

5. Specification

A specification can be a written doc, models, prototype, etc

This is the final work product from the requirements engineer

It describes the function, performance & constraints of a system

6. Validation

Examine the specification to ensure that all requirements have

been stated unambiguously, with errors & omissions corrected

Formal technical review = the primary validation mechanism

The review team includes software engineers, customers, users

7. Requirements management

Activities that help the team identify, control and track

requirements & changes at any time as the project proceeds

Requirements are identified, and traceability tables are made:

o Features traceability table

Shows how requirements relate to important features

o Source traceability table

Identifies the source of each requirement

o Dependency traceability table

Indicates how requirements are related to one another

o Subsystem traceability table

Categorizes requirements by the subsystems they govern

o Interface traceability table

Shows how requirements relate to internal & external

system interfaces

1. Inception: Initiating the requirements engineering processIdentifying the stakeholders

At inception, create a list of people who will contribute input

as requirements are elicited

The initial list will grow as stakeholders are contacted

Recognizing multiple viewpoints

There are different kinds of stakeholders, with different views

As information from multiple viewpoints is collected, emerging

requirements may be inconsistent / conflict with one another All stakeholder info must be categorized in a way that will

allow decision-makers to choose a consistent set of requirements

Working towards collaboration

Stakeholders must collaborate among themselves

The requirements engineer identifies commonality/conflict areas

Asking the first questions

Questions asked at inception should be context-free:

o Who is behind the request for this work?

20


21/57

o Who will use the solution?

o What will be the economic benefit of a successful solution?

o Is there another source for the solution that you need?

o Who is paying for this work?

o Who can we contact in each customer group?

o Do you know of any other business that has solved this

problem successfully?

These questions help identify stakeholders & project benefits The next set of questions enables the team to better understand

the problem and allows the customer to voice his perceptions:

o How would you characterize good output?

o What problems will this solution address?

o Can you describe the business environment?

o Will special performance issues affect the solution?

The final set of questions focuses on the effectiveness of the

communication activity itself:

o Are you the right person to answer these questions?

o Are my questions relevant to the problem that you have?

o Am I asking too many questions?o Can anyone else provide additional information?

o Should I be asking you anything else?

These questions help to break the ice & initiate communication

The Q&A session should be used for the first encounter only andthen replaced by a requirements elicitation format

2. Eliciting requirementsCollaborative requirements gathering

Basic guidelines for a collaborative requirements meeting:

o Meetings are conducted & attended by both software

engineers and customers (and other stakeholders)o Rules for preparation and participation are established

o An agenda is suggested

o A facilitator controls the meeting

o A definition mechanism (work sheets / flip charts / chat

room / bulletin board / wall stickers) is used

o The goal is to identify the problem, propose elements of

the solution and a preliminary set of solution requirements

Quality function deployment

QFD = a technique that translates the needs of the customer into

technical requirements for software

Concentrates on maximizing customer satisfaction QFD identifies 3 types of requirements:

o Normal requirements

Reflect objectives stated for the system

E.g. specific system functions, levels of performance

o Expected requirements

Implicit to the system, and not stated explicitly

E.g. ease of use and installation

21


22/57


23/57

Developing use-cases

Primary actors interact to achieve required system function and

derive the intended benefit from the system

Secondary actors support the system so that primary actors can

do their work

Questions that should be answered by a use-case:

o Who are the primary actor(s), secondary actor(s)?o What are the actors goals?

o What preconditions should exist before the story begins?

o What main tasks / functions are performed by the actor?

o What exceptions might come up as the story is described?

o What variations in the actors interaction are possible?

o What system info will the actor acquire, produce / change?

o Will the actor have to inform the system about changes in

the external environment?

o What information does the actor desire from the system?

o Does the actor wish to be informed of unexpected changes?

Use-cases can be further elaborated to provide more detail Use-cases can be assessed by stakeholders, and assigned priority

A use-case for making a withdrawal at an ATM:

Use case: ATM withdrawalPrimary actor: ClientGoal in context: To withdraw cash from the ATM quickly and securelyPre-conditions: The system has been programmed to recognize theinsertion of the bank card and input of a password.

Trigger: Bank card and password

Scenario:1. User inserts bank card

2. User keys in password

3. User selects which account to draw cash from

4. User keys in the amount of cash

5. User collects cash

6. ATM: Checks if another transaction is required

7. ATM: Ejects bank card if no further transactions are required

8. ATM: Prints bank slip

Exceptions:1. ATM out of order

2. Incorrect password entered3. Password not recognized after 3 attempts

4. ATM does not eject bank card at the end of the transaction

5. User takes a long time to make a selection / to enter password

Priority: Essential, must be implementedWhen available: First incrementFrequency of use: As many times as requiredChannel to actor: Via ATM control panelSecondary actors: ATM machine, camera

23


24/57

Channels to secondary actors: ATM machine: computer networks. ATMmachine is independent of the location.

Camera installed for the safety of the client.

Open issues:1. Should the client use biometrics instead of PIN numbers?

2. Should the ATM machine display client additional information?

3. What will happen if there is a power failure during transaction?

4. How many cameras are to be installed to allow proper

identification should a robbery occur?

3. Elaboration: Building the analysis model The analysis model provides a description of the required

informational, functional, and behavioral domains for a system

The analysis model is a snapshot of requirements at a given time

As the analysis model evolves, some elements become stable,

while others may be more volatile, indicating that the customer

doesnt yet fully understand requirements for the system

Elements of the analysis model

Insert card

Enter password

Select account

Enter amount

Processtransaction

Dispense cash

Eject card

Print slip

ATM

machine

24


25/57

Using different modes of representation forces you to consider

requirements from different viewpoints, which is better

Generic elements common to most analysis models:

o Scenario-based elements

Template-based use-cases

Activity diagrams

o Class-based elements

Class diagrams

o Behavioral elements

State diagrams

o Flow-oriented elements

Data / control flow models

Analysis patterns

Definition of analysis patterns:

o Things that reoccur across all projects within a specificapplication domain. They represent something that can be

reused(e.g. a class, function, behavior)

Two benefits that can be associated with analysis patterns:

o They speed up the development of abstract analysis modelso They facilitate the transformation of the analysis model

into a design model by suggesting design patterns

Information about an analysis pattern is presented in a template

with these headings: Pattern name | Intent | Motivation | Forces

and context | Solution | Consequences | Design | Known uses |

Related patterns

Why we say that the analysis model represents a snapshot of a

system in time:

o The intent of the analysis model is to provide adescription of the required informational, functional, and

behavioral domains for a computer-based system. The model

changes dynamically as software engineers learn more aboutthe system to be built and as stakeholders understand more

about what they really require. For that reason, the

analysis model is a snapshot of requirements at any time.

4. Negotiating requirements

Activities for the beginning of each software process iteration:

1. Identification of the system / subsystems key stakeholders

2. Determination of the stakeholders win conditions3. Negotiation of the stakeholders win conditions to reconcile

them into a set of win-win conditions for all concerned

If youve convinced the customer to agree to every demand you

have, does that make you a master negotiator?

o There should be no winner or loser in a negotiating

situation. Both sides should win. Best negotiations strive

25


26/57

for a win-win result, so if the customer feels he has

won, that makes you a master negotiator.

6. Validating requirementsQuestions to ask when reviewing requirements:

Is each requirement consistent with the overall objectives? Are all requirements specified at the right level of abstraction

Is the requirement really necessary?

Is each requirement bounded and unambiguous?

Is a source (e.g. an individual) noted for each requirement?

Do any requirements conflict with other requirements?

Is each requirement achievable in the systems environment?

Is each requirement testable, once implemented?

Does the requirements model reflect the systems behavior?

Has the requirements model been partitioned to progressively

expose more detailed information about the system? Have requirements patterns been used to simplify the model? Have

they all been validated? Are they consistent with requirements?

Define customer for IS developers, builders of computer-based

products, and system builders:

o The customer for IS developers is often another department

in the same company often the user department

o The customer for builders of computer-based products is

typically the marketing department

o The customer for system builders may be an internaldepartment, marketing, or an outside entity

Why many developers dont pay enough attention to requirements

engineering, and circumstances where you can skip it:

o Software engineers want tobegin building something, sothey sometimes give requirement analysis short shrift. In

addition, understanding the requirements of a problem is

difficult, since requirements change, can be contradictory,and are often difficult to enunciate clearly. Hence,

software engineers want to get through this activity

quickly.o If the problem is relatively small and reasonably well

understood, an abbreviated approach may be chosen. For more

complex problems with many requirements, every task defined

for comprehensive requirements engineering should be

performed rigorously. Requirements engineering builds a

bridge to design and construction and cannot be skipped.

26


27/57

Chapter 8 Building the analysis model

Requirements analysis Result: specification of softwares operational characteristics

Indicates softwares interface with other system elements

Establishes constraints that software must meet

Allows the software engineer to elaborate on basic requirements

established during earlier requirement engineering tasks

Provides the software designer with a representation of info,

function, and behavior to be translated into designs

The analysis model & requirements specification provide the

developer & customer with the means to assess quality

Throughout analysis modeling, the main focus is on what, not how

Overall objective and philosophy

The analysis model must achieve 3 primary objectives:

o Describe what the customer requires

o Establish a basis for the creation of a software design

o Define a set of requirements that can be validated later

The analysis model bridges the gap between a system-level

description and a software design

Analysis rules of thumb

The model should focus on requirements that are visible within

the problem / business domain & have a high level of abstraction

Each element of the analysis model should add to an overallunderstanding of software requirements and provide insight into

the information domain, function, and behavior of the system

Delay consideration of infrastructure and other non-functional

models until design

Minimize coupling throughout the system

Make sure the analysis model provides value to all stakeholders

Keep the model as simple as it can be

Domain analysis

Analysis patterns often reoccur across many applications within

a specific business domain If these patterns are defined and categorized to allow reuse,

then creation of the analysis model is speeded up

More important, the likelihood of applying reusable design

patterns and executable software components grows dramatically

Software domain analysis = the identification, analysis, and

specification of common requirements from a specific applicationdomain, for reuse on multiple projects within that domain

27


28/57

Goal of domain analysis: To find / create those analysis classes

/ common functions and features that are broadly applicable, so

that they may be reused

Role of the domain analyst: to discover and define reusable

analysis patterns, analysis classes, and related info that may

be used by many people working on similar applications

Key inputs for domain analysis:

o Technical literatureo Existing applications

o Customer surveys

o Expert advice

o Current / future requirements

Key outputs for domain analysis:

o Class taxonomies

o Reuse standards

o Functional models

o Domain languages

The purpose of domain analysis and how it is related to theconcept of requirements patterns:

o Domain analysis is an on-going SE activity that is not

connected to any one software project. The intent is to

find analysis patterns that arewidely usedwithin aspecific application domain and to identify a set of

objects and classes that characterize the domain.

An analysis rule of thumb is that the model should focus on

requirements that are visible within the problem or business

domain. What types of requirements are not visible in these

domains? Provide a few examples.o Many infrastructure requirements, e.g.

Functions required to manage global data

Functions required to implement network communication

Functions required to implement a user interface

Analysis modeling approaches

Describe the differences between structured and OO analysis

Structured analysis

o Data is separate from the processes that transform the data

o Data objects are modeled to show attributes & relationships

o Processes are modeled in a manner that shows how they

transform data as data objects flow through the system: DFD

Object-oriented analysis

o Focuses on the definition of classes and the manner in

which they collaborate with one another

Elements of the analysis model:

o Class-based elements

Class diagrams

28


29/57

Analysis packages

CRC models

Collaboration diagrams

o Scenario-based elements

Use-cases text

Use-case diagrams

Activity diagrams

Swim lane diagrams

o Flow-oriented elements

Data flow diagrams

Control-flow diagrams

Processing narratives

o Behavioral elements

State diagrams

Sequence diagrams

Is it possible to develop an effective analysis model without

developing all four of the above elements?

o Yes, although each element presents a different view and

provides the ability to see potential problems. In

addition, if all four elements are developed, the

transition to design is simplified.

Is it possible to begin coding immediately after an analysis

model has been created?

o The analysis model will serve as the basis for design and

construction of the domain objects. It is possible to begincoding after the objects and attributes are defined and

relationships are known. However, the design will suffer as

a result because explicit architectural design will nothave been considered; interfaces will have been developedin a haphazard manner and global data structures will nothave been explicitly designed.

Data modeling concepts

Analysis modeling often begins with data modeling

The analyst defines: all data objects that are processed within

the system, the relationships between the data objects, and

other info that is pertinent to the relationships

Data objects

= a representation of composite information

E.g. dimensions, which incorporates height, width, and depth

A data object can be a thing (report), occurrence (phone call),

event (alarm), role (salesperson), organizational unit (sales

dept), place (warehouse), or a structure (file)

The data object description incorporates the data object and all

of its attributes there is no reference to operations

29


30/57

Data attributes

They define properties of a data object and can be used to:

o Name an instance of the data object

o Describe the instance

o Make reference to another instance in another table

One or more of the attributes must be defined as an ID (key)

Relationships

Indicate how data objects are connected to one another

Cardinality and modality

Cardinality = the no of occurrences of objects in a relationship

Modality = 0 if there is no explicit need for the relationship

Modality = 1 if an occurrence of the relationship is mandatory

Object-oriented analysis

Tasks for OO:

1. Basic user requirements must be communicated between customer

& software engineer

2. Classes must be identified (with attributes & methods)

3. A class hierarchy is defined

4. Define object-to-object relationships (connections)

5. Object behavior must be modeled

6. 1 5 are reapplied iteratively until the model is complete

Scenario-based modelingWriting use-cases

Inception & elicitation provide the info needed to begin

Requirements gathering mechanisms are used to

o Identify stakeholders

o Define the scope of the problem

o Specify overall operational goals

o Outline all known functional requirements

o Describe the objects that will be manipulated by the system

Begin by listing functions / activities of a specific actor

Primary scenarios dont consider any alternative interactions

Secondary scenarios answer these questions:

o Can the actor take some other action?o What error conditions could occur?

o Might the actor encounter some other (external) behavior?Developing an activity diagram

Supplements the use case with a graphical representation of the

flow of interaction within a specific scenario (flow chart!)

The activity diagram adds additional detail not directlymentioned (but implied) by the use case

Rounded rectangles imply a specific function

Arrows represent flow through the system

Decision diamonds depict a branching decision

30


31/57

Solid horizontal lines indicate parallel activities

Swimlane diagrams

A variation of the activity diagram

Additional info: indicates which actor / class is responsiblefor the action described by an activity rectangle

Responsibilities are represented as parallel segments that

divide the diagram vertically

Flow-oriented modeling

The DFD can be used to complement UML diagrams

The DFD takes an input-process-output view of a system

The DFD is presented in a hierarchical fashion, with the first

data flow model (level 0 DFD) representing the system as a whole

Creating a data flow model

The DFD enables you to develop models of the information domain

and functional domain at the same time

Performing a grammatical parse on the processing narrative can

generate useful info about how to proceed As the DFD is refined into greater levels of detail, the analyst

performs an implicit functional decomposition of the system

Refine the DFDs until each bubble is single-minded

Creating a control flow model

Needed (in addition to the DFD) for applications that:

o are driven by events rather than datao produce control information rather than reports / displayso process info with heavy concern for time & performance

An event / control item is implemented as a Boolean value /discrete list of conditions (empty/full)

The control specification (CSPEC) Represents the behavior of the system in 2 different ways:

State diagram

o A sequential specification of behavior

Program activation table

o A combinatorial specification of behavior

The CSPEC describes behavior, but not the inner workings of theprocesses that are activated as a result of this behavior

The process specification (PSPEC)

Used to describe all flow modelprocesses that appear at the

final level of refinement The content can include:

o Narrative text

o Program design language (PDL) description of the algorithm

o Mathematical equations, tables, diagrams, charts

By providing a PSPEC to accompany each bubble in the flow model,

you crate a mini-spec that can serve as a guide for design of

the software component that will implement the process

31


32/57

Class-based modelingIdentifying analysis classes

Examine the problem statement and perform a grammatical parse on

the use-cases or processing narratives developed for the system

6 selection characteristics when considering potential classes:

1. Retained information

o Must class info be rememberedfor the system to function?

2. Needed serviceso Are there operations that can change the attribute values?

3. Multiple attributes

o A 1-attribute class should be an attribute of another class

4. Common attributes

o Can attributes be applied to all instances of the class?5. Common operations

o Can operations be applied to all instances of the class?6. Essential requirements

o External entities that produce / consume info essential tothe systems operation will always be defined as classes

A potential class should satisfy all the above characteristics

Specifying attributes

Study a use-case and select things that belong to the class

Ask: What data items define this class in the problem context?

Defining operations

1. Operations thatmanipulate data (E.g. add, delete, select)2. Operations that perform a computation3. Operations that inquire about the objects state4. Operations thatmonitor an object for the occurrence of an event

The grammatical parse is again studied and verbs are isolated

CRC modeling

Class: FloorPlan

(Description)

Responsibility: Collaborator:

Defines floor plan name/type

Incorporates walls, doors and windows Wall

Shows position of video cameras Camera

Classes

Entity classes (model / business classes)

o Come directly from theproblem statement (e.g. FloorPlan)o Typically represent things to be stored in a database

o Persist throughout the duration of the application

Boundary classes

o Used to create the interface (e.g. interactive screen)o Manage the way entity objects arepresentedto the user

Controller classes

o Manage a unit of work from start to finish:

The creation / update of entity objects

32


33/57

The instantiation of boundary objects

Complex communication between sets of objects

Validation of data communicated between objects

o Generally not considered until design has begun

Responsibilities (attributes & operations)

Guidelines for allocating responsibilities:

1. System intelligence should be distributedacross classes

o If dumb classes are servants to smart classes

It concentrates all intelligence within a few classes,

making changes more difficult

It tends to require more classes, i.e. more effort

o If a class has a very long list of responsibilities, this

is an indication of a concentration of intelligence

o In addition, the responsibilities should exhibit the same

level of abstraction

2. Each responsibility should be stated as generally as possibleo So that they can apply to all subclasses

3. Information & related behavior should reside in the same classo This achieves encapsulation a cohesive unit

4. Information about one thing should be localized with a single

class, not distributed across multiple classes

5. Share responsibilities among related classes, when appropriate

o E.g. arms and legs collaborate with each other

Collaborators

Collaborations identify relationships between classes

First see whether a class can fulfill each responsibility itself

There are three different generic relationships between classes:

o Is-part-of relationship

Classes that are part of an aggregate class

o Has-knowledge-of relationship

When one class must acquire info from another class

o Depends-upon relationship

Other dependencies, e.g. head connected to body

When a complete CRC model has been developed it can be reviewed:

1. All participants in the review are given a subset of the cards

2. All use-case scenarios should be organized into categories

3. The review leader reads the use-case deliberately. As he comes

to a named class, he passes a token to the person holding the

corresponding class index card.

4. When the token is passed, the holder of the class card mustdescribe the responsibilities noted on the card

5. If the responsibilities and collaborations cannot accommodate

the use-case, modifications are made to the cards

Associations and dependencies

The difference between associations and dependencies:

An association defines a relationship between classes

A dependency relationship exists with clients & servers

Dependencies are defined by a stereotype

33


34/57

Stereotype = a UML extensibility mechanism that allows you todefine a special modeling element with custom-defined semantics

In UML stereotypes are represented in

Analysis packages

What is an analysis package and how might it be used?

o A package is used to assemble a collection of relatedclasses and other elements of the analysis model

Creating a behavioral model

The behavioral model indicates how software will respond to

external events or stimuli

To create the model, the analyst must perform these steps:

o Evaluate all use-cases to fully understand the sequence of

interaction within the system

o Identify events that drive the interaction sequence and

understand how these events relate to specific classes

o Create a sequence for each use-case

o Build a state diagram for the systemo Review the behavioral model to check accuracy & consistency

Identifying events with the use case

An event occurs whenever the system & actor exchange information

Note the info exchanged, and list any conditions / constraints

After identifying all events, allocate them to objects:

o Objects can generate eventso Objects can recognize events

State representations

Two different characterizations of states must be considered:

o The state of each class as the system performs its function

o The state of the system as observed from the outside as the

system performs its function

The state of a class takes on passive & active characteristics:

o Passive state = current status of an objects attributes

o Active state = current status of the object as it undergoes

a continuing transformation / processing

1. State diagrams for analysis classes

o Shows how a class changes state based on external eventso In addition to specifying the event that causes the

transition to occur, you can specify a guard and an action

o Guard= a Boolean condition that must be satisfied in orderfor the transition to occur

o Action = something that occurs concurrently with the statetransition or as a consequence of it

2. Sequence diagrams

o Shows the behavior of the software as a function of timeo Shows how events cause transitions from object to object

o After developing a complete sequence diagram, all of the

events that cause transitions between system objects can be

collated into a set of input events and output events

34


35/57

How a state diagram for analysis classes differs from the state

diagrams presented for the complete system:

o The state diagrams depicting the state behavior of a system

represent externally observable events and states.o State diagrams for analysis classes are a component of the

behavioral model and represent the states associated with a

specific analysis class.

Chapter 9 Design engineering

Design within the context of software engineering

Each element of the analysis model provides information

necessary to create the 4 design models required:

Data/class design

o Transforms analysis-class models into design class

realizations and data structures

Architectural design

o Defines the relationship between major structural elementsof the software, the architectural styles and design

patterns that can be used to achieve the requirements

Interface design

o Describes how the software communicates with systems that

interoperate with it, and with humans who use it

Component-level design

o Transforms structural elements of the software architecture

into a procedural description of software components

If a software design is not a program, then what is it?

o The intent of software design is to apply a set of

principles, concepts, and practices that lead to the

development of a high quality system. The goal of design is

to create amodel of software that will implement allcustomer requirements correctly and bring delight to users.

Do you design software when you write a program? What makes

software design different from coding?

o Yes, but the design is conducted implicitly often in a

haphazard manner. During design (in a software engineering

context) we develop representations (models) of programs

not the programs themselves.

Design process and design quality

Three characteristics that serve as a guide for the evaluation

of good design:

o The design must implement all of the explicit requirementscontained in the analysis model, and must accommodate all

of the implicit requirements desired by the customer

35


36/57


37/57


38/57

This makes them easier to maintain and test because error

propagation is reduced, and reuse is possible

Independence is assessed using two qualitative criteria:

o Cohesion

Indication of a modules relative functional strengtho Coupling

Indication of the interdependence among modules

Refinement

You develop a hierarchy by decomposing macroscopic functionsuntil reaching programming language statements

Refinement is actually a process of elaboration because youprovide more and more detail with each successive refinement

Abstraction and refinement are complementary concepts:

o Abstraction enables a designer to specify procedure anddata and yet suppress low-level details

o Stepwise Refinement helps the designer to reveal low-leveldetails as design progresses

Refactoring

Refactoring is a reorganization technique that simplifies thedesign of a component without changing its function / behavior

When software is refactored, the existing design is examined for

redundancy, unused design elements, inefficient algorithms, etc.

Design classes

Analysis classes represent objects, while design classes presentmore technical detail as a guide for implementation

The design classes must

o Refine the analysis classes by providing design detail thatwill enable the classes to be implemented

o Include new classes to implement a software infrastructure Five different types of design classes:

o User interface classes (E.g. elements of a metaphor)

o Business domain classes (refinements of analysis classes)

o Process classes (implement low-level business abstractions)

o Persistent classes (represent data stores)

o System classes (functions that enable the system to operate

& communicate within its computing environment & the world)

Four characteristics of a well-formed design class:

o Complete and sufficient (encapsulate all methods necessary

and nothing more)

o Primitiveness (methods should accomplish one service)o High cohesion

o Low coupling

The design model

Two dimensions of the design model:

o Process dimension

Indicates the evolution of the design model as design

tasks are executed as part of the software process

38


39/57

o Abstraction dimension

Represents the level of detail as each element of the

analysis model is transformed into a design equivalent

The elements of the design model use many of the same UML

diagrams that were used in the analysis model, but

o These diagrams are refined and elaborated

o More implementation-specific detail is provided

o Architectural structure and style are emphasizedo Interfaces between components are emphasized

Data design elements

Data design creates a model of data that is represented at a

high level of abstraction (the users view of data)

It is then refined into progressively more implementation-

specific representations that can be processed by the system

At the program component level

o Design of data structures & associated algorithms

At the application levelo Translation of a data model into a database

At the business level

o Data reorganized into a data warehouse enables data mining

Architectural design elements

The architectural model is derived from three sources:

o Information about the application domain

o Specific analysis model elements, like DFDs, their

relationships and collaborations for the problem

o The availability of architectural patterns and styles

Interface design elements

These elements tell how information flows into and out of the

system and how it is communicated among the components

Three important elements of interface design:

o The user interface

o External interfaces to other systems

Collect this info during requirements engineering

Incorporate error checking and security features

o Internal interfaces between various design components

Design realizations of analysis classes show messaging

Each message must be able to perform the info transfer

Component-level design elements Component-level design fully describes the internal detail of

each software component

Component-level design defines

o Data structures for all local data objectso Algorithmic detail for all processingo An interface that allows access to all component operations

The design details of a component can be modeled at many

different levels of abstraction:

39


40/57

o Activity diagram to represent processing logic

o Pseudo code to represent detailed procedural flow

Deployment-level design elements

Indicate how software functionality and subsystems will be

allocatedwithin thephysical computing environment

Deployment diagrams show computing elements, with subsystems

o Descriptor form

No explicit indication of configuration detailso Instance form

Later stages of design with details

Pattern-based software designDescribing a design pattern

Design pattern template:

Pattern name Describes theessence of the

pattern

Structure The classes toimplement the

pattern

Intent What the pattern

does

Participants The

responsibilitiesof the classes

Also known as Synonyms Collaborations How theparticipants

collaborate

Motivation An example of theproblem

Consequences Trade-offs toconsider

Applicability Specific designsituations where

it is applicable

Related patterns Cross-referencesrelated design

patterns

A description of the design pattern may also consider a set of

design forces, that describe nonfunctional requirements Forces define the constraints that restrict the implementation

Pattern characteristics indicate the design attributes that maybe adjusted to allow the pattern to accommodate various problems

Guidance associated with the use of a design pattern provides anindication of the ramifications of design decisions

Using patterns in design

Architectural patterns

o Define the overall structure of the software

o Indicate relationships among subsystems & components

Design patternso Address a specific element of the design

o E.g. an aggregation of components to solve a problem,

relationships among components, communication mechanisms

Idioms (coding patterns)

o Implement an algorithmic element of a component, a specific

interface protocol, or a communication mechanism

Each of these pattern types differs in the

o Level of abstraction with which it is represented

40


41/57

o Degree to which it provides guidance for construction

Frameworks

Definition: an implementation-specific skeletal infrastructure

The skeleton has a collection of plug points that enable it tobe adapted to a specific problem domain

The plug points enable a designer to integrate problem specific

classes or functionality within the skeleton

OO context: a framework is a collection of cooperating classes

To be most effective, frameworks are applied with no changes

Additional design elements may be added, but only via the plug

points that allow the designer to flesh out the skeleton

Chapter 10 Creating an architectural design

Software architectureWhat is architecture?

Definition: The structure of the system, which comprises:o Software components,

o the externally visible properties of those componentso and the relationships among them

Architecture is a representation that lets a software engineer:o Analyze the effectiveness of the design in meeting its

stated requirements

o Consider architectural alternatives at a stage when making

design changes is still relatively easy

o Reduce the risks associated with constructing software

The definition emphasizes the role of software components in

any architectural representation

A software component can be a program module / OO class /

databases / middleware Architecture design considers two levels of the design pyramid:

o Data design

Class definitions in OO systems

o Architectural design

Focuses on the representation of the structure of

software components, their properties, & interactions

Why is architecture important?

1. Enables communication between all stakeholders2. Highlights early design decisions that will have a profound

impact on all SE work that follows

3. Constitutes a relatively small, graspable model of how thesystem is structured and how its components work together

Data design

Data design translates data objects defined as part of theanalysis model into data structures at the software componentlevel and a database architecture at the application level

Data design at the architectural level

41


42/57

Data mining techniques / KDB (knowledge discovery in databases)navigate through existing databases to extract appropriate info

Data mining is difficult in an existing database environment, so

a data warehouse adds an additional layer to the architecture

Documents

INF305 Notes (Pressman)