1 | P a g e

L OVELY P ROFESSIONAL

U NIVERSITY

CSE-314

ISSUES IN DESIGN OF LARGE SOFTWARE

Submitted to:- Submitted by:-

Mrs. Harjinder Kaur NAME:- AJAY KUMAR

REG:-11009446

ACKNOWLEDGMENT

2 | P a g e

I have the honor to express our gratitude to our Mrs.Herjinder Kaur for their timely help, support encouragement, valuable comments, suggestions and many innovative ideas in carrying out this project. It is great for me to gain out of their experience. I also owe overwhelming debt to my classmates for their constant encouragement and support throughout the execution of this project.

Above all, consider it a blessing of the Almighty God that i have been able to complete this project. His contribution towards every aspect of ours throughout our life would always be the supreme and unmatched.

Ajay kumar

TABLE OF CONTENTS

3 | P a g e

History of software design

What is software design and why is it important?

Design Specification Models

Design Principles

Fundamental Software Design Concepts

Software architecture and larger design issues

Software control

Control implementation strategies

4 | P a g e

History

A critical aspect of the design for any large software system is its gross

structure represented as a high-level organization of computational

elements and interactions between those elements. Broadly speaking,

this is the software architectural level of design. The structure of

software has long been recognized as an important issue of concern.

However, recently software architecture has begun to emerge as an

explicit field of study for software engineering practitioners and

researchers. Evidence of this trend is apparent in a large body of recent

work in research such as module interface languages, domain specific

architectures, architectural description languages, design patterns and

handbooks, formal underpinnings for architectural design, and

architectural design environments. This IEEE Transactions on Software

Engineering Special Issue on Software Architecture presents seven

papers that illustrate many of these emerging research areas

The origin of software architecture as a concept was first identified in

the research work of Edsger Dijkstra in 1968 and David Parnas in the

early 1970s. These scientists emphasized that the structure of a software

system matters and getting the structure right is critical. The study of the

field increased in popularity since the early 1990s with research work

concentrating on architectural styles (patterns), architecture description

5 | P a g e

languages, architecture documentation, and formal method.

Research institutions have played a prominent role in furthering software

architecture as a discipline. Mary Shaw and David Garlan of

Carnegie Mellon wrote a book titled Software Architecture:

Perspectives on an Emerging Discipline in 1996, which brought

forward the concepts in Software Architecture, such as components,

connectors, styles and so on. The University of California, Irvine's

Institute for Software Research's efforts in software architecture research

is directed primarily in architectural styles, architecture description

languages, and dynamic architectures.

The field of computer science has come across problems associated with

complexity since its formation. Earlier problems of complexity were

solved by developers by choosing the right data structures, developing

algorithms, and by applying the concept of separation of concerns.

Although the term “software architecture” is relatively new to the

industry, the fundamental principles of the field have been applied

sporadically by software engineering pioneers since the mid 1980s.

Early attempts to capture and explain software architecture of a system

were imprecise and disorganized, often characterized by a set of box-

and-line diagrams. During the 1990’s there was a concentrated effort to

define and codify fundamental aspects of the discipline. Initial sets of

design patterns, styles, best practices, description languages, and formal

logic were developed during that time.[who?] The software architecture

6 | P a g e

discipline is centered on the idea of reducing complexity through

abstraction and separation of concerns. To date there is still no

agreement on the precise definition of the term “software architecture”.

As a maturing discipline with no clear rules on the right way to build a

system, designing software architecture is still a mix of art and science.

The “art” aspect of software architecture is because a commercial

software system supports some aspect of a business or a mission. How a

system supports key business drivers is described via scenarios as non-

functional requirements of a system, also known as quality attributes,

determine how a system will behave. Every system is unique due to the

nature of the business drivers it supports, as such the degree of quality

attributes exhibited by a system such as fault-tolerance, backward

compatibility, extensibility, reliability, maintainability, availability,

security, usability, and such other –ilities will vary with each

implementation.

To bring a software architecture user's perspective into the software

architecture, it can be said that software architecture gives the direction

to take steps and do the tasks involved in each such user's speciality area

and interest e.g. the stake holders of software systems, the software

developer, the software system operational support group, the software

maintenance specialists, the deployer, the tester and also the business

end user[citation needed]. In this sense software architecture is really the

amalgamation of the multiple perspectives a system always embodies.

7 | P a g e

The fact that those several different perspectives can be put together into

a software architecture stands as the vindication of the need and

justification of creation of software architecture before the software

development in a project attains maturity.

What is software design and why is it important?

A software design is a meaningful engineering representation of some software product that is to be built. A design can be traced to the customer's requirements and can be assessed for quality against predefined criteria. In the software engineering context, design focuses on four major areas of concern: data, architecture, interfaces and components.

The design process is very important. From a practical standpoint, as a labourer, one would not attempt to build a house without an approved blueprint thereby risking the structural integrity and customer satisfaction. In the same manner, the approach to building software products is no different. The emphasis in design is on quality; this phase provides us with representation of software that can be assessed for quality. Furthermore, this is the only phase in which the customer’s requirements can be accurately translated into a finished

8 | P a g e

software product or system. As such, software design serves as the foundation for all software engineering steps that follow regardless of which process model is being employed. Without a proper design we risk building an unstable system – one that will fail when small changes are made, one that may be difficult to test; one whose quality cannot be assessed until late in the software process, perhaps when critical deadlines are approaching and much capital has already been invested into the product.

During the design process the software specifications are transformed into design models that describe the details of the data structures, system architecture, interface, and components. Each design product is reviewed for quality before moving to the next phase of software development. At the end of the design process a design specification document is produced. This document is composed of the design models that describe the data, architecture, interfaces and components.

At the data and architectural levels the emphasis is placed on the patterns as they relate to the application to be built. Whereas at the interface level, human ergonomics often dictate the design approach employed. Lastly, at the component level the design is concerned with a “programming approach” which leads to effective data and procedural designs.

 

Design Specification Models Data design – created by transforming the analysis

information model (data dictionary and ERD) into data structures required to implement the software. Part of the

9 | P a g e

data design may occur in conjunction with the design of software architecture. More detailed data design occurs as each software component is designed.

Architectural design - defines the relationships among the major structural elements of the software, the “design patterns” than can be used to achieve the requirements that have been defined for the system, and the constraints that affect the way in which the architectural patterns can be applied. It is derived from the system specification, the analysis model, and the subsystem interactions defined in the analysis model (DFD).

Interface design - describes how the software elements communicate with each other, with other systems, and with human users; the data flow and control flow diagrams provide much of the necessary information required.

Component-level design - created by transforming the structural elements defined by the software architecture into procedural descriptions of software components using information obtained from the process specification (PSPEC), control specification (CSPEC), and state transition diagram (STD).

These models collectively form the design model, which is represented diagrammatically as a pyramid structure with data design at the base and component level design at the pinnacle. Note that each level produces its own documentation, which collectively form the design specifications document, along with the guidelines for testing individual modules and the integration of the entire package. Algorithm description and other relevant information may be included as an appendix.

10 | P a g e

Design Principles

Software design can be viewed as both a process and a model.

“The design process is a sequence of steps that enable the designer to describe all aspects of the software to be built. However, it is not merely a cookbook; for a competent and successful design, the designer must use creative skill, past experience, a sense of what makes “good” software, and have a commitment to quality.

The design model is equivalent to the architect’s plans for a house. It begins by representing the totality of the entity to be built (e.g. a 3D rendering of the house), and slowly refines the entity to provide guidance for constructing each detail (e.g. the plumbing layout). Similarly the design model that is created for software provides a variety of views of the computer software.” – adapted from book by R Pressman.

 

The set of principles which has been established to aid the software engineer in navigating the design process are:

1.      The design process should not suffer from tunnel vision – A good designer should consider alternative approaches. Judging each based on the requirements of the problem, the resources available to do the job and any other constraints.

2.      The design should be traceable to the analysis model – because a single element of the design model often traces to multiple requirements, it is necessary to have a means of

11 | P a g e

tracking how the requirements have been satisfied by the model

3.      The design should not reinvent the wheel – Systems are constructed using a set of design patterns, many of which may have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited! Design time should be invested in representing truly new ideas and integrating those patterns that already exist.

4.      The design should minimise intellectual distance between the software and the problem as it exists in the real world – That is, the structure of the software design should (whenever possible) mimic the structure of the problem domain.

5.      The design should exhibit uniformity and integration – a design is uniform if it appears that one person developed the whole thing. Rules of style and format should be defined for a design team before design work begins. A design is integrated if care is taken in defining interfaces between design components.

6.      The design should be structured to degrade gently, even with bad data, events, or operating conditions are encountered – Well-designed software should never “bomb”. It should be designed to accommodate unusual circumstances, and if it must terminate processing, do so in a graceful manner. 

12 | P a g e

7.      The design should be reviewed to minimize conceptual (semantic) errors – there is sometimes the tendency to focus on minute details when the design is reviewed, missing the forest for the trees. The designer team should ensure that major conceptual elements of the design have been addressed before worrying about the syntax if the design model.

8.      Design is not coding, coding is not design – Even when detailed designs are created for program components, the level of abstraction of the design model is higher than source code. The only design decisions made of the coding level address the small implementation details that enable the procedural design to be coded.

9.      The design should be structured to accommodate change

10.  The design should be assessed for quality as it is being created

When these design principles are properly applied, the design exhibits both external and internal quality factors. External quality factors are those factors that can readily be observed by the user, (e.g. speed, reliability, correctness, usability). Internal quality factors relate to the technical quality (which is important to the software engineer) more so the quality of the design itself. To achieve internal quality factors the designer must understand basic design concepts.

 

13 | P a g e

Fundamental Software Design Concepts

A set of fundamental software design concepts has evolved over the past four decades, each providing the software designer with a foundation from which more sophisticated design methods can be applied. Each concept helps the soft ware engineer to answer the following questions:

1. What criteria can be used to partition software into individual components?

2. How is function or data structure detail separated from a conceptual representation of software?

3. Are there uniform criteria that define the technical quality of a software design?

The fundamental design concepts are:

Abstraction - allows designers to focus on solving a problem without being concerned about irrelevant lower level details (procedural abstraction - named sequence of events, data abstraction - named collection of data objects)

Refinement - process of elaboration where the designer provides successively more detail for each design component

Modularity - the degree to which software can be understood by examining its components independently of one another

Software architecture - overall structure of the software components and the ways in which that structure provides conceptual integrity for a system

14 | P a g e

Control hierarchy or program structure - represents the module organization and implies a control hierarchy, but does not represent the procedural aspects of the software (e.g. event sequences)

Structural partitioning - horizontal partitioning defines three partitions (input, data transformations, and output); vertical partitioning (factoring) distributes control in a top-down manner (control decisions in top level modules and processing work in the lower level modules). [Follow the link for more details on these concepts]

Data structure - representation of the logical relationship among individual data elements (requires at least as much attention as algorithm design)

Software procedure - precise specification of processing (event sequences, decision points, repetitive operations, data organization/structure)

Information hiding - information (data and procedure) contained within a module is inaccessible to modules that have no need for such information

 

Software architecture and larger design issues :

15 | P a g e

o Strategic design decisions that influence a host of smaller, more tactical design decisions

E.g., policy for persistence of data in long-running system

E.g., allocating functionality to a single, centralized system vs. distributing functionality among a collection of communicating hosts

o Often involve a major capital investment o Source of both risk and opportunity o Require lots of a priori modeling and analysis o Focus: Design issues related to concurrent and

distributed systems

 Software control  

Styles of control in a program

o Procedural: Control resides in “application code”

Requests for resources block until resource available

 

o Event-driven: Control resides in a central dispatcher

Application code does not explicitly requests resources

Rather, application methods are “called back” to handle external events

16 | P a g e

E.g., mouse clicks, key presses, network traffic, etc.

 

o Concurrent: Multiple simultaneous threads of control

New problems to contend with: synchronization

Active vs. passive objects

Control implementation strategies  

Event-driven sequential: Central dispatcher invokes registered objects to service asynchronous events 

Time-sliced multiplexing:

o Scheduler activates each active object in sequence and periodically preempts one actor to schedule another

o Generally requires operating-system support o Thread: “Lightweight process”; essentially a unit of

time-sliced multiplexing within a sequential process

 

Multi-process: Active objects associated with operating-system processes

17 | P a g e

Issues in Developing Large Software Systems

• A single software developer may not be

able to do the job in the required amount of

time, developers have to work as a team

• The team members have to communicate

and interact with each other

• Specification of a large software product is

more complicated than just saying “write a

program that sorts a set of integers”

• For a large software project one has to carefully

think about the design of the software before

starting to write code

• A team of programmers have to write different

parts of the code that will work together

• How do we make sure that the software does what

it is supposed to do?

• What happens if we need to add a new feature to

the software ?

18 | P a g e

The origin of software architecture

The origin of software architecture as a concept was first

identified in the research work of Edsger Dijkstra in 1968 and

David Parnas in the early 1970s. These scientists emphasized

that the structure of a software system matters and getting the

19 | P a g e

structure right is critical. The study of the field increased in

popularity since the early 1990s with research work

concentrating on architectural styles (patterns), architecture

description languages, architecture documentation, and formal

methods.

No. Well... [thinks] Nope, still no.

The projects seem big. Sometimes overwhelmingly so, some

people report staying up nights and weekends to get everything

done. And you may find yourself going “I don’t know where to

even start!” But that’s exactly why you should start early. I’m

not kidding. The easiest way to. For example, the Client-Server

style is architectural (strategic) because a program that is built

by this principle can be expanded into a program which is not

client server; for example, by adding peer-to-peer nodes. Or

more simply, it is the distinction of the general from the specific.

bottom out in CS351 is to procrastinate and not give yourself

time to really think. Some of these

problems you need to sleep on to see the right way to do it. You

have to give yourself time to do

that.

20 | P a g e

You also need to give yourself time to write all the lines of code.

This class isn’t really about

turning out large volumes of code. It’s about turning out the

right code. But even if you have a

beautiful, elegant, concise design, there are still a lot of lines to

write. You can’t do it in one night.

(Ok, nobody I know has ever done it in one night. Successfully,

anyway.)

If you start early, think carefully, and realize when you need to

back up rather than forging

ahead, then you should be able to finish everything without

staying up nights and Sundays.

Well. Not very many nights, anyway.

Software architecture is commonly organized in views [8] , which

are analogous to the different types of blueprints made in

building architecture. Within the ontology established by

ANSI/IEEE 1471-2000, views are instances of viewpoints,

where a viewpoint exists to describe the architecture in question

from the perspective of a given set of stakeholders and their

concerns.

21 | P a g e

Designing Large software architecture

Basic Designing software architecture Be capable of:

• Writing a program of between 100 and 500 lines of code,

including more than one class/module

• Compiling it

• Running it

• Debugging it (!)

• Basic performance testing. The term also refers to

documentation of a system's software architecture. Documenting

software architecture facilitates communication between

stakeholders, documents early decisions about high-level design,

and allows reuse of design components and patterns between

projects. The field of computer science has come across

problems associated with complexity since its formation. Earlier

problems of complexity were solved by developers by choosing

the right data structures, developing algorithms, and by applying

22 | P a g e

the concept of separation of concerns

You should be familiar with all of the basic Java syntax and

semantics: built-in data types,

variable declaration, boolean and bitwise operators, control flow

structures (if, while, exceptions,

iteration), method definition, etc. In addition, you should have

be familiar with some of the structures

in the Java standard library (especially java.util) and I/O via

java.io.

Of course, you also need basic familiarity with tools — editor,

compiler, the UNIX operatingAccording to the

Intension/Locality Hypothesis [9] , the distinction between

strategic and tactical design is defined by the Locality

Criterion [9] , according to which a statement about software

design is non-local if and only if a program that satisfies it can

be expanded into a program which does not

system, jar, etc. Knowing your way around some form of

scripting (sh, perl, python, etc.) would

also be helpful, but is not required.

You should have basic understanding of computer architecture

and layout, what memory really

23 | P a g e

means, and so on.

You can’t neglect the theory part of the curriculum. Hacking

isn’t just about churning out

code — you need to understand the first principles in order to

write the right code. You should

be familiar with asymptotic analysis (big-O notation), the

analysis and properties of basic data

structures (lists, trees, hash tables, finite state machines, etc.)

and algorithms (sorting, searching,

string matching, etc.).

In UNM course terms, that means, basically, CS151, CS251,

CS261, CS241, and CS361.

CS341 and CS257 are useful to know as well, but not critical

software

Finally, you need to be able to write protracted descriptive text

in English, including correct

spelling, grammar, and usage.

The software architecture of a program or computing system is

the structure or structures of the system, which comprise

24 | P a g e

software components, the externally visible properties of those

components, and the relationships between them. The term also

refers to documentation of a system's software architecture.

Documenting software architecture facilitates communication

between stakeholders, documents early decisions about high-

level design, and allows reuse of design components and

patterns between projects.

As a maturing discipline with no clear rules on the right way to

build a system, designing software architecture is still a mix of

art and science. The “art” aspect of software architecture is

because a commercial software system supports some aspect of

a business or a mission. How a system supports key business

drivers is described via scenarios as non-functional requirements

of a system, also known as quality attributes, determine how a

system will behave. Every system is unique due to the nature of

the business drivers it supports, as such the degree of quality

attributes exhibited by a system such as fault-tolerance,

backward compatibility, extensibility, reliability,

maintainability, availability, security, usability, and such other –

25 | P a g e

ilities will vary with each implementation.

To bring a software architecture user's perspective into the

software architecture, it can be said that software architecture

gives the direction to take steps and do the tasks involved in

each such user's speciality area and interest e.g. the stake holders

of software systems, the software developer, the software system

operational support group, the software maintenance specialists,

the deployer, the tester and also the business end user[citation

needed]. In this sense software architecture is really the

amalgamation of the multiple perspectives a system always

embodies. The fact that those several different perspectives can

be put together into a software architecture stands as the

vindication of the need and justification of creation of software

architecture before the software development in a project attains

maturity.

The study of the field increased in popularity since the early

1990s with research work concentrating on architectural styles

(patterns), architecture description languages, architecture

documentation, and formal methods.

26 | P a g e

Research institutions have played a prominent role in furthering

software architecture as a discipline. Mary Shaw and David

Garlan of Carnegie Mellon wrote a book titled Software

Architecture: Perspectives on an Emerging Discipline in 1996,

which brought forward the concepts in Software Architecture,

such as components, connectors, styles and so on. The

University of California, Irvine's Institute for Software

Research's efforts in software architecture research is directed

primarily in architectural styles, architecture description

languages, and dynamic architectures.

Software architecture is commonly organized in views, which

are analogous to the different types of blueprints made in

building architecture. Within the ontology established by

ANSI/IEEE 1471-2000, views are instances of viewpoints,

where a viewpoint exists to describe the architecture in question

from the perspective of a given set of stakeholders and their

concerns.

Some possible views (actually, viewpoints in the 1471 ontology)

are:

Functional/logic view

27 | P a g e

Code/module view

Development/structural view

Concurrency/process/thread view

Physical/deployment view

User action/feedback view

Data view

Several languages for describing software architectures have

been devised, but no consensus has yet been reached on which

symbol-set and view-system should be adopted. The UML was

established as a standard "to model systems (and not just

software)," and thus applies to views about software

architecture. Others believe that effective development of

software relies on understanding unique constraints of each

problem, and so universal notations are doomed because each

provides a notational bias that necessarily makes the notation

useless or dangerous for some set of tasks[citation needed].

They point to the proliferation of programming languages and a

succession of failed attempts to impose a single 'universal

language' on programmers, as proof that software thrives on

diversity and not on standards.

28 | P a g e

Software architecture, also described as strategic design, is an

activity concerned with global design constraints, such as

programming paradigms, architectural styles, component-based

software engineering standards, design principles, and law-

governed regularities. Detailed design, also described as tactical

design, is an activity concerned with local design constraints,

such as design patterns, architectural patterns, programming

idioms, and refactorings. According to the Intension/Locality

Hypothesis [9] , the distinction between strategic and tactical

design is defined by the Locality Criterion [9] , according to

which a statement about software design is non-local if and only

if a program that satisfies it can be expanded into a program

which does not. For example, the Client-Server style is

architectural (strategic) because a program that is built by this

principle can be expanded into a program which is not client

server; for example, by adding peer-to-peer nodes. Or more

simply, it is the distinction of the general from the specific.

Architecture is design but not all design is architectural. In

practice, the architect is the one who draws the line between

29 | P a g e

software architecture (architectural design) and detailed design

(non-architectural design).

Examples of Architectural Styles / Patterns

There are many common ways of designing computer software

modules and their communications, among them:

Blackboard

Client-server (2-tier, n-tier, peer-to-peer, Cloud Computing

all use this model)

Database-centric architecture (broad division can be made

for programs which have database at its center and

applications which don't have to rely on databases, E.g.

desktop application programs, utility programs etc.)

Distributed computing

Event Driven Architecture

Front-end and back-end

Implicit invocation

Monolithic application

30 | P a g e

Peer-to-peer

Architecture frame work

Department of Defense Architecture Framework (DODAF)

UK Ministry of Defence Architectural Framework (MODAF)

The Open Group Architecture Framework (TOGAF)

Zachman framework

Federal Enterprise Architecture

Reference Model of Open Distributed Processing (RM-ODP)

Service-Oriented Modeling Framework (SOMF)

Example system- design decisions  

Choose system performance constraints

31 | P a g e

Organize system into subsystems

Identify concurrency and choose a strategy for implementing concurrent control

Choose a policy /mechanisms for managing persistent data

Make a reuse plan

Etc…

Example concern: Concurrency  

Many modern desktop applications perform multiple tasks concurrently

Lots of different ways to implement concurrency in an application

Each approach comes with its own set of costs and benefits

More important: Each approach can have a dramatic impact on how one designs every class in the system

Example:-

Suppose we want to replace the DocManager with a StreamManager, which continuously reads lines to display from a service over the network.  This manager must notify scrollbar and viewport when a new line is read from network. 

32 | P a g e

Task: Draw a sequence diagram that depicts what happens when the stream manager reads a new line from the network.

 

Solution sketch  

vp : … 

sb : … 

vpm : … 

sm : … 

announceNewValue(X) 

update() 

retrieve(0, ...) 

getLine(X, …) 

retrieve(n, ...) 

getLine(X+n, …) 

… 

announceNewValue(X) 

Physical Design Issues for Large, Growing

33 | P a g e

Database Systems

Databases are a lot like people. As they get older, they get fatter, slower, and less efficient. Their digital arteries get clogged with the accumulated results of years of operation and they can finally get to the point where they either stop working or work so slowly that their usefulness is compromised. As a courtesy to the reader and as a concession to my own circumferentially-challenged physique, I promise not to take this analogy any further!

Many issues arise because of initial design decisions that do not take into account future growth plans for the database. In the rush that often accompanies bringing a product to market, emphasis is often placed on getting the product out the door rather than taking the time to analyze and project what the database will look like one or two years after its installation.

Often software vendors consider these issues to belong to the customer rather than to the vendor. The problem is that by the time the customer is familiar enough with the product and aware of the magnitude of the data, it is a major undertaking to go back and fix the early setup and database layout problems. It is possible to make these types of changes to an existing system that is full of data, but it usually entails rebuilding very large tables. It makes a lot more sense for the designer to plan for the system's inevitable growth and to make the proper decisions at design time or at install time.

Some of the worst database design failures come when a vendor is trying to design an application that runs on multiple databases. Developers tend to view database systems as commodity "black boxes" that are totally interchangeable. Not knowing the database on which the system will be running means that they tend to view the database at the conceptual rather than at the physical level. They usually have no idea how or where the data is to be stored, and their view ends at the table level.

34 | P a g e

Anything else is usually considered to be the responsibility of the onsite database administrator (DBA).

This is totally wrong. You can see the results of this thinking in systems that choke after six months or one year of use. Any system can run well with very low data volumes. Only a system that has been designed with the physical data layout in mind can make the transition from small database to large database successfully.

Database designers usually do a fairly good job in the logical design of databases. Such areas as normalization and an indexing strategy tend to be fairly well understood. Where designers typically fall down is in the area of physical database design, especially in the areas of extent sizing and table design. This 10-Minute Solution shows you how to design your system properly so that these issues are addressed.

Your database is slowing down with age, probably as a result of poor physical design. How do you make your database handle larger volumes of data more efficiently?

Make these decisions about the physical design of your database system:

1. Estimate the future database's size and growth rate. 2. Size the computer and disk systems properly so they can handle

the data volume. 3. Design your tables with the physical layout and structure in mind. 4. Consider data archiving, purging, and cleaning as you design the

table structure.