Term Paper of Software Engineerinng

8/4/2019 Term Paper of Software Engineerinng

http://slidepdf.com/reader/full/term-paper-of-software-engineerinng 1/37

1 | P a g e

LOVELY PROFESSIONAL

UNIVERSITY

CSE-314

ISSUES IN DESIGN OF LARGESOFTWARE

Submitted to: Submitted by:

Mrs. Harjinder Kaur SURENDRA

MCA 2nd SEM

*roll no D3804B51

*Regd. no 10806601



2 | P a g e

ACKNOWLEDGMENT

I have the honor to express our gratitude to our Mrs.Herjinder Kaur for their timely help, support encouragement, valuable comments, suggestions andmany 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 constantencouragement and support throughout the execution of this project.

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

SURENDRA SINGH



3 | P a g e

TABLE OF CONTENTSHistory of software design

What is software design and why is itimportant?

Design Specification Models

Design Principles

Fundamental Software Design Concepts

Software architecture and larger designissues

Software control

Control implementation strategies Issues in Developing Large Software Systems

The origin of software architecture

Designing Large software architecture

Some possible views of architecture are:

• Functional/logic view

• Code/module view

• Development/structural view

• Concurrency/process/thread view



4 | P a g e

• Physical/deployment view

• User action/feedback view

• Data view

• Examples of Architectural Styles/Patterns

• Architecture frame work

• Example system-design decisions

• Example concern: Concurrency



5 | P a g e



6 | 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 anexplicit 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

http://wiki/Edsger_Dijkstra

http://wiki/David_Parnas





7 | P a g e

concentrating on architectural styles ( patterns), architecture description

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, developingalgorithms, 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

http://wiki/Patterns

http://wiki/Software_component

http://wiki/University_of_California,_Irvine

http://wiki/Computer_science

http://wiki/Separation_of_concerns








8 | P a g e

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

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

http://wiki/Wikipedia:Avoid_weasel_words

http://wiki/Abstraction_(computer_science)

http://wiki/Ilities

http://wiki/Wikipedia:Citation_needed

http://wiki/Wikipedia:Avoid_weasel_words

http://wiki/Abstraction_(computer_science)

http://wiki/Ilities




9 | P a g e

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.

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 qualityagainst 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, theapproach 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



10 | P a g e

requirements can be accurately translated into a finished

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 aretransformed 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



11 | P a g e

structures required to implement the software. Part of the

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 architectureinto 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



12 | P a g e

of the entire package. Algorithm description and other relevant

information may be included as an appendix.

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.



13 | P a g e

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

tracking how the requirements have been satisfied by themodel

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 integratingthose 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, evenwith bad data, events, or operating conditions are

encountered – Well-designed software should never

“bomb”. It should be designed to accommodate unusual



14 | P a g e

circumstances, and if it must terminate processing, do so in

a graceful manner.

7. The design should be reviewed to minimize conceptual

(semantic) errors – there is sometimes the tendency tofocus 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 whendetailed 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 importantto the software engineer) more so the quality of the design itself.

To achieve internal quality factors the designer must understand

basic design concepts.



15 | 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 intoindividual 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



16 | P a g e

• Software architecture - overall structure of the software

components and the ways in which that structure provides

conceptual integrity for a system

• Control hierarchy or program structure - represents themodule 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



17 | P a g e

Software architecture and larger design issues:

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 analysiso 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



18 | P a g e

Rather, application methods are “called back” to

handle external events

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



19 | 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 differentparts of the code that will work together

• How do we make sure that the software does what

it is supposed to do?



20 | P a g e

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

the software ?

• 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





21 | P a g e

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 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



http://wiki/Client-Server

http://wiki/Peer-to-peer







22 | P a g e

have to give yourself time to do

that.

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

http://wiki/View_model

http://wiki/Blueprint

http://wiki/Architecture

http://wiki/IEEE_1471

http://wiki/View_model






23 | P a g e

concerns.

• 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

http://wiki/Stakeholder_(general)






24 | P a g e

problems of complexity were solved by developers by choosing

the right data structures, developing algorithms, and by applying

the concept of separation of concernsYou 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.


http://w/index.php?title=Intension/Locality_Hypothesis&action=edit&redlink=1

http://w/index.php?title=Locality_Criterion&action=edit&redlink=1








25 | P a g e

You should have basic understanding of computer architecture

and layout, what memory really

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), theanalysis 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.



26 | P a g e

The software architecture of a program or computing system is

the structure or structures of the system, which comprise

software components, the externally visible properties of thosecomponents, 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,

http://wiki/Software_system


http://wiki/Software_system




27 | P a g e

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. 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

http://wiki/Ilities



http://wiki/Ilities





28 | P a g e

( patterns), architecture description languages, architecture

documentation, and formal methods.

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)















29 | P a g e

are:

• Functional/logic view

• 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 wasestablished 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

http://wiki/Unified_Modeling_Language

http://wiki/Standardization

http://wiki/Notational_bias


http://wiki/Programming_language

http://wiki/Unified_Modeling_Language

http://wiki/Standardization

http://wiki/Notational_bias


http://wiki/Programming_language



30 | P a g e

succession of failed attempts to impose a single 'universal

language' on programmers, as proof that software thrives on

diversity and not on standards.

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

http://wiki/Programming_paradigms

http://wiki/Component-based_software_engineering


http://wiki/Design_patterns

http://wiki/Architectural_pattern_(computer_science)

http://wiki/Programming_idioms


http://wiki/Refactorings






http://wiki/Programming_paradigms



http://wiki/Design_patterns

http://wiki/Architectural_pattern_(computer_science)



http://wiki/Refactorings








31 | P a g e

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

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

http://wiki/Blackboard_(computing)

http://wiki/Client-server

http://wiki/Database-centric_architecture

http://wiki/Distributed_computing

http://wiki/Event_Driven_Architecture

http://wiki/Front-end_and_back-end

http://wiki/Blackboard_(computing)

http://wiki/Client-server

http://wiki/Database-centric_architecture

http://wiki/Distributed_computing

http://wiki/Event_Driven_Architecture

http://wiki/Front-end_and_back-end



32 | P a g e

• Implicit invocation

• Monolithic application

• 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)

http://wiki/Implicit_invocation

http://wiki/Monolithic_application


http://wiki/Department_of_Defense_Architecture_Framework

http://wiki/MODAF

http://wiki/TOGAF

http://wiki/Zachman_framework

http://wiki/Federal_Enterprise_Architecture

http://wiki/RM-ODP

http://wiki/Service-Oriented_Modeling

http://wiki/Implicit_invocation

http://wiki/Monolithic_application


http://wiki/Department_of_Defense_Architecture_Framework

http://wiki/MODAF

http://wiki/TOGAF

http://wiki/Zachman_framework

http://wiki/Federal_Enterprise_Architecture

http://wiki/RM-ODP

http://wiki/Service-Oriented_Modeling



33 | P a g e

Example system-design decisions

Choose system performance constraints

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



34 | P a g e

a service over the network. This manager must notify scrollbar

and viewport when a new line is read from network.

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)



35 | P a g e

Physical Design Issues for Large, GrowingDatabase 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 takeinto 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 tryingto 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



36 | P a g e

where the data is to be stored, and their view ends at the table level.

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 systemsthat 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.



37 | P a g e

Documents

Term Paper of Software Engineerinng