Right Money Management App For Your Financial Goals
OOSE UNIT-1.pdf
1.
2.
3.
4. 20
Software Engineering: Definition
Software Engineering is a collection of techniques,
methodologies and tools that helps to produce a
high quality software system
• with a given budget
• before a given deadline
• Limited Resources
The Software Engineer using this limited amount of
resources and integrate several individual and
build high quality of Software System.
5. Software System Failures
• Interface Missing
• High Budget
• Time Exceeds
• User Interface Missing
• Poor Testing Process
• Availability
• Modifiability
• Extendibility
• Security
6. 1.1 What is Software Engineering or Definition
of Software Engineering
• Modelling Activity
• Problem Solving Activity
• Knowledge Acquisition Activity
• Rational Management Activity
7. Modelling Activity
• Pattern or Shape
• Abstraction Representation
• Easy understanding
• Avoid Complexity
• Answer several Questions
Two Mode:-
1.Application Domain Model or Problem Domain
Model
2.Solution Domain Model
8. Problem Solving Activity
• Formulate the problem
• Analyse the Problem
• Search for Solutions
• Pick the Solution
• Specify the Solution
11. 1.2 Software Engineering Development
Activities
• Requirements Engineering
• Analysis
• System Design or Software Design
• Implementation
• Testing
12. Requirements Engineering
• Clint and Developer define purpose and scope
In terms of Actors and Use Cases
• Actor is an External Entity that interact with the
System
• Use Case is Sequence of events that explain all
possible actions b/w Actor and System
Ex: Use Case PurchaseOneWayTicket
• These two also defined i.e Non-functional
Requirements and Pseudo Requirements in RE.
13. Use Case Name : PurchaseOneWayTicket
Participating Actors :Traveller communicates with TicketDistributor
Entry Condition :Traveller stand in front of TD Counter
located in station.
Flow of Events :1.Traveller know source & Destination
2.TD display the price of Ticket
3.Traveler insert money not less than the price
of ticket.
4.TD issue Ticket and return any excess of
change
Exit Condition :Traveller hold Ticket and leaves counter
Special Requirement :Transaction is not completed with in one
minute TD return all inserted amount.
fig1.2 Use Case for PurchaseOneWayTicket
14. Analysis
• Construct the model
• Object model for TicketDidtributor
Transaction Ticket Zone
Balance
Rupees
Coins
inserted
valid
tracks
results
Fig.(a)Object Model for TicketDistributor
15. System Design or Software Design
• System is decomposed it into Subsystems based on
design goals for each subsystem and select S/W & H/W
to implement each subsystem
• Specify Global Control flow, Access Control and
Boundary Conditions.
Fig(b)Subsystem Decomposition for PurchaseOneWayTicket
Notification Update
CentralDB
LocalDB
16. Implementation
• Means the developer write the code, the code
first compile then run.
Testing
• In testing each and every piece is tested then these
are integrated and test. Finally the entire system is
tested before giving it to the client.
17. 1.3 The Nature of Software
The Mechanical Engg. Build Mechanical System and Electrical Engg.
Build Electrical system and the software engg build Software
system but building software system is difficult because of
following Reasons:
• We cannot feel the shape of Software System and Diff. Visualize
• Difficult to estimate the time to complete
• Difficult to assist its quality
• Difficult estimate the cost because in other systems we can
estimate the cost by using each item cost multiplied total
number of items and number of labour required to build etc. But
in Software these is no concept of labour but piece of code is
available in Internet, we can change according our specification.
18. • Software doesn’t “wear out”.
Hardware components suffer from the growing effects of dust,
vibration, abuse, temperature extremes, and many other
environmental maladies, The hardware begins to wear out.
When a hardware component wears out, it is replace by a
spare part. In Software There are no software spare parts.
The Hardware Failure Curve (bathtub curve)and Software
Failure curves(idealized curve ).Undiscovered defects will cause
high failure rates early in the life of a program. However, these
are corrected (ideally, without introducing other errors) and
the curve flattens as shown.
19. • The other systems use Software system to automate the
Design Process, so that they reduce the Labour and improve
the quality.
• In reality most of the software systems are undelivered,
delivered late, delivered but never been used because of
large number of bugs. These are called as software crisis, the
Software System does not fall into these crisis. Therefore the
Software Engineer must know what is Software Engineering.
• The poorly trained software engineer build the software then
it is useless. The SE must trained in efficient manner, get
domain knowledge and good design knowledge to achieve
good quality of Software System.
20. 1.4 Types of Software
Types of Software Classified it into Three:
• Custom software
• Generic software
• Embedded software
Custom software : It is developed to meet the specific needs of a
particular customer and tends to be of little use to others .
Custom software is developed in-house within the same
organization that uses it;
Eg. Custom software include websites and software for managing
the finances of large organizations.
21. • Generic software : Designed to be sold on the open market and
to perform function on general-purpose computers that many
people need.
• Eg: generic software include word processors, spreadsheets,
compilers, web browsers, operating systems, computer games
and accounting packages for small businesses.
Embedded software:
• Runs specific hardware devices which are typically sold on the
open market. Such devices include washing machines,
microwave ovens and automobiles etc.. Unlike generic software,
users cannot usually replace embedded software or upgrade it
without also replacing the hardware.
22.
23. 1.5 Software Quality
Almost everybody says they want software to be of ‘high quality
The following fig. shows what quality means to each of the
stakeholders.
24. Software Quality depends on 5 Attributes
• Usability : The easier it is for users to work with it. There are
several aspects of usability, including learnability for novices,
efficiency of use for experts, and handling of errors.
• Efficiency : The more efficient software is, the less it uses of CPU-
time, memory, disk space, network bandwidth and other resources.
This is important to customers in order to reduce their costs of
running the software.
• Reliability : Software is more reliable if it has fewer failures.
Reliability depends on number and type of mistakes they make.
Designers can improve reliability by ensuring the software is easy to
implement and change.
• Maintainability : This is the ease with which you can change the
software. The more difficult it is to make a change , the lower the
maintainability. Software engineers can design highly maintainable
software by anticipating future changes and adding flexibility. It
reduces the cost for both developers and customers.
25. • Reusability : A software component is reusable if it can be
used in several different systems with little or no modification.
High reusability can reduce the long-term costs faced by the
development team.
26. 1.6 Introduction to Object-Orientation
• In earlier days Software Systems are build by using Procedural
Paradigm(PP) and Procedural Abstraction(PA).
• In PA consists of set of functions called from main() function this
approach is called as PP, it only suite for simple data if the data
is complex then we go for Data Abstraction(DA).
• DA can help reduce some of a system’s complexity. Records and
structures were the first data abstractions to be introduced. The
idea is to group together the pieces of data that describe some
entity, so that programmers can manipulate that data as a unit.
• Ex: banking system that is written using the procedural
paradigm, but using records representing bank accounts. The
software has to manage accounts of different types, such as
checking, savings and mortgage accounts. Each type of account
will have different rules for the computation of fees, interest,
etc.
27. Example of Pseudo cede PP
if account is of type checking then
do something
else if account is of type savings then
do something else
else
do yet another thing
end if
• Some of the persons have multiple accounts and each A/C has
different rates, Therefore it is difficult to implement it in
Procedure Paradigm then we go for Object-Oriented Paradigm
28. Object-Oriented Paradigm
• Implement the Real-Time Objects
• Problem is viewed as Run-time entities i.e objects, set of
objects are combined to form a class.
• In the procedural paradigm (shown on the left), the code is
organized into procedures that each manipulate different
types of data. In the object-oriented paradigm (shown on the
right), the code is organized into classes that each contain
procedures for manipulating instances of that class.
30. Features of OOP
• Object: Object is run-time entity it can represent real things, it can
also called as Instance of a class. Ex: Person, Customer, Bank
Account, Chair, Table, Car etc.
• Object consists of set of properties or attributes and action to
perform , action is nothing but operation. for ex car is object its
properties are color, capacity, price ,number of wheels etc. and
actions are stop(),start() and run().
Note: In UML Object is Represented by Colon( : ) and Underline(__)
31. • Class: The class consists of data members and members into a
single unit, Once the class is defined we can create any
objects belongs to particular class.
Employee
Name
DOB
Address
Position
Credit()
Debit()
Class name
Attributes
Actions or Methods
Employee Class in Banking System
32. Difference b/w PP and OOP
• PP system is implemented either operations oriented or data
oriented but not the both. OOP system is implemented both
• In PP the data is moved freely around the system.
Ex: Banking System implemented both
Credit()
AccNumber
Balance()
Fig(a)PP
Debit()
Credit()
AccNumber
Balance()
Debit()
Fig(b)OOP
message
message
message
33. Encapsulation
• Binding the data and its methods into a single unit
• Ex: Customer class in banking system
class Customer
{
private int AccNo=1234;
private String name=“ali”;
public void display()
{
System.out.println(“Accno=“+AccNo);
System.out.println(“Name=“+name);
}
}
Object Creation and method calling:
Customer c1=new Customer();
c1.display();
34. Data Abstraction
• Rep. Essential features without including background details,the
class consists of data abstraction technique.
• Ex. Car consists of internal parts like engine,radiator,mechanical
equipment, electrical equipment etc. the driver to drive a car it
requires only driving details not require the knowledge of internal
parts.
class bank
{
private int AccNo=1234;
private String name=“ali”;
private float bal=100000.10;
private float profit;
private float loan;
public void displayToClerk()
{
System.out.println(“Accno=“+AccNo);
System.out.println(“Name=“+name);
System.out.println(“Balance=“+bal);
}
}
35. Inheritance
• Reusability ,using the existing class we derive new class.
Several classes have attributes, associations or operations in
common, it is best to avoid duplication by creating a separate
super class that contains these common aspects. Conversely,
if you have a complex class, it may be good to divide its
functionality among several specialized subclasses.
38. class watch
{
private String time;
private String date;
public void setTime();
public void setDate();
public void readTime();
}
class calWatch extends watch
{
private String state;
public int Calculate(int n1,int n2)
{
return(n1+n2);
}
}
class test{
public static void main(String args[])
{
calWatch c1=new calWatch();
System.out.println(“sum=”+c1.Calculate(10,20);
}
}
39. Polymorphism
• Ability to take more than one form
• Classified it into Compile-Time and Run-Time
• The Object is linked for method at Compile Time then Compile-Time or
Early Binding this implemented by using method Overloading i.e
method name is same and it is used to perform more than one task.
Class sample
{
public int add(int a,int b)
{
return(a+b);
}
public int add(int c,int d,int e)
{
return(c+d+e);
}
public float add(float f, float g)
{
return(f+g);
}
}
Class test
{
public static void main(String args[])
{
sample s1=new sample();
System.out.println(s1.add(10,20));
System.out.println(s1.add(10,20,30));
System.out.println(s1.add(10.1,20.2));
}
}
40. Run-Time Polymorphism
• We create reference object using this we call different methods at
run-time .Simply we say that the Object is linked to the method at
run-time then it is called run-time Polymorphism.
class one
{
public void calculate(int x)
{
system.out.println(“square=“+x*x);
}
}
class two extends one
{
public void calculate(int x)
{
system.out.println(“cube=“+x*x*x);
}
}
Class test
{
public static void main(String args[])
{
one obj1=new one();
two obj2=new two();
one ref;
ref=obj1;
ref.calculate(2);
ref =obj2;
ref.calculate(2);
}
}
41. It refers to the process of defining, documenting and maintaining
requirements in the Software engineering Activity to develop high quality of
Software System. It is used to identify Functional, Non-functional & Pseudo
Req.
2.1 Domain Analysis or Knowledge
Domain analysis is the process by which a software engineer learns background
information. He or she has to learn sufficient information so as to be able to
understand the problem and make good decisions during requirements analysis and
other stages of the software engineering process.
Examples: Domains such as “ Reservation Systems”, “medical diagnosis”,“
financial ” and Telecommunications, Sales, Accounting etc.
The following are benefits if SE as Domain Knowledge:
• Faster development. You will be able to communicate with the stakeholders more
effectively, hence you will be able to establish requirements more rapidly..
• Better system. Ensure that the solutions you adopt will more effectively solve the
customer’s problem. You will make fewer mistakes, and will know which procedures
and standards to follow.
2.Requirements Engineering
42. • Future development. SE include feature requirements and how these
requirements are implemented.
The Entire domain information is documented then it is called as domain
analysis document it consists of following parameters .
•Introduction. Name the domain, and give the motivation for performing the
analysis. The motivation normally is that you are preparing to solve a particular
problem by development or extension of a software system.
•Glossary. Describe the meanings of all terms used in the domain that are
either not part of everyday language or else have special meanings.
•knowledge about the domain. Summarize important facts or rules that are
widely known by the domain experts and which would normally be learned as
part of their education. Such knowledge includes scientific principles, business
processes, analysis techniques, and how any technology works. This is an
excellent place to use diagrams.
•Customers and users. Describe who will or might buy the software, and in what
industrial sectors they operate. Also, describe the other people who work in the
domain, even peripherally.
43. •The Environment. Describe the equipment and systems used. The new system
or extensions will have to work in the context of this environment.
•Competing Software. Describe what software is available to assist the users
and customers, including software that is already in use, and software on the
market. Discuss its advantages and disadvantages.
44. 2.2 The Starting Point for Software Projects
• Most of SS are developed from beginning and in some SS
modify existing system to add new functionality
• SS Developer define all Requirements otherwise Client specify
requirements
• SS Categorised into four broad categories
45. 2.3 Defining Problem and Scope
The problem statement must be simple easy to understand and
must solve the business problem. The system scope must be
narrow if it is broad it must be divided it into narrow scope
subsystems.
OfferedCourses
Registration
FeePayment
Dues
ExamScheduale
RoomAllotment
ConductExams
Results
Fig(a)Broad Scope Examination System
47. 2.3 What is Requirement
• A requirement is a statement about what the proposed system
will do that all stakeholders agree must be agree must solve the
customer’s problem.
2.3.1 Functional requirements :
• Functional requirement that directly used in development of a
system without this we can’t develop the system, simply we can
say that it is essential to implement the system in other words,
they describe the services provided for the users and for other
systems.
48. The functional requirements also Specifies as following:
• What inputs the system should accept, and under what conditions. This
includes data and commands both from the users and from other systems.
• What outputs the system should produce, and under what conditions.
Outputs can be to the screen or printed.
• What data the system should store that other systems might use.
• What computations the system should perform. For example, you would
describe a sorting process by saying that the result is to be ordered in
ascending sequence according to the account number.
• The timing and synchronization of the above. Not all systems involve
timing and synchronization – this category of functional requirements is of
most importance in hard real-time systems that do such things as control
hardware devices (e.g. telecommunications systems, systems that control
power plants or factories, and systems that run automobiles and
airplanes).
49. Functional Requirements for an embedded software system that
allows a us to control a Microwave Oven
The system as a whole consists of Functional Req.:
• A keypad, with the following buttons that deliver an interrupt to
the software when they are pressed: 0 to 9, five power-level
buttons (‘hi’, ‘med-hi’, ‘med’, ‘med-low’, ‘low’), three temperature
buttons (‘frozen’, ‘refrigerated’, ‘room temperature’) , and five
action buttons (‘AUTO-DEFROST’, ‘AUTO-REHEAT’,‘START’, ‘CANCEL’
and ‘TIME OF DAY’).
• A door sensor that delivers an interrupt to the software when the
door is opened or closed
• A digital LCD display on which the system can display output.
• A sound generator that the system can use to generate various
tones.
50. The system can be in the following modes
• ‘idle’: this is initial state and entered when cooking is complete
or when ‘CANCEL’ is pressed.
• ‘accepting input’: here system accept the input by using
keyboard buttons.
• ‘cooking’: this is entered if the door is closed. This is exited when
the user opens the door or presses ‘cancel’.
• ‘suspended’: this is entered if the user opens the door while
cooking or user presses ‘cancel’ button.
51. The user specifies a valid cooking method in one of the following
ways (input):
• By pressing ‘AUTO-DEFROST’ followed by an optional
sequence of digits indicating the weight in pounds by using
keyboard buttons. If the user omits the weight, then the
default is 1 pound.
• By pressing ‘AUTO-REHEAT’ followed optionally by one of the
three temperature buttons. If the user omits the temperature,
the default is ‘refrigerated’.
• By pressing TIME-OF-DAY a sequence of up to five digits
indicating minutes and seconds. The last two digits are the
seconds, the previous digits (if any) are the minutes.
• Once user select the one of three cooking methods then user
press the START button then the will start cooking once it is
completed it will issue three beeps then the user press the
Power off button.
52. Non-functional Requirements:
• One of the most important things about non-functional
requirements is to make them verifiable, non-functional
requirements categorized into These groups.
Category1:Quality Requirements
These requirements constrain the design to meet specified levels
of quality.
•Response time : The system gives feedback to the user in a
certain minimum time
•Throughput : In terms of computations or transactions per
minute.
Resource usage : For systems that use non-trivial amounts of
such resources as memory and network bandwidth, you should
specify the maximum amount of these resources that the system
will consume.
53. Reliability : Reliability is measured as the average amount of time
between failures or the probability of a failure in a given period. It is a
good idea to set strong but realistic targets for this.
Availability. : Availability measures the amount of time that a server is
running and available to respond to users. As with reliability, you
should set a target for this. For example, you might specify that a
server must be available over 99% of the time.
Recovery from failure : They state that if the hardware or software
crashes, or the power fails, then the system will be able to recover
within a certain amount of time, and with a certain minimal loss of
data. For example, the system will allow users to continue their work
after a failure with the loss of no more than 20 words of typing or 20
formatting commands.
54. •Maintainability and Enhancement. In order to ensure that the system
can be adapted in the future, you should describe changes that are
anticipated for subsequent releases. This constrains design and
improves quality without adding explicit new functional requirements.
•Reusability. it is desirable in many cases to specify that a certain
percentage of the system.
•User Interface: Must consists of UI
•Security: High level security
•Error Handling: must handle errors
55. Category2:Platform requirements
This type of requirement constrains the environment and technology
of the system
Computing platform. It is normally important to make it clear what
hardware and operating system the software must be able to work on.
Technology to be used. While it is wise to give the designers as much
flexibility as possible in choosing how to implement the system,
sometimes constraints must be imposed.
56. Category3: Process Requirements
The final type of requirements constrains the project plan and
development methods:
Development process (methodology) to be used. In order to ensure
quality, some requirements documents specify that certain processes be
followed; for example, particular approaches to testing.
Cost and delivery date. These are important constraints. However, they
are usually not placed in the requirements document, but are found in
the contract for the system or are left to a separate project plan
document.
57. 2.4 Techniques for gathering and analyzing requirements :
• The following are techniques for gathering and
analyzing requirements:
• Observation : The first gathering technique,
observation, is used to obtain subtle information that
stakeholders may not think of telling. We can read
documents and discuss extensively with users, but
often only the process of observing the users at work
will bring to light subtle details the type might
otherwise miss. It can consume large amount of time.
58. • Interviewing : Interviewing is widely use technique.
Firstly, plan to have as many members of the software
engineering team interview as many stakeholders as
possible.
Spread out the interviews over time, and allow yourself
several hours for each interview.
Prepare an extensive list of questions.
• Brainstorming : It is an effective way to gather
information from a group of people. The general idea is
that the group sits around a table and discusses some
topic with the goal of generating ideas.
59. • Prototyping : A prototype is a program that is
rapidly implemented and only contains a small
part of the anticipated functionality of a
complete system. Its purpose is to gather
requirements by allowing software engineers to
obtain early feedback about their ideas.
• Use case analysis : It is a systematic approach
to working out what users should be able to do
with the software you are developing.
61. Functional Requirements
• FieldOfficer: Identified by badge number and he initiate the
ReportEmergency
• EmergencyForm:It consists of type of emergency, location &
description
• Dispatcher: he also identified by badge number, he create
incident in database and allocate resources
• IncidentForm: It consists of following states:
Fig: states in Incident
62. 2.5 Types of Requirements Engineering Documents or
Managing Requirements Engineering
1. Eliciting Requiems :KAT(Knowledge Analysis of Task)
2. Specification from Client :JAD(Joint Application Design)
3. Validating Requirements: Usability Testing
4. Documenting Requirements Engineering Activity
1. Eliciting Requiems : KAT
Consists of 5 Steps
• Identifying Objects
• Identifying Procedures
• Indentifying Importance
• Define Goals and Sub goals
• Construct the Model
