Download to read offline
![2. Non-functional Requirements: This can be the necessities that specify the criteria
that can be used to decide the operation instead of specific behaviors of the system.
Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are observable at run
time.
o Evolution qualities like testability, maintainability, extensibility, and
scalability that embodied in the static structure of the software
An information model in software engineering is a representation of concepts and the
relationships, constraints, rules, and operations to specify data semantics for a chosen domain of
discourse. Typically it specifies relations between kinds of things, but may also include relations
with individual things. It can provide sharable, stable, and organized structure of information
requirements or knowledge for the domain context.[1]
The term information model in general is used for models of individual things, such as facilities,
buildings, process plants, etc. In those cases the concept is specialised to facility information
model, building information model, plant information model, etc. Such an information model is
an integration of a model of the facility with the data and documents about the facility.
Within the field of software engineering and data modeling an information model is usually an
abstract, formal representation of entity types that may include their properties, relationships and
the operations that can be performed on them. The entity types in the model may be kinds of
real-world objects, such as devices in a network, or occurrences, or they may themselves be
abstract, such as for the entities used in a billing system. Typically, they are used to model a
constrained domain that can be described by a closed set of entity types, properties, relationships
and operations.
An information model provides formalism to the description of a problem domain without
constraining how that description is mapped to an actual implementation in software. There may
be many mappings of the information model. Such mappings are called data models, irrespective
of whether they are object models (e.g. using UML), entity relationship models or XML
schemas.
References:
S/W Engg. Roger Pressman
Lecture 12(13/10/2020)
Information modeling languages](https://image.slidesharecdn.com/swengglecturenotes-201128053026/75/Software-engineering-lecture-notes-24-2048.jpg)
![A sample ER diagram.
Database requirements for a CD collection in EXPRESS-G notation.
In 1976, an entity-relationship (ER) graphic notation was introduced by Peter Chen. He stressed
that it was a "semantic" modelling technique and independent of any database modelling
techniques such as Hierarchical, CODASYL, Relational etc.[2]
Since then, languages for
information models have continued to evolve. Some examples are the Integrated Definition
Language 1 Extended (IDEF1X), the EXPRESS language and the Unified Modeling Language
(UML).[1]
Research by contemporaries of Peter Chen such as J.R.Abrial (1974) and G.M Nijssen (1976) led
to today's Fact Oriented Modeling (FOM) languages which are based on linguistic propositions
rather than on "entities". FOM tools can be used to generate an ER model which means that the
modeler can avoid the time-consuming and error prone practice of manual normalization.
Object-Role Modeling language (ORM) and Fully Communication Oriented Information
Modeling (FCO-IM) are both research results, based upon earlier research.
In the 1980s there were several approaches to extend Chen’s Entity Relationship Model. Also
important in this decade is REMORA by Colette Rolland.[3]
The ICAM Definition (IDEF) Language was developed from the U.S. Air Force ICAM Program
during the 1976 to 1982 timeframe.[4]
The objective of the ICAM Program, according to Lee
(1999), was to increase manufacturing productivity through the systematic application of
computer technology. IDEF includes three different modeling methods: IDEF0, IDEF1, and
IDEF2 for producing a functional model, an information model, and a dynamic model
respectively. IDEF1X is an extended version of IDEF1. The language is in the public domain. It](https://image.slidesharecdn.com/swengglecturenotes-201128053026/75/Software-engineering-lecture-notes-25-2048.jpg)
![is a graphical representation and is designed using the ER approach and the relational theory. It
is used to represent the “real world” in terms of entities, attributes, and relationships between
entities. Normalization is enforced by KEY Structures and KEY Migration. The language
identifies property groupings (Aggregation) to form complete entity definitions.[1]
EXPRESS was created as ISO 10303-11 for formally specifying information requirements of
product data model. It is part of a suite of standards informally known as the STandard for the
Exchange of Product model data (STEP). It was first introduced in the early 1990s.[5][6]
The
language, according to Lee (1999), is a textual representation. In addition, a graphical subset of
EXPRESS called EXPRESS-G is available. EXPRESS is based on programming languages and
the O-O paradigm. A number of languages have contributed to EXPRESS. In particular, Ada,
Algol, C, C++, Euler, Modula-2, Pascal, PL/1, and SQL. EXPRESS consists of language
elements that allow an unambiguous object definition and specification of constraints on the
objects defined. It uses SCHEMA declaration to provide partitioning and it supports
specification of data properties, constraints, and operations.[1]
UML is a modeling language for specifying, visualizing, constructing, and documenting the
artifacts, rather than processes, of software systems. It was conceived originally by Grady
Booch, James Rumbaugh, and Ivar Jacobson. UML was approved by the Object Management
Group (OMG) as a standard in 1997. The language, according to Lee (1999), is non-proprietary
and is available to the public. It is a graphical representation. The language is based on the
objected-oriented paradigm. UML contains notations and rules and is designed to represent data
requirements in terms of O-O diagrams. UML organizes a model in a number of views that
present different aspects of a system. The contents of a view are described in diagrams that are
graphs with model elements. A diagram contains model elements that represent common O-O
concepts such as classes, objects, messages, and relationships among these concepts.[1]
IDEF1X, EXPRESS, and UML all can be used to create a conceptual model and, according to
Lee (1999), each has its own characteristics. Although some may lead to a natural usage (e.g.,
implementation), one is not necessarily better than another. In practice, it may require more than
one language to develop all information models when an application is complex. In fact, the
modeling practice is often more important than the language chosen.[1]
Information models can also be expressed in formalized natural languages, such as Gellish.
Gellish, which has natural language variants Gellish Formal English, Gellish Formal Dutch
(Gellish Formeel Nederlands), etc. is an information representation language or modeling
language that is defined in the Gellish smart Dictionary-Taxonomy, which has the form of a
Taxonomy/Ontology. A Gellish Database is not only suitable to store information models, but
also knowledge models, requirements models and dictionaries, taxonomies and ontologies.
Information models in Gellish English use Gellish Formal English expressions. For example, a
geographic information model might consist of a number of Gellish Formal English expressions,
such as:
- the Eiffel tower <is located in> Paris
- Paris <is classified as a> city
whereas information requirements and knowledge can be expressed for example as follows:
- tower <shall be located in a> geographical area
- city <is a kind of> geographical area](https://image.slidesharecdn.com/swengglecturenotes-201128053026/75/Software-engineering-lecture-notes-26-2048.jpg)
![Such Gellish expressions use names of concepts (such as 'city') and relation types (such as ⟨is
located in⟩ and ⟨is classified as a⟩) that should be selected from the Gellish Formal English
Dictionary-Taxonomy (or of your own domain dictionary). The Gellish English Dictionary-
Taxonomy enables the creation of semantically rich information models, because the dictionary
contains definitions of more than 40000 concepts, including more than 600 standard relation
types. Thus, an information model in Gellish consists of a collection of Gellish expressions that
use those phrases and dictionary concepts to express facts or make statements, queries and
answers.
Standard sets of information models[edit]
The Distributed Management Task Force (DMTF) provides a standard set of information models
for various enterprise domains under the general title of the Common Information Model (CIM).
Specific information models are derived from CIM for particular management domains.
The TeleManagement Forum (TMF) has defined an advanced model for the Telecommunication
domain (the Shared Information/Data model, or SID) as another. This includes views from the
business, service and resource domains within the Telecommunication industry. The TMF has
established a set of principles that an OSS integration should adopt, along with a set of models
that provide standardized approaches.
The models interact with the information model (the Shared Information/Data Model, or SID),
via a process model (the Business Process Framework (eTOM), or eTOM) and a life cycle
model.
Levels in Data Flow Diagrams (DFD)
In Software engineering DFD(data flow diagram) can be drawn to represent the system of
different levels of abstraction. Higher level DFDs are partitioned into low levels-hacking more
information and functional elements. Levels in DFD are numbered 0, 1, 2 or beyond. Here, we
will see mainly 3 levels in data flow diagram, which are: 0-level DFD, 1-level DFD, and 2-level
DFD.
0-level DFD:
It is also known as context diagram. It’s designed to be an abstraction view, showing the system
as a single process with its relationship to external entities. It represent the entire system as
single bubble with input and output data indicated by incoming/outgoing arrows.](https://image.slidesharecdn.com/swengglecturenotes-201128053026/75/Software-engineering-lecture-notes-27-2048.jpg)
![Condition 2
Condition 3
Condition 4
Decision Table: Combinations
CONDITIONS STEP 1 STEP 2 STEP 3 STEP 4
Condition 1 Y Y N N
Condition 2 Y N Y N
Condition 3 Y N N Y
Condition 4 N Y Y N
Advantage of Decision Table:
1. Any complex business flow can be easily converted into the test scenarios & test cases using this
technique.
2. Decision tables work iteratively that means the table created at the first iteration is used as input
table for next tables. The iteration is done only if the initial table is not satisfactory.
3. Simple to understand and everyone can use this method design the test scenarios & test cases.
4. It provide complete coverage of test cases which help to reduce the rework on writing test scenarios
& test cases.
5. These tables guarantee that we consider every possible combination of condition values. This is
known as its completeness property.
References: GeeksForGeeks
Java T
Software Engineering(MCA 512)
MCA V Sem
Unit-II: Software Requirement Specifications (SRS)
Faculty: Ms. Savita Mittal
Lecture 17
A software requirements specification (SRS) is a description of a software system to be
developed. It is modeled after business requirements specification (CONOPS), also known as
a stakeholder requirements specification (StRS).[citation needed]
The software requirements
specification lays out functional and non-functional requirements, and it may include a set of use](https://image.slidesharecdn.com/swengglecturenotes-201128053026/75/Software-engineering-lecture-notes-44-2048.jpg)
![cases that describe user interactions that the software must provide to the user for perfect
interaction.
Software requirements specification establishes the basis for an agreement between customers
and contractors or suppliers on how the software product should function (in a market-driven
project, these roles may be played by the marketing and development divisions). Software
requirements specification is a rigorous assessment of requirements before the more specific
system design stages, and its goal is to reduce later redesign. It should also provide a realistic
basis for estimating product costs, risks, and schedules.[1]
Used appropriately, software
requirements specifications can help prevent software project failure.[2]
The software requirements specification document lists sufficient and necessary requirements for
the project development.[3]
To derive the requirements, the developer needs to have clear and
thorough understanding of the products under development. This is achieved through detailed
and continuous communications with the project team and customer throughout the software
development process.
The SRS may be one of a contract's deliverable data item descriptions[4]
or have other forms of
organizationally-mandated content.
Typically a SRS is written by a technical writer, a systems architect, or a software programmer.[5]
Structure
An example organization of an SRS is as follows:[6]
1. Purpose
1. Definitions
2. Background
3. System overview
4. References
2. Overall description
1. Product perspective
1. System Interfaces
2. User interfaces
3. Hardware interfaces
4. Software interfaces
5. Communication Interfaces
6. Memory constraints
2. Design constraints
1. Operations
2. Site adaptation requirements
3. Product functions
4. User characteristics
5. Constraints, assumptions and dependencies
3. Specific requirements
1. External interface requirements
2. Functional requirements](https://image.slidesharecdn.com/swengglecturenotes-201128053026/75/Software-engineering-lecture-notes-45-2048.jpg)
![supports reusability of separate modules of the ontology while grouping along the function
supports the reusability of the ontology as a whole, but it also supplements the represented
knowledge, as it enables the use of these properties in an application in a more structured
approach aiding specific functionalities of the user .
Modularization Smells
Girish Suryanarayana, ... Tushar Sharma, in Refactoring for Software Design Smells, 2015
5.2.1 Rationale
Modularization concerns the logical partitioning of a software design so that the design becomes
easy to understand and maintain. One of the key enabling techniques for effective modularization
is to “decompose abstractions to manageable size.” In this context, Lanza and Marinescu [21]
recommend that “operations and classes should have a harmonious size, i.e., they should avoid
both size extremities.” When an abstraction has complex methods or a large number of methods,
it violates this enabling technique and the principle of modularization. Since the abstraction is
inadequately decomposed, we name this smell Insufficient Modularization.
MULTIFACETED ABSTRACTION VERSUS INSUFFICIENT MODULARIZATION
Note that Multifaceted Abstraction smell (Section 3.4) is different from Insufficient
Modularization smell. In Multifaceted Abstraction, an abstraction addresses more than one
responsibility, thereby violating the Single Responsibility Principle (SRP). In Insufficient
Modularization, an abstraction violates the Principle of Decomposition, indicating that the
abstraction is large, complex, or both. Interestingly, these two smells often occur together: It is
common to see a large and complex abstraction that has multiple responsibilities. However, they
are different smells: An abstraction could have a single responsibility, but could still be large and
complex. Similarly, an abstraction could be small, but could still have multiple responsibilities.
Design modularity enables production modularity
Modularization of platform architectures matters also because it determines whether
development around a platform can feasibly be organized as an ecosystem or whether it must be
done within the boundaries of a single organization. Different architectures impose different
constraints on those who interact with it or are exposed to it (van Schewick, 2012, p. 4). The
preceding discussion focuses primarily on modularity in design, overlooking another kind of
modularity—modularity in production (Gamba and Fusari, 2009), which refers to modularity in
the logic used to organize production of a design. A traditionally integrated organization
represents a monolithic organizing logic whereas a distributed ecosystem composed on many
independent app developers represents a modular organizing logic used for producing the design.
Modularity of production is a platform governance decision (the focus of the next chapter), but
one whose feasibility is determined by modularity of the platform’s design. Lack of design
modularity, in contrast, makes production modularity infeasible (Langlois, 2002; Sanchez and
Mahoney, 1996). Architectural choices therefore preordain the realm of execution possibilities.
This is the essence of the mirroring principle. Design modularity and production modularity are
therefore fundamentally isomorphic (i.e., design modularity enables production modularity)
(Baldwin and Clark, 2000, p. 12; Hoetker, 2006). A platform’s architecture is therefore
particularly decisive in the evolution of its ecosystem because it is closely intertwined with the](https://image.slidesharecdn.com/swengglecturenotes-201128053026/75/Software-engineering-lecture-notes-64-2048.jpg)
![Let’s go deeper into the general concepts of OOP, which are given below:
What Are Class & Object?
It is the basic concept of OOP; an extended concept of the structure used in C. It is an abstract and user-
defined data type. It consists of several variables and functions. The primary purpose of the class is to store
data and information. The members of a class define the behaviour of the class. A class is the blueprint of
the object, but also, we can say the implementation of the class is the object. The class is not visible to the
world, but the object is.
filter_none
brightness_4
Class car
{
int car_id;
char colour[4];
float engine_no;
double distance;
void distance_travelled();
float petrol_used();](https://image.slidesharecdn.com/swengglecturenotes-201128053026/75/Software-engineering-lecture-notes-80-2048.jpg)
![6. Functions calls are considered as operators.
7. All looping statements e.g., do {…} while ( ), while ( ) {…}, for ( ) {…}, all control
statements e.g., if ( ) {…}, if ( ) {…} else {…}, etc. are considered as operators.
8. In control construct switch ( ) {case:…}, switch as well as all the case statements are
considered as operators.
9. The reserve words like return, default, continue, break, sizeof, etc., are considered as
operators.
10. All the brackets, commas, and terminators are considered as operators.
11. GOTO is counted as an operator and the label is counted as an operand.
12. The unary and binary occurrence of “+” and “-” are dealt separately. Similarly “*”
(multiplication operator) are dealt separately.
13. In the array variables such as “array-name [index]” “array-name” and “index” are
considered as operands and [ ] is considered as operator.
14. In the structure variables such as “struct-name, member-name” or “struct-name -> member-
name”, struct-name, member-name are taken as operands and ‘.’, ‘->’ are taken as
operators. Some names of member elements in different structure variables are counted as
unique operands.
15. All the hash directive are ignored.
Example – List out the operators and operands and also calculate the values of software science
measures like
int sort (int x[ ], int n)
{
int i, j, save, im1;
/*This function sorts array x in ascending order */
If (n< 2) return 1;
for (i=2; i< =n; i++)
{
im1=i-1;
for (j=1; j< =im1; j++)
if (x[i] < x[j])
{
Save = x[i];
x[i] = x[j];](https://image.slidesharecdn.com/swengglecturenotes-201128053026/75/Software-engineering-lecture-notes-88-2048.jpg)
![x[j] = save;
}
}
return 0;
}
Explanation –
operators occurrences operands occurrences
int 4 sort 1
() 5 x 7
, 4 n 3
[] 7 i 8
if 2 j 7
< 2 save 3
; 11 im1 3](https://image.slidesharecdn.com/swengglecturenotes-201128053026/75/Software-engineering-lecture-notes-89-2048.jpg)
Uploaded byTEJVEER SINGH
Software engineering lecture notes
The document provides an overview of software engineering and different software development life cycle (SDLC) models. It discusses the waterfall, iterative, spiral, and agile SDLC models. The waterfall model follows a linear sequence of stages from requirements to maintenance. The iterative model is repetitive, allowing new versions with each cycle. The spiral model combines architecture and prototyping in risk-analysis-focused stages. Different models suit different types of projects based on requirements clarity and risk.
More Related Content
Similar to Software engineering lecture notes
Software engineering lecture notes
- 1. Software Engineering(MCA 512) MCAV Sem Unit-I: Introduction Faculty: Ms. Savita Mittal Lecture 1 Topic :Introduction to Software Engineering Software is a program or set of programs containing instructions which provide desired functionality . And Engineering is the processes of designing and building something that serves a particular purpose and find a cost effective solution to problems. Software Engineering is a systematic approach to the design, development, operation, and maintenance of a software system. Dual Role of Software: 1. As a product – It delivers the computing potential across network of Hardware. It enables the Hardware to deliver the expected functionality. It acts as information transformer because it produces, manages, acquires, modifies, displays, or transmits information. 2. As a vehicle for delivering a product – It provides system functionality (e.g., payroll system) It controls other software (e.g., an operating system) It helps build other software (e.g., software tools) Objectives of Software Engineering: 1. Maintainability – It should be feasible for the software to evolve to meet changing requirements. 2. Correctness – A software product is correct, if the different requirements as specified in the SRS document have been correctly implemented. 3. Reusability – A software product has good reusability, if the different modules of the product can easily be reused to develop new products. 4. Testability – Here software facilitates both the establishment of test criteria and the evaluation of the software with respect to those criteria. 5. Reliability – It is an attribute of software quality. The extent to which a program can be expected to perform its desired function, over an arbitrary time period. 6. Portability – In this case, software can be transferred from one computer system or environment to another. 7. Adaptability –
- 2. In this case,software allows differing system constraints and user needs to be satisfied by making changes to the software. Compiled By:Ms. Savita Mittal(Astt.Professor,DCA) References : @existek.com support@dzone.com @geeksforgeeks Faculty: Ms. Savita Mittal Lecture 2: 21/9/2020 Topic:Program vs Software Product A program is a set of instructions which is given to a computer in order to achieve a specific task whereas a software is when a program is made available for commercial business and is properly documented along with its licensing. Software=Program+documentation+licensing. A program is one of the stages involved in the development of the software, whereas a software development usually follows a life cycle, which involves the feasibility study of the project, requirement gathering, development of a prototype, system design, coding and testing. Software Characteristics: Software is defined as collection of computer programs, procedures, rules and data. Software Characteristics are classified into six major catagories: 1.Functionality: It refers to the degree of performance of the software against its intended purpose. Required functions are: 2.Reliability: A set of attribute that bear on capability of software to maintain its level of performance under the given condition for a stated period of time. 3.Efficiency: It refers to the ability of the software to use system resources in the most effective and efficient manner.the software should make effective use of storage space and executive command as per desired timing requirement. 4.Usability: It refers to the extent to which the software can be used with ease.the amount of effort or time required to learn how to use the software. 5.Maintainability: It refers to the ease with which the modifications can be made in a software system to extend its functionality, improve its performance, or correct errors. 6.Portability: A set of attribute that bear on the ability of software to be transferred from one environment to another, without or minimum changes.
- 3. Software-Components: (SW-C) are architecturalelements that provide and/or require interfaces and are connected to each other through the Virtual Functional Bus to fulfill architectural responsibilities. The Software Component is the central structural element used when building a system at the VFB-level. Following are the components of a software system: 1.Network and Internet Services. 2.Hardware Level of Operating System. 3.Logical Level of Operating System. 4.Graphics Engine. 5.User Interface. 6.System Services. 7.Command Shell. 8.System Utilities. Compiled By: Ms. Savita Mittal(Astt. Professor,DCA) References : @existek.com support@dzone.com @geeksforgeeks Faculty: Ms. Savita Mittal Lecture 3: 26/9/2020 Another view of S/W Components is: There are three components of the software: 1.Program: A computer program is a list of instructions that tell a computer what to do. 2.Documentation: Source information about the product contained in design documents, detailed code comments, etc. 3.Operating Procedures: Set of step-by-step instructions compiled by an organization to help workers carry out complex routine operations. Software Crisis: Software Crisis is a term used in computer science for the difficulty of writing useful and efficient computer programs in the required time .software crisis was due to using same workforce, same methods, same tools even though rapidly increasing in software demand, complexity of software and software challenges. With increase in the complexity of software, many software problems arise because existing methods were insufficient. If we will use same workforce, same methods and same tools after fast increasing in software demand, software complexity and software challenges, then there arose some problems like software budget problem, software efficiency problem, software quality problem, software managing and delivering problem etc. This condition is called software crisis. Causes of Software Crisis: The cost of owning and maintaining software was as expensive as developing the software
- 4. At that timeProjects was running over-time At that time Software was very inefficient The quality of software was low quality Software often did not meet requirements The average software project overshoots its schedule by half At that time Software was never delivered Solution of Software Crisis: There is no single solution to the crisis. One possible solution of software crisis is Software Engineering because software engineering is a systematic, disciplined and quantifiable approach. For preventing software crisis, there are some guidelines: 1.Reduction in software over-budget 2.The quality of software must be high 3.Less time needed for software project 4.Experience working team member on software project 5.Software must be delivered Compiled By:Ms. Savita Mittal(Astt. Professor,DCA) References : @existek.com support@dzone.com @geeksforgeeks Unit-I: Introduction Faculty: Savita Mittal Lecture 4: Software Processes in Software Engineering: Software is the set of instructions in the form of programs to govern the computer system and to process the hardware components. To produce a software product the set of activities is used. This set is called a software process. There are four basic key process activities: 1.Software Specifications:In this process, detailed description of a software system to be developed with its functional and non-functional requirements. 2.Software Development:In this process, designing, programming, documenting, testing, and bug fixing is done. 3.Software Validation:In this process, evaluation software product is done to ensure that the software meets the business requirements as well as the end users needs. 4.Software Evolution:It is a process of developing software initially, then timely updating it for various reasons. Difference between Software Engineering process and Conventional Engineering Processs 1. Software Engineering Process : It is a engineering process which is mainly related to computers and programming and developing different kinds of applications through the use of information technology.
- 5. 2. Conventional EngineeringProcess : It is a engineering process which is highly based on empirical knowledge and is about building cars, machines and hardware. Difference between Software Engineering Process and Conventional Engineering Process : Compiled By: Ms. Savita Mittal References : @existek.com support@dzone.com @geeksforgeeks Software Engineering Process is a process which majorly involves computer science, information Conventional Engineering Process is a process which majorly involves science, mathematics and empirical Software Engineering(MCA 512) MCA V Sem Lecture 5: 29/9/2020 Unit-I: Introduction Quality Attributes (Contd..) Testability Software testability is a measure of how easy is to create test criteria for the system and its components, and to execute these tests that assess if the criteria are met. Security All systems must be capable of prevent malicious or accidental actions that aren't following designed usage. With security comes a measure of the system’s ability to protect data and information from unauthorized access while still providing access to people and systems that are authorized. Usability Usability is concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides. One of the basic notions of the software development process is SDLC models which stands for Software Development Life Cycle models. SDLC – is a continuous process, which starts from the moment, when it’s made a decision to launch the project, and it ends at the moment of its full remove
- 6. from the exploitation.There is no one single SDLC model. They are divided into main groups, each with its features and weaknesses. Evolving from the first and oldest “waterfall” SDLC model, their variety significantly expanded. The SDLC models diversity is predetermined by the wide number of product types – starting with a web application development to a complex medical software. And if you take one of the SDLC models mentioned below as the basis – in any case, it should be adjusted to the features of the product, project, and company. The most used, popular and important SDLC models are given below: • • Waterfall model • • Iterative model • • Spiral model • • V-shaped model • • Agile model
- 7. No matter whattype of the models has been chosen, each of them has basic stages which are used by every software development company. Let’s explore those stages as this is important for the understanding of the each of SDLC models and the differences between them. BASIC STAGES OF SOFTWARE DEVELOPMENT LIFE CYCLE Stage 1. Planning and requirement analysis Each software development life cycle model starts with the analysis, in which the stakeholders of the process discuss the requirements for the final product. The goal of this stage is the detailed definition of the system requirements. Besides, it is needed to make sure that all the process participants have clearly understood the tasks and how every requirement is going to be implemented. Often, the discussion involves the QA specialists who can interfere the process with additions even during the development stage if it is necessary. Stage 2. Designing project architecture At the second phase of the software development life cycle, the developers are actually designing the architecture. All the different technical questions that may appear on this stage are discussed by all the stakeholders, including the customer. Also, here are defined the technologies used in the project, team load, limitations, time frames, and budget. The most appropriate project decisions are made according to the defined requirements. Stage 3. Development and programming After the requirements approved, the process goes to the next stage – actual development. Programmers start here with the source code writing while keeping in mind previously defined requirements. The system administrators adjust the software environment, front-end programmers develop the user interface of the program and the logics for its interaction with the server. The programming by itself assumes four stages • • Algorithm development • • Source code writing • • Compilation • • Testing and debugging Stage 4. Testing The testing phase includes the debugging process. All the code flaws missed during the development are detected here, documented, and passed back to the developers to fix. The testing process repeats until all the critical issues are removed and software workflow is stable. Stage 5. Deployment When the program is finalized and has no critical issues – it is time to launch it for the end users. After the new program version release, the tech support team joins. This department provides user feedback; consult and support users during the time of exploitation. Moreover, the update of selected components is included in this phase, to make sure, that the software is up-to-date and is invulnerable to a security breach.
- 8. SDLC MODELS Waterfall SDLCModel Waterfall is a cascade SDLC model, in which development process looks like the flow, moving step by step through the phases of analysis, projecting, realization, testing, implementation, and support. This SDLC model includes gradual execution of every stage completely. This process is strictly documented and predefined with features expected to every phase of this software development life cycle model. References : Compiled By:Ms. Savita Mitta DCA @existek.com support@dzone.com @geeksforgeeks Software Engineering(MCA 512) MCA V Sem Lecture 6: 30/9/2020 Unit-I: Introduction Waterfall Model(Contd…) ADVANTAGES Simple to use and understand Disadvantages The software is ready only after the last stage is over Management simplicity thanks to its rigidity: every phase has a defined result and process review High risks and uncertainty Development stages go one by one Not the best choice for complex and object- oriented projects Perfect for the small or mid-sized projects where requirements are clear and not equivocal Inappropriate for the long-term projects
- 9. Easy to determinethe key points in the development cycle The progress of the stage is hard to measure while it is still in the development Easy to classify and prioritize tasks Integration is done at the very end, which does not give the option of identifying the problem in advance Use cases for the Waterfall SDLC model: • • The requirements are precisely documented • • Product definition is stable • • The technologies stack is predefined which makes it not dynamic • • No ambiguous requirements • • The project is short Iterative SDLC Model The Iterative SDLC model does not need the full list of requirements before the project starts. The development process may start with the requirements to the functional part, which can be expanded later. The process is repetitive, allowing to make new versions of the product for every cycle. Every iteration (which last from two to six weeks) includes the development of a separate component of the system, and after that, this component is added to the functional developed earlier. Speaking with math terminology, the iterative model is a realization of the sequential approximation method; that means a gradual closeness to the planned final product shape. ADVANTAGES DISADVANTAGES Some functions can be quickly developed at the beginning of the development lifecycle Iterative model requires more resources than the waterfall model The paralleled development can be applied Constant management is required The progress is easy measurable Issues with architecture or design may occur
- 10. because not allthe requirements are foreseen during the short planning stage The shorter iteration is - the easier testing and debugging stages are Bad choice for the small projects It is easier to control the risks as high-risk tasks are completed first The process is difficult to manage Problems and risks defined within one iteration can be prevented in the next sprints The risks may not be completely determined even at the final stage of the project Flexibility and readiness to the changes in the requirements Risks analysis requires involvement of the highly-qualified specialists Use cases for the Iteration model: • • The requirements to the final product are strictly predefined • • Applied to the large-scale projects • • The main task is predefined, but the details may advance with the time References : Compiled By:Ms. Savita Mittal , DCA @existek.com support@dzone.com @geeksforgeeks Software Engineering(MCA 512) MCA V Sem Lecture 7: 1/10/2020 Unit-I: Introduction Spiral SDLC Model Spiral model – is SDLC model, which combines architecture and prototyping by stages. It is a combination of the Iterative and Waterfall SDLC models with the significant accent on the risk analysis. The main issue of the spiral model – is defining the right moment to make a step into the next stage. The preliminary set time frames are recommended as the solution to this issue. The shift to the next stage is done according to the plan, even if the work on the previous stage isn’t done yet. The plan is introduced basing on the statistic data, received during the previous projects even from the personal developer’s experience.
- 11. ADVANTAGES DISADVANTAGES Lifecycle isdivided into small parts, and if the risk concentration is higher, the phase can be finished earlier to address the treats Can be quite expensive The development process is precisely documented yet scalable to the changes The risk control demands involvement of the highly-skilled professionals The scalability allows to make changes and add new functionality even at the relatively late stages Can be ineffective for the small projects The earlier working prototype is done - sooner users can point out the flaws Big number of the intermediate stages requires excessive documentation Use cases for the Spiral model Customer isn’t sure about the requirements Major edits are expected during the development cycle The projects with mid or high-level risk, where it is important to prevent these risks The new product that should be released in a few stages to have enough of clients feedback.
- 12. References : CompiledBy:Ms. Savita Mittal(Astt. Professor,DCA) @existek.com support@dzone.com @geeksforgeeks Software Engineering(MCA 512) MCA V Sem Lecture 8: 5/10/2020 Unit-I: Introduction V-shaped SDLC Model V-shaped SDLC model is an expansion of classic waterfall model and it’s based on associated test stage for the every development stage. This is a very strict model and the next stage is started only after the previous phase. This is also called “Validation and verification” model. Every stage has the current process control, to make sure that the conversion to the next stage is
- 13. possible. ADVANTAGES DISADVANTAGES Every stageof V-shaped model has strict results so it’s easy to control Lack of the flexibility Testing and verification take place in the early stages Bad choice for the small projects Good for the small projects, where requirements are static and clear Relatively big risks Use cases for the V-shaped model: For the projects where an accurate product testing is required For the small and mid-sized projects, where requirements are strictly predefined The engineers of the required qualification, especially testers, are within easy reach. Agile SDLC Model In the agile methodology after every development iteration, the customer is able to see the result and understand if he is satisfied with it or he is not. This is one of the advantages of the agile software development life cycle model. One of its disadvantages is that with the absence of defined requirements it is difficult to estimate the resources and development cost. Extreme programming is one of the practical use of the agile model. The basis of such model consists of
- 14. short weekly meetings– Sprints which are the part of the Scrum approach. ADVANTAGES DISADVANTAGES Corrections of functional requirements are implemented into the development process to provide the competitiveness Difficulties with measuring the final cost because of permanent changes Project is divided by short and transparent iterations The team should be highly professional and client-oriented Risks are minimized thanks to the flexible change process New requirements may conflict with the existing architecture Fast release of the first product version With all the corrections and changes there is possibility that the project will exceed expected time Use cases for the Agile model: The users’ needs change dynamically Less price for the changes implemented because of the many iterations Unlike the Waterfall model, it requires only initial planning to start the project Conclusion
- 15. During the yearsof the SDLC evolution, different models were developed from the basic cascade model to meet a huge variety of development requirements and expectations. There is no only one suitable model for all the projects, starting conditions and payment model. Even at the first sight, multi-purpose Agile cannot be used widely because of some customers’ unpreparedness to scale the budget. The SDLC models often cross in the solutions and particularly look similar. References : Compiled By:Ms. Savita Mittal(Astt. Professor,DCA) @existek.com support@dzone.com @geeksforgeeks SW Engg. Unit 2 Lecture 9 S/W Engg. Process
- 16. Activities of S/wEngg. Process: Elicitation, Analysis, Documentation, Review and Management of User Needs Requirement Engineering Requirements engineering (RE) refers to the process of defining, documenting, and maintaining requirements in the engineering design process. Requirement engineering provides the appropriate mechanism to understand what the customer desires, analyzing the need, and assessing feasibility, negotiating a reasonable solution, specifying the solution clearly, validating the specifications and managing the requirements as they are transformed into a working system. Thus, requirement engineering is the disciplined application of proven principles, methods, tools, and notation to describe a proposed system's intended behavior and its associated constraints. Requirement Engineering Process It is a four-step process, which includes - 1. Feasibility Study 2. Requirement Elicitation and Analysis 3. Software Requirement Specification 4. Software Requirement Validation 5. Software Requirement Management
- 17. 1. Feasibility Study: Theobjective behind the feasibility study is to create the reasons for developing the software that is acceptable to users, flexible to change and conformable to established standards. Types of Feasibility: 1. Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to accomplish customer requirements within the time and budget. 2. Operational Feasibility - Operational feasibility assesses the range in which the required software performs a series of levels to solve business problems and customer requirements. 3. Economic Feasibility - Economic feasibility decides whether the necessary software can generate financial profits for an organization.
- 18. 2. Requirement Elicitationand Analysis: This is also known as the gathering of requirements. Here, requirements are identified with the help of customers and existing systems processes, if available. Analysis of requirements starts with requirement elicitation. The requirements are analyzed to identify inconsistencies, defects, omission, etc. We describe requirements in terms of relationships and also resolve conflicts if any. Problems of Elicitation and Analysis o Getting all, and only, the right people involved. o Stakeholders often don't know what they want o Stakeholders express requirements in their terms. o Stakeholders may have conflicting requirements. o Requirement change during the analysis process. o Organizational and political factors may influence system requirements.
- 19. Lecture 10(8/10/2020) Lecture 10(8/10/2020) 1. Feasibility Study: The objective behind the feasibility study is to create the reasons for developing the software that is acceptable to users, flexible to change and conformable to established standards. Types of Feasibility: 4. Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to accomplish customer requirements within the time and budget. 5. Operational Feasibility - Operational feasibility assesses the range in which the required software performs a series of levels to solve business problems and customer requirements.
- 20. 6. Economic Feasibility- Economic feasibility decides whether the necessary software can generate financial profits for an organization. 2. Requirement Elicitation and Analysis: This is also known as the gathering of requirements. Here, requirements are identified with the help of customers and existing systems processes, if available. Analysis of requirements starts with requirement elicitation. The requirements are analyzed to identify inconsistencies, defects, omission, etc. We describe requirements in terms of relationships and also resolve conflicts if any. Problems of Elicitation and Analysis o Getting all, and only, the right people involved. o Stakeholders often don't know what they want o Stakeholders express requirements in their terms. o Stakeholders may have conflicting requirements. o Requirement change during the analysis process. o Organizational and political factors may influence system requirements.
- 21. 3. Software RequirementSpecification: Software requirement specification is a kind of document which is created by a software analyst after the requirements collected from the various sources - the requirement received by the customer written in ordinary language. It is the job of the analyst to write the requirement in technical language so that they can be understood and beneficial by the development team. The models used at this stage include ER diagrams, data flow diagrams (DFDs), function decomposition diagrams (FDDs), data dictionaries, etc. o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the requirements. DFD shows the flow of data through a system. The system may be a company, an organization, a set of procedures, a computer hardware system, a software system, or any combination of the preceding. The DFD is also known as a data flow graph or bubble chart.
- 22. o Data Dictionaries:Data Dictionaries are simply repositories to store information about all data items defined in DFDs. At the requirements stage, the data dictionary should at least define customer data items, to ensure that the customer and developers use the same definition and terminologies. o Entity-Relationship Diagrams: Another tool for requirement specification is the entity-relationship diagram, often called an "E-R diagram." It is a detailed logical representation of the data for the organization and uses three main constructs i.e. data entities, relationships, and their associated attributes. References: GeeksForGeeks Compiled By: Ms. Savita Mittal(Astt.Prof.; DCA) JavaT Books: Gill, Naseeb Singh- S/E Engineering Pressman, R- S/E Engineering Software Engineering – MCA 512 Unit II Lecture 11(12/10/2020) 4. Software Requirement Validation: After requirement specifications developed, the requirements discussed in this document are validated. The user might demand illegal, impossible solution or experts may misinterpret the needs. Requirements can be the check against the following conditions - o If they can practically implement o If they are correct and as per the functionality and specially of software o If there are any ambiguities o If they are full o If they can describe Requirements Validation Techniques o Requirements reviews/inspections: systematic manual analysis of the requirements. o Prototyping: Using an executable model of the system to check requirements. o Test-case generation: Developing tests for requirements to check testability.
- 23. o Automated consistencyanalysis: checking for the consistency of structured requirements descriptions. Software Requirement Management: Requirement management is the process of managing changing requirements during the requirements engineering process and system development. New requirements emerge during the process as business needs a change, and a better understanding of the system is developed. The priority of requirements from different viewpoints changes during development process. The business and technical environment of the system changes during the development. Prerequisite of Software requirements Collection of software requirements is the basis of the entire software development project. Hence they should be clear, correct, and well-defined. A complete Software Requirement Specifications should be: o Clear o Correct o Consistent o Coherent o Comprehensible o Modifiable o Verifiable o Prioritized o Unambiguous o Traceable o Credible source Software Requirements: Software requirement categories: 1. Functional Requirements: Functional requirements define a function that a system or system element must be qualified to perform and must be documented in different forms. The functional requirements are describing the behavior of the system as it correlates to the system's functionality.
- 24. 2. Non-functional Requirements:This can be the necessities that specify the criteria that can be used to decide the operation instead of specific behaviors of the system. Non-functional requirements are divided into two main categories: o Execution qualities like security and usability, which are observable at run time. o Evolution qualities like testability, maintainability, extensibility, and scalability that embodied in the static structure of the software An information model in software engineering is a representation of concepts and the relationships, constraints, rules, and operations to specify data semantics for a chosen domain of discourse. Typically it specifies relations between kinds of things, but may also include relations with individual things. It can provide sharable, stable, and organized structure of information requirements or knowledge for the domain context.[1] The term information model in general is used for models of individual things, such as facilities, buildings, process plants, etc. In those cases the concept is specialised to facility information model, building information model, plant information model, etc. Such an information model is an integration of a model of the facility with the data and documents about the facility. Within the field of software engineering and data modeling an information model is usually an abstract, formal representation of entity types that may include their properties, relationships and the operations that can be performed on them. The entity types in the model may be kinds of real-world objects, such as devices in a network, or occurrences, or they may themselves be abstract, such as for the entities used in a billing system. Typically, they are used to model a constrained domain that can be described by a closed set of entity types, properties, relationships and operations. An information model provides formalism to the description of a problem domain without constraining how that description is mapped to an actual implementation in software. There may be many mappings of the information model. Such mappings are called data models, irrespective of whether they are object models (e.g. using UML), entity relationship models or XML schemas. References: S/W Engg. Roger Pressman Lecture 12(13/10/2020) Information modeling languages
- 25. A sample ERdiagram. Database requirements for a CD collection in EXPRESS-G notation. In 1976, an entity-relationship (ER) graphic notation was introduced by Peter Chen. He stressed that it was a "semantic" modelling technique and independent of any database modelling techniques such as Hierarchical, CODASYL, Relational etc.[2] Since then, languages for information models have continued to evolve. Some examples are the Integrated Definition Language 1 Extended (IDEF1X), the EXPRESS language and the Unified Modeling Language (UML).[1] Research by contemporaries of Peter Chen such as J.R.Abrial (1974) and G.M Nijssen (1976) led to today's Fact Oriented Modeling (FOM) languages which are based on linguistic propositions rather than on "entities". FOM tools can be used to generate an ER model which means that the modeler can avoid the time-consuming and error prone practice of manual normalization. Object-Role Modeling language (ORM) and Fully Communication Oriented Information Modeling (FCO-IM) are both research results, based upon earlier research. In the 1980s there were several approaches to extend Chen’s Entity Relationship Model. Also important in this decade is REMORA by Colette Rolland.[3] The ICAM Definition (IDEF) Language was developed from the U.S. Air Force ICAM Program during the 1976 to 1982 timeframe.[4] The objective of the ICAM Program, according to Lee (1999), was to increase manufacturing productivity through the systematic application of computer technology. IDEF includes three different modeling methods: IDEF0, IDEF1, and IDEF2 for producing a functional model, an information model, and a dynamic model respectively. IDEF1X is an extended version of IDEF1. The language is in the public domain. It
- 26. is a graphicalrepresentation and is designed using the ER approach and the relational theory. It is used to represent the “real world” in terms of entities, attributes, and relationships between entities. Normalization is enforced by KEY Structures and KEY Migration. The language identifies property groupings (Aggregation) to form complete entity definitions.[1] EXPRESS was created as ISO 10303-11 for formally specifying information requirements of product data model. It is part of a suite of standards informally known as the STandard for the Exchange of Product model data (STEP). It was first introduced in the early 1990s.[5][6] The language, according to Lee (1999), is a textual representation. In addition, a graphical subset of EXPRESS called EXPRESS-G is available. EXPRESS is based on programming languages and the O-O paradigm. A number of languages have contributed to EXPRESS. In particular, Ada, Algol, C, C++, Euler, Modula-2, Pascal, PL/1, and SQL. EXPRESS consists of language elements that allow an unambiguous object definition and specification of constraints on the objects defined. It uses SCHEMA declaration to provide partitioning and it supports specification of data properties, constraints, and operations.[1] UML is a modeling language for specifying, visualizing, constructing, and documenting the artifacts, rather than processes, of software systems. It was conceived originally by Grady Booch, James Rumbaugh, and Ivar Jacobson. UML was approved by the Object Management Group (OMG) as a standard in 1997. The language, according to Lee (1999), is non-proprietary and is available to the public. It is a graphical representation. The language is based on the objected-oriented paradigm. UML contains notations and rules and is designed to represent data requirements in terms of O-O diagrams. UML organizes a model in a number of views that present different aspects of a system. The contents of a view are described in diagrams that are graphs with model elements. A diagram contains model elements that represent common O-O concepts such as classes, objects, messages, and relationships among these concepts.[1] IDEF1X, EXPRESS, and UML all can be used to create a conceptual model and, according to Lee (1999), each has its own characteristics. Although some may lead to a natural usage (e.g., implementation), one is not necessarily better than another. In practice, it may require more than one language to develop all information models when an application is complex. In fact, the modeling practice is often more important than the language chosen.[1] Information models can also be expressed in formalized natural languages, such as Gellish. Gellish, which has natural language variants Gellish Formal English, Gellish Formal Dutch (Gellish Formeel Nederlands), etc. is an information representation language or modeling language that is defined in the Gellish smart Dictionary-Taxonomy, which has the form of a Taxonomy/Ontology. A Gellish Database is not only suitable to store information models, but also knowledge models, requirements models and dictionaries, taxonomies and ontologies. Information models in Gellish English use Gellish Formal English expressions. For example, a geographic information model might consist of a number of Gellish Formal English expressions, such as: - the Eiffel tower <is located in> Paris - Paris <is classified as a> city whereas information requirements and knowledge can be expressed for example as follows: - tower <shall be located in a> geographical area - city <is a kind of> geographical area
- 27. Such Gellish expressionsuse names of concepts (such as 'city') and relation types (such as ⟨is located in⟩ and ⟨is classified as a⟩) that should be selected from the Gellish Formal English Dictionary-Taxonomy (or of your own domain dictionary). The Gellish English Dictionary- Taxonomy enables the creation of semantically rich information models, because the dictionary contains definitions of more than 40000 concepts, including more than 600 standard relation types. Thus, an information model in Gellish consists of a collection of Gellish expressions that use those phrases and dictionary concepts to express facts or make statements, queries and answers. Standard sets of information models[edit] The Distributed Management Task Force (DMTF) provides a standard set of information models for various enterprise domains under the general title of the Common Information Model (CIM). Specific information models are derived from CIM for particular management domains. The TeleManagement Forum (TMF) has defined an advanced model for the Telecommunication domain (the Shared Information/Data model, or SID) as another. This includes views from the business, service and resource domains within the Telecommunication industry. The TMF has established a set of principles that an OSS integration should adopt, along with a set of models that provide standardized approaches. The models interact with the information model (the Shared Information/Data Model, or SID), via a process model (the Business Process Framework (eTOM), or eTOM) and a life cycle model. Levels in Data Flow Diagrams (DFD) In Software engineering DFD(data flow diagram) can be drawn to represent the system of different levels of abstraction. Higher level DFDs are partitioned into low levels-hacking more information and functional elements. Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see mainly 3 levels in data flow diagram, which are: 0-level DFD, 1-level DFD, and 2-level DFD. 0-level DFD: It is also known as context diagram. It’s designed to be an abstraction view, showing the system as a single process with its relationship to external entities. It represent the entire system as single bubble with input and output data indicated by incoming/outgoing arrows.
- 28. References: GeeksForGeeks JavaT Jalote Pankaj; S/W Engg Pressman roger; S/W Engg Lecture 13(15/10/2020) Levels in Data Flow Diagrams (DFD) In Software engineering DFD(data flow diagram) can be drawn to represent the system of different levels of abstraction. Higher level DFDs are partitioned into low levels-hacking more information and functional elements. Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see mainly 3 levels in data flow diagram, which are: 0-level DFD, 1-level DFD, and 2-level DFD. 0-level DFD: It is also known as context diagram. It’s designed to be an abstraction view, showing the system as a single process with its relationship to external entities. It represent the entire system as single bubble with input and output data indicated by incoming/outgoing arrows.
- 29. Lecture 13(13/10/2020) 1-level DFD: In1-level DFD, context diagram is decomposed into multiple bubbles/processes.in this level we highlight the main functions of the system and breakdown the high level process of 0-level DFD into subprocesses.
- 30. 2-level DFD: 2-level DFDgoes one step deeper into parts of 1-level DFD.It can be used to plan or record the specific/necessary detail about the system’s functioning.
- 31. Entity-Relationship Diagrams ER-modeling isa data modeling method used in software engineering to produce a conceptual data model of an information system. Diagrams created using this ER-modeling method are called Entity-Relationship Diagrams or ER diagrams or ERDs. Purpose of ERD o The database analyst gains a better understanding of the data to be contained in the database through the step of constructing the ERD. o The ERD serves as a documentation tool.
- 32. o Finally, theERD is used to connect the logical structure of the database to users. In particular, the ERD effectively communicates the logic of the database to users. Components of an ER Diagrams 1. Entity An entity can be a real-world object, either animate or inanimate, that can be merely identifiable. An entity is denoted as a rectangle in an ER diagram. For example, in a school database, students, teachers, classes, and courses offered can be treated as entities. All these entities have some attributes or properties that give them their identity. Entity Set An entity set is a collection of related types of entities. An entity set may include entities with attribute sharing similar values. For example, a Student set may contain all the students of a school; likewise, a Teacher set may include all the teachers of a school from all faculties. Entity set need not be disjoint.
- 33. 2. Attributes Entities aredenoted utilizing their properties, known as attributes. All attributes have values. For example, a student entity may have name, class, and age as attributes. There exists a domain or range of values that can be assigned to attributes. For example, a student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot be negative, etc. There are four types of Attributes: 1. Key attribute 2. Composite attribute 3. Single-valued attribute 4. Multi-valued attribute 5. Derived attribute 1. Key attribute: Key is an attribute or collection of attributes that uniquely identifies an entity among the entity set. For example, the roll_number of a student makes him identifiable among students.
- 34. Lecture 14(17/10/2020) 2-level DFD: 2-levelDFD goes one step deeper into parts of 1-level DFD.It can be used to plan or record the specific/necessary detail about the system’s functioning.
- 35. Entity-Relationship Diagrams ER-modeling isa data modeling method used in software engineering to produce a conceptual data model of an information system. Diagrams created using this ER-modeling method are called Entity-Relationship Diagrams or ER diagrams or ERDs. Purpose of ERD o The database analyst gains a better understanding of the data to be contained in the database through the step of constructing the ERD.
- 36. o The ERDserves as a documentation tool. o Finally, the ERD is used to connect the logical structure of the database to users. In particular, the ERD effectively communicates the logic of the database to users. Components of an ER Diagrams 1. Entity An entity can be a real-world object, either animate or inanimate, that can be merely identifiable. An entity is denoted as a rectangle in an ER diagram. For example, in a school database, students, teachers, classes, and courses offered can be treated as entities. All these entities have some attributes or properties that give them their identity. Entity Set An entity set is a collection of related types of entities. An entity set may include entities with attribute sharing similar values. For example, a Student set may contain all the students of a school; likewise, a Teacher set may include all the teachers of a school from all faculties. Entity set need not be disjoint.
- 37. 2. Attributes Entities aredenoted utilizing their properties, known as attributes. All attributes have values. For example, a student entity may have name, class, and age as attributes. There exists a domain or range of values that can be assigned to attributes. For example, a student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot be negative, etc. There are four types of Attributes: 6. Key attribute 7. Composite attribute 8. Single-valued attribute 9. Multi-valued attribute 10. Derived attribute 1. Key attribute: Key is an attribute or collection of attributes that uniquely identifies an entity among the entity set. For example, the roll_number of a student makes him identifiable among students.
- 38. Lecture 15 26/10/2020 There aremainly three types of keys: 1. Super key: A set of attributes that collectively identifies an entity in the entity set. 2. Candidate key: A minimal super key is known as a candidate key. An entity set may have more than one candidate key. 3. Primary key: A primary key is one of the candidate keys chosen by the database designer to uniquely identify the entity set. 2. Composite attribute: An attribute that is a combination of other attributes is called a composite attribute. For example, In student entity, the student address is a composite attribute as an address is composed of other characteristics such as pin code, state, country.
- 39. 3. Single-valued attribute:Single-valued attribute contain a single value. For example, Social_Security_Number. 4. Multi-valued Attribute: If an attribute can have more than one value, it is known as a multi-valued attribute. Multi-valued attributes are depicted by the double ellipse. For example, a person can have more than one phone number, email-address, etc. 5. Derived attribute: Derived attributes are the attribute that does not exist in the physical database, but their values are derived from other attributes present in the database. For example, age can be derived from date_of_birth. In the ER diagram, Derived attributes are depicted by the dashed ellipse.
- 40. 3. Relationships The associationamong entities is known as relationship. Relationships are represented by the diamond-shaped box. For example, an employee works_at a department, a student enrolls in a course. Here, Works_at and Enrolls are called relationships.
- 41. Relationship set A setof relationships of a similar type is known as a relationship set. Like entities, a relationship too can have attributes. These attributes are called descriptive attributes. Degree of a relationship set The number of participating entities in a relationship describes the degree of the relationship. The three most common relationships in E-R models are: 1. Unary (degree1) 2. Binary (degree2) 3. Ternary (degree3) 1. Unary relationship: This is also called recursive relationships. It is a relationship between the instances of one entity type. For example, one person is married to only one person. 2. Binary relationship: It is a relationship between the instances of two entity types. For example, the Teacher teaches the subject.
- 42. 3. Ternary relationship:It is a relationship amongst instances of three entity types. In fig, the relationships "may have" provide the association of three entities, i.e., TEACHER, STUDENT, and SUBJECT. All three entities are many-to-many participants. There may be one or many participants in a ternary relationship. In general, "n" entities can be related by the same relationship and is known as n-ary relationship. Lecture 16 Date : 28/10/2020 Cardinality Cardinality describes the number of entities in one entity set, which can be associated with the number of entities of other sets via relationship set. Types of Cardinalities 1. One to One: One entity from entity set A can be contained with at most one entity of entity set B and vice versa. Let us assume that each student has only one student ID, and each student ID is assigned to only one person. So, the relationship will be one to one. Using Sets, it can be represented as:
- 43. 2. One tomany: When a single instance of an entity is associated with more than one instances of another entity then it is called one to many relationships. For example, a client can place many orders; a order cannot be placed by many customers. Using Sets, it can be represented as: 3. Many to One: More than one entity from entity set A can be associated with at most one entity of entity set B, however an entity from entity set B can be associated with more than one entity from entity set A. For example - many students can study in a single college, but a student cannot study in many colleges at the same time. Using Sets, it can be represented as: 4. Many to Many: One entity from A can be associated with more than one entity from B and vice-versa. For example, the student can be assigned to many projects, and a project can be assigned to many students. Software Engineering | Decision Table Decision table is a brief visual representation for specifying which actions to perform depending on given conditions. The information represented in decision tables can also be represented as decision trees or in a programming language using if-then-else and switch-case statements. A decision table is a good way to settle with different combination inputs with their corresponding outputs and also called cause-effect table. Reason to call cause-effect table is a related logical diagramming technique called cause-effect graphing that is basically used to obtain the decision table. Importance of Decision Table: 1. Decision tables are very much helpful in test design technique. 2. It helps testers to search the effects of combinations of different inputs and other software states that must correctly implement business rules. 3. It provides a regular way of stating complex business rules, that is helpful for developers as well as for testers. 4. It assists in development process with developer to do a better job. Testing with all combination might be impractical. 5. A decision table is basically an outstanding technique used in both testing and requirements management. 6. It is a structured exercise to prepare requirements when dealing with complex business rules. 7. It is also used in model complicated logic. Decision Table in test designing: Blank Decision Table CONDITIONS STEP 1 STEP 2 STEP 3 STEP 4 Condition 1
- 44. Condition 2 Condition 3 Condition4 Decision Table: Combinations CONDITIONS STEP 1 STEP 2 STEP 3 STEP 4 Condition 1 Y Y N N Condition 2 Y N Y N Condition 3 Y N N Y Condition 4 N Y Y N Advantage of Decision Table: 1. Any complex business flow can be easily converted into the test scenarios & test cases using this technique. 2. Decision tables work iteratively that means the table created at the first iteration is used as input table for next tables. The iteration is done only if the initial table is not satisfactory. 3. Simple to understand and everyone can use this method design the test scenarios & test cases. 4. It provide complete coverage of test cases which help to reduce the rework on writing test scenarios & test cases. 5. These tables guarantee that we consider every possible combination of condition values. This is known as its completeness property. References: GeeksForGeeks Java T Software Engineering(MCA 512) MCA V Sem Unit-II: Software Requirement Specifications (SRS) Faculty: Ms. Savita Mittal Lecture 17 A software requirements specification (SRS) is a description of a software system to be developed. It is modeled after business requirements specification (CONOPS), also known as a stakeholder requirements specification (StRS).[citation needed] The software requirements specification lays out functional and non-functional requirements, and it may include a set of use
- 45. cases that describeuser interactions that the software must provide to the user for perfect interaction. Software requirements specification establishes the basis for an agreement between customers and contractors or suppliers on how the software product should function (in a market-driven project, these roles may be played by the marketing and development divisions). Software requirements specification is a rigorous assessment of requirements before the more specific system design stages, and its goal is to reduce later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules.[1] Used appropriately, software requirements specifications can help prevent software project failure.[2] The software requirements specification document lists sufficient and necessary requirements for the project development.[3] To derive the requirements, the developer needs to have clear and thorough understanding of the products under development. This is achieved through detailed and continuous communications with the project team and customer throughout the software development process. The SRS may be one of a contract's deliverable data item descriptions[4] or have other forms of organizationally-mandated content. Typically a SRS is written by a technical writer, a systems architect, or a software programmer.[5] Structure An example organization of an SRS is as follows:[6] 1. Purpose 1. Definitions 2. Background 3. System overview 4. References 2. Overall description 1. Product perspective 1. System Interfaces 2. User interfaces 3. Hardware interfaces 4. Software interfaces 5. Communication Interfaces 6. Memory constraints 2. Design constraints 1. Operations 2. Site adaptation requirements 3. Product functions 4. User characteristics 5. Constraints, assumptions and dependencies 3. Specific requirements 1. External interface requirements 2. Functional requirements
- 46. 3. Performance requirements 4.Logical database requirement 5. Software system attributes 1. Reliability 2. Availability 3. Security 4. Maintainability 5. Portability 6. Functional requirements 1. Functional partitioning 2. Functional description 3. Control description 7. Environment characteristics 1. Hardware 2. Peripherals 3. Users 8. Other Goals The software requirements specification (SRS) is a communication tool between users and software designers. The specific goals of the SRS are as follows: Facilitating reviews Describing the scope of work Providing a reference to software designers (i.e. navigation aids, document structure) Providing a framework for testing primary and secondary use cases Including features to customer requirements Providing a platform for ongoing refinement (via incomplete specs or questions) Requirements smell Following the idea of code smells, the notion of requirements smell has been proposed to describe issues in requirements specification where the requirement is not necessarily wrong but could be problematic. Examples of requirements smells are subjective language, ambiguous adverbs and adjectives, superlatives and negative statements. References: Java T Compiled By: Ms. Savita Mittal
- 47. Software Engineering(MCA 512) MCAV Sem Unit-II: Software Requirement Specifications (SRS) Faculty: Ms. Savita Mittal Lecture 18 Topic: Verification and Validation The Software Quality Assurance (SQA) process compromises of the verification and validation process of the software code. In general, guaranteeing that the software conforms to its specification while meeting the customer needs. Let us compare and contrast the verification and validation process. Verification and validation begin by reviewing the requirements and covering the design and analysis of the code up to the product testing. For this reason, verification demands to check that the program meets specified requirements. While, on the other hand, validation requires examining that the software product meets the client expectation as well as a formal proof of program correctness (IEEE, 1990). Software Quality Assurance (SQA) is a set of activities for ensuring quality in software engineering processes. It ensures that developed software meets and complies with the defined or
- 48. standardized quality specifications.SQA is an ongoing process within the Software Development Life Cycle (SDLC) that routinely checks the developed software to ensure it meets the desired quality measures. SQA practices are implemented in most types of software development, regardless of the underlying software development model being used. SQA incorporates and implements software testing methodologies to test the software. Rather than checking for quality after completion, SQA processes test for quality in each phase of development, until the software is complete. With SQA, the software development process moves into the next phase only once the current/previous phase complies with the required quality standards. SQA generally works on one or more industry standards that help in building software quality guidelines and implementation strategies. It includes the following activities − Process definition and implementation Auditing Training Processes could be − Software Development Methodology Project Management Configuration Management Requirements Development/Management Estimation Software Design Testing, etc. Once the processes have been defined and implemented, Quality Assurance has the following responsibilities − Identify the weaknesses in the processes Correct those weaknesses to continually improve the process Components of SQA System An SQA system always combines a wide range of SQA components. These components can be classified into the following six classes − Pre-project components This assures that the project commitments have been clearly defined considering the resources required, the schedule and budget; and the development and quality plans have been correctly determined.
- 49. Components of projectlife cycle activities assessment The project life cycle is composed of two stages: the development life cycle stage and the operation–maintenance stage. The development life cycle stage components detect design and programming errors. Its components are divided into the following sub-classes: Reviews, Expert opinions, and Software testing. The SQA components used during the operation–maintenance phase include specialized maintenance components as well as development life cycle components, which are applied mainly for functionality to improve the maintenance tasks. Components of infrastructure error prevention and improvement The main objective of these components, which is applied throughout the entire organization, is to eliminate or at least reduce the rate of errors, based on the organization’s accumulated SQA experience. Components of software quality management This class of components deal with several goals, such as the control of development and maintenance activities, and the introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes. Components of standardization, certification, and SQA system assessment These components implement international professional and managerial standards within the organization. The main objectives of this class are utilization of international professional knowledge, improvement of coordination of the organizational quality systems with other organizations, and assessment of the achievements of quality systems according to a common scale. The various standards may be classified into two main groups: quality management standards and project process standards. Organizing for SQA – the human components The SQA organizational base includes managers, testing personnel, the SQA unit and the persons interested in software quality such as SQA trustees, SQA committee members, and SQA forum members. Their main objectives are to initiate and support the implementation of SQA components, detect deviations from SQA procedures and methodology, and suggest improvements. Compiled By: Savita Mittal Software Engineering(MCA 512) MCA V Sem Unit-II: Software Requirement Specifications (SRS)
- 50. Faculty: Ms. SavitaMittal Lecture 19 Topic: ISO 9000 ; SEI-CMM The ISO 9000 family of standards is the same across the globe even though they are called by different names. Each member country has their own entity authorized by ISO to manage the standards, but they are all the same exact ISO 9000 quality documents. What is the ISO 9000 series of quality management system standards? The ISO 9000 series was created by the International Organization for Standardization (ISO) as international requirements and guidelines for quality management systems. It was originally introduced in 1987 and over the years has established itself in the global economy having been adopted in over 178 countries with over one million registrations. The phrase “ISO 9000 family” or “ISO 9000 series” refers to a group of quality management standards which are process standards (not product standards). ISO 9000 Quality management systems – Fundamentals and Vocabulary, referenced in all ISO 9000 Standards. ISO 9001 Quality management systems – Requirements, contains the requirements an organization must comply with to become ISO 9001 certified. ISO 9002 – Guidelines for the application of ISO 9001:2015 ISO 9004 – Managing for the sustained success of an organization, provides guidelines for sustaining QMS success through evaluation and performance improvement. ISO 9001:2015 is the current version of the ISO 9001 standard. ISO 9001 lists requirements, while the other standards in the 9000 family provide guidelines and information. People often say “ISO 9000 certified“, but what they mean is they have met the requirements of the ISO 9001 standard. Read more about ISO 9001 Certification. The ISO 9000 Series of Quality Standards is not industry specific and is applicable to any manufacturing, distribution or service organization. It is managed by Technical Committee (TC) 176, comprised of international members from many industries and backgrounds. What are the older (obsolete) ISO 9000 quality standards? ISO 9000 (1994) originally had three QMS models depending on the primary function:
- 51. ISO 9001:1994Model for quality assurance in design, development, production, installation, and servicing was for companies and organizations whose activities included the creation of new products. ISO 9002:1994 Model for quality assurance in production, installation, and servicing had basically the same material as ISO 9001 but without covering the creation of new products. Learn more about ISO 9002. ISO 9003:1994 Model for quality assurance in final inspection and test covered only the final inspection of finished product, with no concern for how the product was produced. Learn more about ISO 9003. All of these were combined into ISO 9001:2000, which was updated to ISO 9001:2008 and is now ISO 9001:2015. What standards support the ISO 9000 Series of Quality Standards? Other ISO quality standards were created to support the ISO 9000 family, and not all start with ISO 9001: ISO 10000 Series of Standards What is ISO 19011? What is ISO/IEC 17021? Standards based upon ISO 9001 There are other ISO quality standards created based up the 9000 family which are specific to certain industries (Aerospace, Automotive Medical Devices, etc): Software Engineering | Capability maturity model (CMM) CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in 1987. It is not a software process model. It is a framework which is used to analyse the approach and techniques followed by any organization to develop software products. It also provides guidelines to further enhance the maturity of the process used to develop those software products. It is based on profound feedback and development practices adopted by the most successful organizations worldwide.
- 52. This modeldescribes a strategy for software process improvement that should be followed by moving through 5 different levels. Each level of maturity shows a process capability level. All the levels except level-1 are further described by Key Process Areas (KPA’s). Key Process Areas (KPA’s): Each of these KPA’s defines the basic requirements that should be met by a software process in order to satisfy the KPA and achieve that level of maturity. Conceptually, key process areas form the basis for management control of the software project and establish a context in which technical methods are applied, work products like models, documents, data, reports, etc. are produced, milestones are established, quality is ensured and change is properly managed.
- 53. The 5 levelsof CMM are as follows: Level-1: Initial –
- 54. No KPA’sdefined. Processes followed are adhoc and immature and are not well defined. Unstable environment for software dvelopment. No basis for predicting product quality, time for completion, etc. Level-2: Repeatable – Focuses on establishing basic project management policies. Experience with earlier projects is used for managing new similar natured projects. Project Planning- It includes defining resources required, goals, constraints, etc. for the project. It presents a detailed plan to be followed systematically for successful completion of a good quality software. Configuration Management- The focus is on maintaining the performance of the software product, including all its components, for the entire lifecycle. Requirements Management- It includes the management of customer reviews and feedback which result in some changes in the requirement set. It also consists of accommodation of those modified requirements. Subcontract Management- It focuses on the effective management of qualified software contractors i.e. it manages the parts of the software which are developed by third parties. Software Quality Assurance- It guarantees a good quality software product by following certain rules and quality standard guidelines while development. Level-3: Defined – At this level, documentation of the standard guidelines and procedures takes place. It is a well defined integrated set of project specific software engineering and management processes. Peer Reviews- In this method, defects are removed by using a number of review methods like walkthroughs, inspections, buddy checks, etc. Intergroup Coordination- It consists of planned interactions between different development teams to ensure efficient and proper fulfilment of customer needs. Organization Process Definition- It’s key focus is on the development and maintenance of the standard development processes. Organization Process Focus- It includes activities and practices that should be followed to improve the process capabilities of an organization. Training Programs- It focuses on the enhancement of knowledge and skills of the team members including the developers and ensuring an increase in work efficiency. Level-4: Managed – At this stage, quantitative quality goals are set for the organization for software products as well as software processes. The measurements made help the organization to predict the product and process quality within some limits defined quantitatively.
- 55. Software QualityManagement- It includes the establishment of plans and strategies to develop a quantitative analysis and understanding of the product’s quality. Quantitative Management- It focuses on controlling the project performance in a quantitative manner. Level-5: Optimizing – This is the highest level of process maturity in CMM and focuses on continuous process improvement in the organization using quantitative feedback. Use of new tools, techniques and evaluation of software processes is done to prevent recurrence of known defects. Process Change Management- Its focus is on the continuous improvement of organization’s software processes to improve productivity, quality and cycle time for the software product. Technology Change Management- It consists of identification and use of new technologies to improve product quality and decrease the product development time. Defect Prevention- It focuses on identification of causes of defects and to prevent them from recurring in future projects by improving project defined process. Compiled By : Savita Mittal Unit III – Software Design Lecture 20 Topic : Basic Concept Of S/W Design Software Design is the process to transform the user requirements into some suitable form, which helps the programmer in software coding and implementation. During the software design phase, the design document is produced, based on the customer requirements as documented in the SRS document. Hence the aim of this phase is to transform the SRS document into the design document. The following items are designed and documented during the design phase: Different modules required. Control relationships among modules. Interface among different modules. Data structure among the different modules. Algorithms required to implement among the individual modules.
- 56. Objectives of SoftwareDesign: 1. Correctness: A good design should be correct i.e. it should correctly implement all the functionalities of the system. 2. Efficiency: A good software design should address the resources, time and cost optimization issues. 3. Understandability: A good design should be easily understandable, for which it should be modular and all the modules are arranged in layers. 4. Completeness: The design should have all the components like data structures, modules, and external interfaces, etc. 5. Maintainability: A good software design should be easily amenable to change whenever a change request is made from the customer side. Software Design Concepts: Concepts are defined as a principal idea or invention that comes in our mind or in thought to understand something. The software design concept simply means the idea or principle behind the design. It describes how you plan to solve the problem of designing software, the logic, or thinking behind how you will design software. It allows the software engineer to create the model of the system or software or product that is to be developed or built. The software design concept provides a supporting and essential structure or model for developing the right software. There are many concepts of software design and some of them are given below:
- 57. Following points shouldbe considered while designing a Software: 1. Abstraction- hide relevant data Abstraction simply means to hide the details to reduce complexity and increases efficiency or quality. Different levels of Abstraction are necessary and must be applied at each stage of the design process so that any error that is present can be removed to increase the efficiency of the software solution and to refine the software solution. The solution should be described in broadways that cover a wide range of different things at a higher level of abstraction and a more detailed description of a solution of software should be given at the lower level of abstraction. 2. Modularity- subdivide the system Modularity simply means to divide the system or project into smaller parts to reduce the complexity of the system or project. In the same way, modularity in design means to subdivide a system into smaller parts so that these parts can be created independently and then use these parts in different systems to perform different functions. It is necessary to divide the software into components known as modules because nowadays there are different software available like Monolithic software that is hard to grasp for software engineers. So, modularity is design has now become a trend and is also important. 3. Architecture- design a structure of something Architecture simply means a technique to design a structure of something. Architecture in designing software is a concept that focuses on various elements and the data of the
- 58. structure. These componentsinteract with each other and use the data of the structure in architecture. 4. Refinement- removes impurities Refinement simply means to refine something to remove any impurities if present and increase the quality. The refinement concept of software design is actually a process of developing or presenting the software or system in a detailed manner that means to elaborate a system or software. Refinement is very necessary to find out any error if present and then to reduce it. 5. Pattern- a repeated form The pattern simply means a repeated form or design in which the same shape is repeated several times to form a pattern. The pattern in the design process means the repetition of a solution to a common recurring problem within a certain context. 6. Information Hiding- hide the information Information hiding simply means to hide the information so that it cannot be accessed by an unwanted party. In software design, information hiding is achieved by designing the modules in a manner that the information gathered or contained in one module is hidden and it cant be accessed by any other modules. 7. Refactoring- reconstruct something Refactoring simply means to reconstruct something in such a way that it does not affect the behavior or any other features. Refactoring in software design means to reconstruct the design to reduce and complexity and simplify it without affecting the behavior or its functions. Fowler has defined refactoring as “the process of changing a software system in a way that it won’t affect the behavior of the design and improves the internal structure”. Different levels of Software Design: There are three different levels of software design. They are: 1. Architectural Design: The architecture of a system can be viewed as the overall structure of the system & the way in which structure provides conceptual integrity of the system. The architectural design identifies the software as a system with many components interacting with each other. At this level, the designers get the idea of the proposed solution domain. 2. Preliminary or high-level design: Here the problem is decomposed into a set of modules, the control relationship among various modules identified and also the interfaces among various modules are identified. The outcome of this stage is called the program architecture. Design representation techniques used in this stage are structure chart and UML. 3. Detailed design: Once the high level design is complete, detailed design is undertaken. In detailed design, each module is examined carefully to design the data structure and algorithms. The stage outcome is documented in the form of a module specification document. Compiled By: Ms.Savita Mittal
- 59. S/W Engineering Unit 3 Lecture21 Architectural Design Introduction: The software needs the architectural design to represents the design of software. IEEE defines architectural design as “the process of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system.” The software that is built for computer-based systems can exhibit one of these many architectural styles. Each style will describe a system category that consists of : A set of components(eg: a database, computational modules) that will perform a function required by the system. The set of connectors will help in coordination, communication, and cooperation between the components. Conditions that how components can be integrated to form the system. Semantic models that help the designer to understand the overall properties of the system. The use of architectural styles is to establish a structure for all the components of the system. Taxonomy of Architectural styles: 1. Data centred architectures: A data store will reside at the center of this architecture and is accessed frequently by the other components that update, add, delete or modify the data present within the store. The figure illustrates a typical data centered style. The client software access a central repository. Variation of this approach are used to transform the repository into a blackboard when data related to client or data of interest for the client change the notifications to client software. This data-centered architecture will promote integrability. This means that the existing components can be changed and new client components can be added to the architecture without the permission or concern of other clients. Data can be passed among clients using blackboard mechanism.
- 60. 2. Data flowarchitectures: This kind of architecture is used when input data to be transformed into output data through a series of computational manipulative components. The figure represents pipe-and-filter architecture since it uses both pipe and filter and it has a set of components called filters connected by pipes. Pipes are used to transmit data from one component to the next. Each filter will work independently and is designed to take data input of a certain form and produces data output to the next filter of a specified form. The filters don’t require any knowledge of the working of neighboring filters. If the data flow degenerates into a single line of transforms, then it is termed as batch sequential. This structure accepts the batch of data and then applies a series of sequential components to transform it.
- 61. 3. Call andReturn architectures: It is used to create a program that is easy to scale and modify. Many sub-styles exist within this category. Two of them are explained below. Remote procedure call architecture: This components is used to present in a main program or sub program architecture distributed among multiple computers on a network. Main program or Subprogram architectures: The main program structure decomposes into number of subprograms or function into a control hierarchy. Main program contains number of subprograms that can invoke other components.
- 62. 4. Object Orientedarchitecture: The components of a system encapsulate data and the operations that must be applied to manipulate the data. The coordination and communication between the components are established via the message passing. 5. Layered architecture: A number of different layers are defined with each layer performing a well-defined set of operations. Each layer will do some operations that becomes closer to machine instruction set progressively. At the outer layer, components will receive the user interface operations and at the inner layers, components will perform the operating system interfacing(communication and coordination with OS) Intermediate layers to utility services and application software functions. Compiled By: Ms. Savita Mittal Lecture 22 2.1 Modularisation Modularisation (Morbach, Wiesner & Marquardt 2009, Doran, Tamma & Iannone 2007) extends in three dimensions of the ontology: i) domain, ii) level, and iii) properties. Domain modularisation refers to the creation of different modules at the domain level. The main criteria are the knowledge representation and the intended use of the ontology in domain modularisation.
- 63. By using differentand more importantly modules representing distinct parts of the domain, the ontology can be reused as a whole, but also in parts, as demonstrated by the example of eSymbiosis ontology in Figure 1, where distinct segments of the domain refer to processing technologies, materials, description of the process using attributes, and description of participants. Sign in to download hi-res image Figure 1. eSymbiosis ontology domain modularisation Level modularisation serves a similar purpose as the domain modularisation (Figure 2); it is used to differentiate the whole level of abstraction instead of distinct knowledge segments. It is more useful for the reuse of top-level and meta-level ontologies, which usually consist of fewer classes and properties in comparison to the domain level. Sign in to download hi-res image Figure 2. eSymbiosis ontology level modularisation As with concepts, modularisation of the properties in the ontology is also possible and useful. Properties can be grouped along their range, their function, or both. Grouping along the range
- 64. supports reusability ofseparate modules of the ontology while grouping along the function supports the reusability of the ontology as a whole, but it also supplements the represented knowledge, as it enables the use of these properties in an application in a more structured approach aiding specific functionalities of the user . Modularization Smells Girish Suryanarayana, ... Tushar Sharma, in Refactoring for Software Design Smells, 2015 5.2.1 Rationale Modularization concerns the logical partitioning of a software design so that the design becomes easy to understand and maintain. One of the key enabling techniques for effective modularization is to “decompose abstractions to manageable size.” In this context, Lanza and Marinescu [21] recommend that “operations and classes should have a harmonious size, i.e., they should avoid both size extremities.” When an abstraction has complex methods or a large number of methods, it violates this enabling technique and the principle of modularization. Since the abstraction is inadequately decomposed, we name this smell Insufficient Modularization. MULTIFACETED ABSTRACTION VERSUS INSUFFICIENT MODULARIZATION Note that Multifaceted Abstraction smell (Section 3.4) is different from Insufficient Modularization smell. In Multifaceted Abstraction, an abstraction addresses more than one responsibility, thereby violating the Single Responsibility Principle (SRP). In Insufficient Modularization, an abstraction violates the Principle of Decomposition, indicating that the abstraction is large, complex, or both. Interestingly, these two smells often occur together: It is common to see a large and complex abstraction that has multiple responsibilities. However, they are different smells: An abstraction could have a single responsibility, but could still be large and complex. Similarly, an abstraction could be small, but could still have multiple responsibilities. Design modularity enables production modularity Modularization of platform architectures matters also because it determines whether development around a platform can feasibly be organized as an ecosystem or whether it must be done within the boundaries of a single organization. Different architectures impose different constraints on those who interact with it or are exposed to it (van Schewick, 2012, p. 4). The preceding discussion focuses primarily on modularity in design, overlooking another kind of modularity—modularity in production (Gamba and Fusari, 2009), which refers to modularity in the logic used to organize production of a design. A traditionally integrated organization represents a monolithic organizing logic whereas a distributed ecosystem composed on many independent app developers represents a modular organizing logic used for producing the design. Modularity of production is a platform governance decision (the focus of the next chapter), but one whose feasibility is determined by modularity of the platform’s design. Lack of design modularity, in contrast, makes production modularity infeasible (Langlois, 2002; Sanchez and Mahoney, 1996). Architectural choices therefore preordain the realm of execution possibilities. This is the essence of the mirroring principle. Design modularity and production modularity are therefore fundamentally isomorphic (i.e., design modularity enables production modularity) (Baldwin and Clark, 2000, p. 12; Hoetker, 2006). A platform’s architecture is therefore particularly decisive in the evolution of its ecosystem because it is closely intertwined with the
- 65. organization of theecosystem: who chooses to participate, how much they are willing and able to invest in creating complementary innovations around a platform, and their incentives to innovate. Reference: 28th European Symposium on Computer Aided Process Engineering Nikolaos Trokanas, ... Franjo Cecelja, in Computer Aided Chemical Engineering, 2018 S/W Engg.(MCA 512) Unit 3 Lecture 23 Design Structure Charts Structure Chart represent hierarchical structure of modules. It breaks down the entire system into lowest functional modules, describe functions and sub-functions of each module of a system to a greater detail. Structure Chart partitions the system into black boxes (functionality of the system is known to the users but inner details are unknown). Inputs are given to the black boxes and appropriate outputs are generated. Modules at top level called modules at low level. Components are read from top to bottom and left to right. When a module calls another, it views the called module as black box, passing required parameters and receiving results. Symbols used in construction of structured chart 1. Module It represents the process or task of the system. It is of three types. Control Module A control module branches to more than one sub module. Sub Module Sub Module is a module which is the part (Child) of another module. Library Module Library Module are reusable and invokable from any module.
- 66. 2. Conditional Call Itrepresents that control module can select any of the sub module on the basis of some condition. 3. Loop (Repetitive call of module) It represents the repetitive execution of module by the sub module. A curved arrow represents loop in the module.
- 67. All the submodules cover by the loop repeat execution of module. 4. Data Flow It represents the flow of data between the modules. It is represented by directed arrow with empty circle at the end. 5. Control Flow It represents the flow of control between the modules. It is represented by directed arrow with filled circle at the end. 6. Physical Storage Physical Storage is that where all the information are to be stored.
- 68. Example : Structurechart for an Email server Types of Structure Chart: 1. Transform Centered Structured: These type of structure chart are designed for the systems that receives an input which is transformed by a sequence of operations being carried out by one module. Transaction Centered Structure: These structure describes a system that processes a number of different types of transaction Compiled by: Ms.Savita Mittal Lecture 24 Definition of 'Pseudocode' Definition: Pseudocode is an informal way of programming description that does not require any strict programming language syntax or underlying technology considerations. It is used for
- 69. creating an outlineor a rough draft of a program. Pseudocode summarizes a program’s flow, but excludes underlying details. System designers write pseudocode to ensure that programmers understand a software project's requirements and align code accordingly. Description: Pseudocode is not an actual programming language. So it cannot be compiled into an executable program. It uses short terms or simple English language syntaxes to write code for programs before it is actually converted into a specific programming language. This is done to identify top level flow errors, and understand the programming data flows that the final program is going to use. This definitely helps save time during actual programming as conceptual errors have been already corrected. Firstly, program description and functionality is gathered and then pseudocode is used to create statements to achieve the required results for a program. Detailed pseudocode is inspected and verified by the designer’s team or programmers to match design specifications. Catching errors or wrong program flow at the pseudocode stage is beneficial for development as it is less costly than catching them later. Once the pseudocode is accepted by the team, it is rewritten using the vocabulary and syntax of a programming language. The purpose of using pseudocode is an efficient key principle of an algorithm. It is used in planning an algorithm with sketching out the structure of the program before the actual coding takes place. Advantages of pseudocode – • Pseudocode is understood by the programmers of all types. • it enables the programmer to concentrate only on the algorithm part of the code development. • It cannot be compiled into an executable program. Example, Java code : if (i < 10) { i++; } pseudocode :if i is less than 10, increment i by 1. Prototype Model Definition: The Prototyping Model is a Systems Development Methodology (SDM) within which a paradigm output (or an early approximation of a final system or product) is constructed, tested, and then reworked. It is done till an appropriate paradigm is achieved to help develop the entire system or product. This model works best in situations when all the details or requirements are not known well in advance. It is majorly a trial-and-error process which works in an iterative fashion. Description: There are many steps within the Prototyping Model: 1. New system requirements or expectations of the system output are outlined in as much detail as possible. This requires interviewing variety of users, representing all the segments or stakeholders of the prevailing system. 2. A preliminary layout specification is formed for the new system. 3. A first output model of the new system is made from the preliminary layouts. This is often a scaled-
- 70. down system whichtentatively gives an approximation of the desired output required. 4. The users check the primary output, noting its strengths and weaknesses, the things which need to be carried ahead in the next steps and the things which need to be discarded. The developer collects and examines the remarks from the all the stakeholders. 5. The first paradigm is changed, supported by the comments provided by the users, and is shaped to a second output of the new system. 6. The second output is evaluated in the same manner as was the primary output. 7. These steps are reiterated persistently, till the users are satisfied with the output. 8. The final system is hence constructed, supported by the ultimate output. The final system is completely evaluated and tested. Routine maintenance is administered on a seamless basis to forecast large- scale failures and to reduce the time period. Flow Chart Flow charts are easy-to-understand diagrams that show how the steps of a process fit together. American engineer Frank Gilbreth is widely believed to be the first person to document a process flow, having introduced the concept of a “Process Chart” to the American Society of Mechanical Engineers in 1921. Flow charts tend to consist of four main symbols, linked with arrows that show the direction of flow: 1. Elongated circles, which signify the start or end of a process. 2. Rectangles, which show instructions or actions. 3. Diamonds, which highlight where you must make a decision. 4. Parallelograms, which show input and output. This can include materials, services or people. Tip: You can use many other symbols in a flow chart but remember that these diagrams are used for communication . If you use symbols that only a few people understand, you may fail to get your message across. So, be sure to keep things simple ! When to Use a Flow Chart All manner of organizations use flow charts to: Define a process. Standardize a process. Communicate a process.
- 71. Identify bottlenecksor waste in a process. Solve a problem . Improve a process. For example, software developers can use them to work out how the automated and manual parts of a process join up. Inexperienced team members might follow a flow chart to help them to complete activities in the right order. A manufacturer could ensure that it keeps to its values by applying a quality-control flow chart that presents questions and decision points. And an HR department might combine a flow chart with an organogram to show people who to contact about issues and when. Why Use Flow Charts? This tool's simplicity makes communicating and documenting a process quick and clear, so that the process will more likely be understood and applied correctly and consistently. It can also help you to estimate the timescale of the process, as you're better able to gauge the time needed for each task along the way. And you'll more likely identify who you should involve and at what stage, such as senior management or a compliance authority. But you can also benefit from the process of creating a flow chart itself, as you build it step by step. You'll be able to focus on the detail of each individual stage, without feeling overwhelmed by the rest of the process, and then "zoom out" again to see the wider picture. Tip: If your process or project involves several people or teams, you might find it more useful to use a Swim Lane Diagram rather than a flow chart – this helps you to show process flows between people and teams. How to Create a Flow Chart Follow these four steps: Step 1: Identify Tasks Begin by listing all of the tasks in a process in chronological order. Ask questions such as, "What happens next in the process?" or, "Do you need to make a decision before the next step?" or, "What approvals are required before you move on to the next task?" Put yourself in the shoes of the person using the process, possibly for the first time. Talk to team members who work with the process directly, and get their opinions on where improvements could be made. Better yet, take a hands-on approach and go through the procedure yourself, and
- 72. think about thepracticalities of each stage. Use Customer Experience Mapping if your flow chart focuses on customer service, so that you can gain a better understanding of the process. Step 2: Organize and Document Tasks Next, start your flow chart by drawing the elongated circle shape and labeling it "Start." Then, work through your whole process, and show the actions and decisions in the order that they happen. Link them with arrows to illustrate the flow of the process. Where you need to make a decision, draw arrows from the decision diamond to each possible solution, and then label each arrow with the decision made. Remember to show the end of the process by using an elongated circle labeled "Finish." Step 3: Double-Check the Process When you've completed your flow chart, go back to the start and try it out to make sure that you haven't overlooked anything. Work through each step, and ask yourself whether you've represented the sequence of actions and the decisions involved correctly. Are there more decisions to be made at certain stages? Then show your flow chart to other people, especially those who work directly with the process. Ask them to test that it works and to tell you if there are any problems or omissions. Step 4: Challenge the Flow Chart Finally, you might want to improve the process rather than just record it. So, see whether any of the steps that you've described are unnecessary or overly complicated. Identify any major bottlenecks , and deal with them to improve performance. Compiled By: Ms. Savita Mittal Lecture 25 Topic: Coupling and Cohesion Coupling and Cohesion
- 73. Introduction: The purposeof Design phase in the Software Development Life Cycle is to produce a solution to a problem given in the SRS(Software Requirement Specification) document. The output of the design phase is Sofware Design Document (SDD). Basically, design is a two-part iterative process. First part is Conceptual Design that tells the customer what the system will do. Second is Technical Design that allows the system builders to understand the actual hardware and software needed to solve customer’s problem. Conceptual design of system: Written in simple language i.e. customer understandable language. Detail explanation about system characteristics. Describes the functionality of the system. It is independent of implementation. Linked with requirement document. Technical Design of system: Hardware component and design. Functionality and hierarchy of software component. Software architecture Network architecture Data structure and flow of data. I/O component of the system. Shows interface. Modularization: Modularization is the process of dividing a software system into multiple independent modules where each module works independently. There are many advantages of Modularization in software engineering. Some of these are given below: Easy to understand the system.
- 74. System maintenanceis easy. A module can be used many times as their requirements. No need to write it again and again. Coupling: Coupling is the measure of the degree of interdependence between the modules. A good software will have low coupling. Types of Coupling: Data Coupling: If the dependency between the modules is based on the fact that they communicate by passing only data, then the modules are said to be data coupled. In data coupling, the components are independent to each other and communicating through data. Module communications don’t contain tramp data. Example-customer billing system. Stamp Coupling In stamp coupling, the complete data structure is passed from one module to another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors- this choice made by the insightful designer, not a lazy programmer. Control Coupling: If the modules communicate by passing control information, then they are said to be control coupled. It can be bad if parameters indicate completely different behavior and good if parameters allow factoring and reuse of functionality. Example- sort function that takes comparison function as an argument. External Coupling: In external coupling, the modules depend on other modules, external to the software being developed or to a particular type of hardware. Ex- protocol, external file, device format, etc. Common Coupling: The modules have shared data such as global data structures.The changes in global data mean tracing back to all modules which access that data to evaluate the effect of the change. So it has got disadvantages like difficulty in reusing modules, reduced ability to control data accesses and reduced maintainability. Content Coupling: In a content coupling, one module can modify the data of another module or control flow is passed from one module to the other module. This is the worst form of coupling and should be avoided. Cohesion: Cohesion is a measure of the degree to which the elements of the module are functionally related. It is the degree to which all elements directed towards performing a single task are contained in the
- 75. component. Basically, cohesionis the internal glue that keeps the module together. A good software design will have high cohesion. Types of Cohesion: Functional Cohesion: Every essential element for a single computation is contained in the component. A functional cohesion performs the task and functions. It is an ideal situation. Sequential Cohesion: An element outputs some data that becomes the input for other element, i.e., data flow between the parts. It occurs naturally in functional programming languages. Communicational Cohesion: Two elements operate on the same input data or contribute towards the same output data. Example- update record int the database and send it to the printer. Procedural Cohesion: Elements of procedural cohesion ensure the order of execution. Actions are still weakly connected and unlikely to be reusable. Ex- calculate student GPA, print student record, calculate cumulative GPA, print cumulative GPA. Temporal Cohesion: The elements are related by their timing involved. A module connected with temporal cohesion all the tasks must be executed in the same time-span. This cohesion contains the code for initializing all the parts of the system. Lots of different activities occur, all at init time. Logical Cohesion: The elements are logically related and not functionally. Ex- A component reads inputs from tape, disk, and network. All the code for these functions is in the same component. Operations are related, but the functions are significantly different. Coincidental Cohesion: The elements are not related(unrelated). The elements have no conceptual relationship other than location in source code. It is accidental and the worst form of cohesion. Ex- print next line and reverse the characters of a string in a single component.
- 76. Software Engineering(MCA 512) MCAV Sem Unit-III: Software Design Lecture 26 Topic: Function Oriented Design Function Oriented Design The design process for software systems often has two levels. At the first level the focus is on deciding which modules are needed for the system on the basis of SRS (Software Requirement Specification) and how the modules should be interconnected. Function Oriented Design is an approach to software design where the design is decomposed into a set of interacting units where each unit has a clearly defined function. Generic Procedure: Start with a high level description of what the software / program does. Refine each part of the description one by one by specifying in greater details the functionality of each part. These points lead to Top-Down Structure. Problem in Top-Down design method: Mostly each module is used by at most one other module and that module is called its Parent module.
- 77. Solution to theproblem: Designing of reusable module. It means modules use several modules to do their required functions. Function Oriented Design Strategies: Function Oriented Design Strategies are as follows: 1. Data Flow Diagram (DFD): A data flow diagram (DFD) maps out the flow of information for any process or system. It uses defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs, outputs, storage points and the routes between each destination. 2. Data Dictionaries: Data dictionaries are simply repositories to store information about all data items defined in DFDs. At the requirement stage, data dictionaries contains data items. Data dictionaries include Name of the item, Aliases (Other names for items), Description / purpose, Related data items, Range of values, Data structure definition / form. 3. Structure Charts: It is the hierarchical representation of system which partitions the system into black boxes (functionality is known to users but inner details are unknown). Components are read from top to bottom and left to right. When a module calls another, it views the called module as black box, passing required parameters and receiving results. Pseudo Code: Pseudo Code is system description in short English like phrases describing the function. It use keyword and indentation. Pseudo codes are used as replacement for flow charts. It decreases the amount of documentation required. Compiled By: Savita Mittal Lecture 27
- 78. Object oriented designstarted right from the moment computers were invented. Programming was there, and programming approaches came into the picture. Programming is basically giving certain instructions to the computer. At the beginning of the computing era, programming was usually limited to machine language programming. Machine language means those sets of instructions that are specific to a particular machine or processor, which are in the form of 0’s and 1’s. These are sequences of bits (0100110…). But it’s quite difficult to write a program or develop software in machine language. It’s actually impossible to develop software used in today’s scenarios with sequences of bits. This was the main reason programmers moved on to the next generation of programming languages, developing assembly languages, which were near enough to the English language to easily understand. These assembly languages were used in microprocessors. With the invention of the microprocessor, assembly languages flourished and ruled over the industry, but it was not enough. Again, programmers came up with something new, i.e., structured and procedural programming. Structured Programming – The basic principle of the structured programming approach is to divide a program into functions and modules. The use of modules and functions makes the program more understandable and readable. It helps to write cleaner code and to maintain control over the functions and modules. This approach gives importance to functions rather than data. It focuses on the development of large software applications, for example, C was used for modern operating system development. The programming languages: PASCAL (introduced by Niklaus Wirth) and C (introduced by Dennis Ritchie) follow this approach.
- 79. Procedural Programming Approach– This approach is also known as the top-down approach. In this approach, a program is divided into functions that perform specific tasks. This approach is mainly used for medium-sized applications. Data is global, and all the functions can access global data. The basic drawback of the procedural programming approach is that data is not secured because data is global and can be accessed by any function. Program control flow is achieved through function calls and goto statements. The programming languages: FORTRAN (developed by IBM) and COBOL (developed by Dr Grace Murray Hopper) follow this approach. These programming constructs were developed in the late 1970s and 1980s. There were still some issues with these languages, though they fulfilled the criteria of well-structured programs, software etc. They were not as structured as the requirements were at that time. They seem to be over-generalised and don’t correlate with real-time applications. To solve such kinds of problems, OOP, an object-oriented approach was developed as a solution. The Object-Oriented Programming (OOP) Approach – The OOP concept was basically designed to overcome the drawback of the above programming methodologies, which were not so close to real-world applications. The demand was increased, but still, conventional methods were used. This new approach brought a revolution in the programming methodology field. Object-oriented programming (OOP) is nothing but that which allows the writing of programs with the help of certain classes and real-time objects. We can say that this approach is very close to the real-world and its applications because the state and behaviour of these classes and objects are almost the same as real-world objects.
- 80. Let’s go deeperinto the general concepts of OOP, which are given below: What Are Class & Object? It is the basic concept of OOP; an extended concept of the structure used in C. It is an abstract and user- defined data type. It consists of several variables and functions. The primary purpose of the class is to store data and information. The members of a class define the behaviour of the class. A class is the blueprint of the object, but also, we can say the implementation of the class is the object. The class is not visible to the world, but the object is. filter_none brightness_4 Class car { int car_id; char colour[4]; float engine_no; double distance; void distance_travelled(); float petrol_used();
- 81. char music_player(); void display(); } Here,the class car has properties car_id, colour, engine_no and distance. It resembles the real-world car that has the same specifications, which can be declared public (visible to everyone outside the class), protected and private (visible to none). Also, there are some methods such as distance_travelled(), petrol_used(), music_player() and display(). In the code given below, the car is a class and c1 is an object of the car. Compiled By: Ms. Savita Mittal Lecture : 28 Bottom-Up Model and Top-Down Model Top-Down Design Model: In the top-down model, an overview of the system is formulated without going into detail for any part of it. Each part of it then refined into more details, defining it in yet more details until the entire specification is detailed enough to validate the model. if we glance at a haul as a full, it’s going to appear not possible as a result of it’s so complicated For example: Writing a University system program, writing a word processor. Complicated issues may be resolved victimization high down style, conjointly referred to as Stepwise refinement where, 1. We break the problem into parts, 2. Then break the parts into parts soon and now each of parts will be easy to do. Advantages: Breaking problems into parts help us to identify what needs to be done. At each step of refinement, new parts will become less complex and therefore easier to solve. Parts of the solution may turn out to be reusable. Breaking problems into parts allows more than one person to solve the problem. Bottom-Up Design Model: In this design, individual parts of the system are specified in detail. The parts are linked to form larger components, which are in turn linked until a complete system is formed. Object-oriented language such as C++ or java uses a bottom-up approach where each object is identified first.
- 82. Advantage: Make decisionsabout reusable low-level utilities then decide how there will be put together to create high-level construct. , The contrast between Top-down design and bottom-up design. S.NO. TOP DOWN APPROACH BOTTOM UP APPROACH 1. In this approach We focus on breaking up the problem into smaller parts. In bottom up approach, we solve smaller problems and integrate it as whole and complete the solution. 2. Mainly used by structured programming language such as COBOL, Fortran, C, etc. Mainly used by object oriented programming language such as C++, C#, Python. 3. Each part is programmed separately therefore contain redundancy. Redundancy is minimized by using data encapsulation and data hiding. 4. In this the communications is less among modules. In this module must have communication. 5. It is used in debugging, module documentation, etc. It is basically used in testing.
- 83. S.NO. TOP DOWN APPROACH BOTTOMUP APPROACH 6. In top down approach, decomposition takes place. In bottom up approach composition takes place. 7. In this top function of system might be hard to identify. In this sometimes we can not build a program from the piece we have started. 8. In this implementation details may differ. This is not natural for people to assemble. Software Measurement and Metrics Software Measurement: A measurement is an manifestation of the size, quantity, amount or dimension of a particular attributes of a product or process. Software measurement is a titrate impute of a characteristic of a software product or the software process. It is an authority within software engineering. Software measurement process is defined and governed by ISO Standard. Need of Software Measurement: Software is measured to: 1. Create the quality of the current product or process. 2. Anticipate future qualities of the product or process. 3. Enhance the quality of a product or process. 4. Regulate the state of the project in relation to budget and schedule. Classification of Software Measurement: There are 2 types of software measurement: 1. Direct Measurement: In direct measurement the product, process or thing is measured directly using standard scale.
- 84. 2. Indirect Measurement: Inindirect measurement the quantity or quality to be measured is measured using related parameter i.e. by use of reference. Metrics: A metrics is a measurement of the level that any impute belongs to a system product or process. There are 4 functions related to software metrics: 1. Planning 2. Organizing 3. Controlling 4. Improving Characteristics of software Metrics: 1. Quantitative: Metrics must possess quantitative nature.It means metrics can be expressed in values. 2. Understandable: Metric computation should be easily understood ,the method of computing metric should be clearly defined. 3. Applicability: Metrics should be applicable in the initial phases of development of the software. 4. Repeatable: The metric values should be same when measured repeatedly and consistent in nature. 5. Economical: Computation of metric should be economical. 6. Language Independent: Metrics should not depend on any programming language. Classification of Software Metrics: There are 2 types of software metrics: 1. Product Metrics: Product metrics are used to evaluate the state of the product, tracing risks and undercovering prospective problem areas. The ability of team to control quality is evaluated. 2. Process Metrics: Process metrics pay particular attention on enhancing the long term process of the team or organisation. 3. Project Metrics: Project matrix is describes the project characteristic and execution process. Number of software developer Staffing pattern over the life cycle of software Cost and schedule Productivity Compiled By:
- 85. Ms. Savita Mittal SoftwareEngineering(MCA 512) MCA V Sem Unit-III: Software Design Lecture 29 Topic: Halstead’s Software Metrics Halstead’s Software Metrics A computer program is an implementation of an algorithm considered to be a collection of tokens which can be classified as either operators or operands. Halstead’s metrics are included in a number of current commercial tools that count software lines of code. By counting the tokens and determining which are operators and which are operands, the following base measures can be collected : n1 = Number of distinct operators. n2 = Number of distinct operands. N1 = Total number of occurrences of operators. N2 = Total number of occurrences of operands. In addition to the above, Halstead defines the following : n1* = Number of potential operators. n2* = Number of potential operands. Halstead refers to n1* and n2* as the minimum possible number of operators and operands for a module and a program respectively. This minimum number would be embodied in the programming language itself, in which the required operation would already exist (for example, in C language, any program must contain at least the definition of the function main()), possibly as a function or as a procedure: n1* = 2, since at least 2 operators must appear for any function or procedure : 1 for the name of the function and 1 to serve as an assignment or grouping symbol, and n2* represents the number of parameters, without repetition, which would need to be passed on to the function or the procedure. Halstead metrics –
- 86. Halstead metrics are: Halstead Program Length – The total number of operator occurrences and the total number of operand occurrences. N = N1 + N2 And estimated program length is, N^ = n1log2n1 + n2log2n2 The following alternate expressions have been published to estimate program length: NJ = log2(n1!) + log2(n2!) NB = n1 * log2n2 + n2 * log2n1 NC = n1 * sqrt(n1) + n2 * sqrt(n2) NS = (n * log2n) / 2 Halstead Vocabulary – The total number of unique operator and unique operand occurrences. n = n1 + n2 Program Volume – Proportional to program size, represents the size, in bits, of space necessary for storing the program. This parameter is dependent on specific algorithm implementation. The properties V, N, and the number of lines in the code are shown to be linearly connected and equally valid for measuring relative program size. V = Size * (log2 vocabulary) = N * log2(n) The unit of measurement of volume is the common unit for size “bits”. It is the actual size of a program if a uniform binary encoding for the vocabulary is used. And error = Volume / 3000 Potential Minimum Volume – The potential minimum volume V* is defined as the volume of the most succinct program in which a problem can be coded. V* = (2 + n2*) * log2(2 + n2*) Here, n2* is the count of unique input and output parameters Program Level – To rank the programming languages, the level of abstraction provided by the programming language, Program Level (L) is considered. The higher the level of a language, the less effort it takes to develop a program using that language. L = V* / V The value of L ranges between zero and one, with L=1 representing a program written at the highest possible level (i.e., with minimum size). And estimated program level is L^ =2 * (n2) / (n1)(N2) Program Difficulty – This parameter shows how difficult to handle the program is. D = (n1 / 2) * (N2 / n2) D = 1 / L
- 87. As the volumeof the implementation of a program increases, the program level decreases and the difficulty increases. Thus, programming practices such as redundant usage of operands, or the failure to use higher-level control constructs will tend to increase the volume as well as the difficulty. Programming Effort – Measures the amount of mental activity needed to translate the existing algorithm into implementation in the specified program language. E = V / L = D * V = Difficulty * Volume Language Level – Shows the algorithm implementation program language level. The same algorithm demands additional effort if it is written in a low-level program language. For example, it is easier to program in Pascal than in Assembler. L’ = V / D / D lambda = L * V* = L2 * V Intelligence Content – Determines the amount of intelligence presented (stated) in the program This parameter provides a measurement of program complexity, independently of the program language in which it was implemented. I = V / D Programming Time – Shows time (in minutes) needed to translate the existing algorithm into implementation in the specified program language. T = E / (f * S) The concept of the processing rate of the human brain, developed by the psychologist John Stroud, is also used. Stoud defined a moment as the time required by the human brain requires to carry out the most elementary decision. The Stoud number S is therefore Stoud’s moments per second with: 5 <= S <= 20. Halstead uses 18. The value of S has been empirically developed from psychological reasoning, and its recommended value for programming applications is 18. Stroud number S = 18 moments / second seconds-to-minutes factor f = 60 Counting rules for C language – 1. Comments are not considered. 2. The identifier and function declarations are not considered 3. All the variables and constants are considered operands. 4. Global variables used in different modules of the same program are counted as multiple occurrences of the same variable. 5. Local variables with the same name in different functions are counted as unique operands.
- 88. 6. Functions callsare considered as operators. 7. All looping statements e.g., do {…} while ( ), while ( ) {…}, for ( ) {…}, all control statements e.g., if ( ) {…}, if ( ) {…} else {…}, etc. are considered as operators. 8. In control construct switch ( ) {case:…}, switch as well as all the case statements are considered as operators. 9. The reserve words like return, default, continue, break, sizeof, etc., are considered as operators. 10. All the brackets, commas, and terminators are considered as operators. 11. GOTO is counted as an operator and the label is counted as an operand. 12. The unary and binary occurrence of “+” and “-” are dealt separately. Similarly “*” (multiplication operator) are dealt separately. 13. In the array variables such as “array-name [index]” “array-name” and “index” are considered as operands and [ ] is considered as operator. 14. In the structure variables such as “struct-name, member-name” or “struct-name -> member- name”, struct-name, member-name are taken as operands and ‘.’, ‘->’ are taken as operators. Some names of member elements in different structure variables are counted as unique operands. 15. All the hash directive are ignored. Example – List out the operators and operands and also calculate the values of software science measures like int sort (int x[ ], int n) { int i, j, save, im1; /*This function sorts array x in ascending order */ If (n< 2) return 1; for (i=2; i< =n; i++) { im1=i-1; for (j=1; j< =im1; j++) if (x[i] < x[j]) { Save = x[i]; x[i] = x[j];
- 89. x[j] = save; } } return0; } Explanation – operators occurrences operands occurrences int 4 sort 1 () 5 x 7 , 4 n 3 [] 7 i 8 if 2 j 7 < 2 save 3 ; 11 im1 3
- 90. for 2 22 = 6 1 3 – 1 0 1 <= 2 – – ++ 2 – – return 2 – – {} 3 – – n1=14 N1=53 n2=10 N2=38 Therefore, N = 91 n = 24 V = 417.23 bits N^ = 86.51 n2* = 3 (x:array holding integer to be sorted. This is used both
- 91. as input andoutput) V* = 11.6 L = 0.027 D = 37.03 L^ = 0.038 T = 610 seconds Advantages of Halstead Metrics: It is simple to calculate. It measures overall quality of the programs. It predicts the rate of error. It predicts maintenance effort. It does not require the full analysis of programming structure. It is useful in scheduling and reporting projects. It can be used for any programming language. Disadvantages of Halstead Metrics: It depends on the complete code. It has no use as a predictive estimating model. Reference – Halstead complexity measures – Wikipedia ristancase Lecture 30(End Of Unit 3) Function Point (FP) is a unit of measurement to express the amount of business functionality, an information system (as a product) provides to a user. FPs measure software size. They are widely accepted as an industry standard for functional sizing. For sizing software based on FP, several recognized standards and/or public specifications have come into existence. As of 2013, these are −
- 92. ISO Standards COSMIC− ISO/IEC 19761:2011 Software engineering. A functional size measurement method. FiSMA − ISO/IEC 29881:2008 Information technology - Software and systems engineering - FiSMA 1.1 functional size measurement method. IFPUG − ISO/IEC 20926:2009 Software and systems engineering - Software measurement - IFPUG functional size measurement method. Mark-II − ISO/IEC 20968:2002 Software engineering - Ml II Function Point Analysis - Counting Practices Manual. NESMA − ISO/IEC 24570:2005 Software engineering - NESMA function size measurement method version 2.1 - Definitions and counting guidelines for the application of Function Point Analysis. Object Management Group Specification for Automated Function Point Object Management Group (OMG), an open membership and not-for-profit computer industry standards consortium, has adopted the Automated Function Point (AFP) specification led by the Consortium for IT Software Quality. It provides a standard for automating FP counting according to the guidelines of the International Function Point User Group (IFPUG). Function Point Analysis (FPA) technique quantifies the functions contained within software in terms that are meaningful to the software users. FPs consider the number of functions being developed based on the requirements specification. Function Points (FP) Counting is governed by a standard set of rules, processes and guidelines as defined by the International Function Point Users Group (IFPUG). These are published in Counting Practices Manual (CPM). History of Function Point Analysis The concept of Function Points was introduced by Alan Albrecht of IBM in 1979. In 1984, Albrecht refined the method. The first Function Point Guidelines were published in 1984. The International Function Point Users Group (IFPUG) is a US-based worldwide organization of Function Point Analysis metric software users. The International Function Point Users Group (IFPUG) is a non-profit, member-governed organization founded in 1986. IFPUG owns Function Point Analysis (FPA) as defined in ISO standard 20296:2009 which specifies the definitions, rules and steps for applying the IFPUG's functional size measurement (FSM) method. IFPUG maintains the Function Point Counting Practices Manual (CPM). CPM 2.0 was released in 1987, and since then there have been several iterations. CPM Release 4.3 was in 2010.
- 93. The CPM Release4.3.1 with incorporated ISO editorial revisions was in 2010. The ISO Standard (IFPUG FSM) - Functional Size Measurement that is a part of CPM 4.3.1 is a technique for measuring software in terms of the functionality it delivers. The CPM is an internationally approved standard under ISO/IEC 14143-1 Information Technology – Software Measurement. Elementary Process (EP) Elementary Process is the smallest unit of functional user requirement that − Is meaningful to the user. Constitutes a complete transaction. Is self-contained and leaves the business of the application being counted in a consistent state. Functions There are two types of functions − Data Functions Transaction Functions Data Functions There are two types of data functions − Internal Logical Files External Interface Files Data Functions are made up of internal and external resources that affect the system. Internal Logical Files Internal Logical File (ILF) is a user identifiable group of logically related data or control information that resides entirely within the application boundary. The primary intent of an ILF is to hold data maintained through one or more elementary processes of the application being counted. An ILF has the inherent meaning that it is internally maintained, it has some logical structure and it is stored in a file. (Refer Figure 1) External Interface Files External Interface File (EIF) is a user identifiable group of logically related data or control information that is used by the application for reference purposes only. The data resides entirely outside the application boundary and is maintained in an ILF by another application. An EIF has the inherent meaning that it is externally maintained, an interface has to be developed to get the data from the file. (Refer Figure 1)
- 94. Transaction Functions There arethree types of transaction functions. External Inputs External Outputs External Inquiries Transaction functions are made up of the processes that are exchanged between the user, the external applications and the application being measured. External Inputs External Input (EI) is a transaction function in which Data goes “into” the application from outside the boundary to inside. This data is coming external to the application. Data may come from a data input screen or another application. An EI is how an application gets information. Data can be either control information or business information. Data may be used to maintain one or more Internal Logical Files. If the data is control information, it does not have to update an Internal Logical File. (Refer Figure 1) External Outputs
- 95. External Output (EO)is a transaction function in which data comes “out” of the system. Additionally, an EO may update an ILF. The data creates reports or output files sent to other applications. (Refer Figure 1) External Inquiries External Inquiry (EQ) is a transaction function with both input and output components that result in data retrieval. (Refer Figure 1) Lecture 29 Cyclomatic Complexity Cyclomatic complexity of a code section is the quantitative measure of the number of linearly independent paths in it. It is a software metric used to indicate the complexity of a program. It is computed using the Control Flow Graph of the program. The nodes in the graph indicate the smallest group of commands of a program, and a directed edge in it connects the two nodes i.e. if second command might immediately follow the first command. For example, if source code contains no control flow statement then its cyclomatic complexity will be 1 and source code contains a single path in it. Similarly, if the source code contains one if condition then cyclomatic complexity will be 2 because there will be two paths one for true and the other for false. Mathematically, for a structured program, the directed graph inside control flow is the edge joining two basic blocks of the program as control may pass from first to second. So, cyclomatic complexity M would be defined as, M = E – N + 2P where, E = the number of edges in the control flow graph N = the number of nodes in the control flow graph P = the number of connected components Steps that should be followed in calculating cyclomatic complexity and test cases design are: Construction of graph with nodes and edges from code. Identification of independent paths. Cyclomatic Complexity Calculation Design of Test Cases Let a section of code as such:
- 96. A = 10 IFB > C THEN A = B ELSE A = C ENDIF Print A Print B Print C Control Flow Graph of above code
- 97. The cyclomatic complexitycalculated for above code will be from control flow graph. The graph shows seven shapes(nodes), seven lines(edges), hence cyclomatic complexity is 7-7+2 = 2. Use of Cyclomatic Complexity: Determining the independent path executions thus proven to be very helpful for Developers and Testers. It can make sure that every path have been tested at least once. Thus help to focus more on uncovered paths. Code coverage can be improved. Risk associated with program can be evaluated. These metrics being used earlier in the program helps in reducing the risks. Advantages of Cyclomatic Complexity:.
- 98. It canbe used as a quality metric, gives relative complexity of various designs. It is able to compute faster than the Halstead’s metrics. It is used to measure the minimum effort and best areas of concentration for testing. It is able to guide the testing process. It is easy to apply. Disadvantages of Cyclomatic Complexity: It is the measure of the programs’s control complexity and not the data the data complexity. In this, nested conditional structures are harder to understand than non-nested structures. In case of simple comparisons and decision strucures, it may give a misleading figure. Reference: https://en.wikipedia.org/wiki/Cyclomatic_complexity