Software Engineering Development Activities

1. Planning and Requirements Gathering: Identify and document user needs and system
requirements.
2. Design: Architectural design outlines the overall system structure; detailed design focuses on
specific components.
3. Implementation: Writing code in a programming language; developing software functionalities.
4. Testing: Systematic identification and fixing of defects; ensuring software meets requirements.
5. Deployment: Distributing the software to users; includes installation and configuration.
6. Maintenance: Ongoing support; includes bug fixing, updates, and possible enhancements.

Techniques of Managing Software Development

Effective management of software development is pivotal for the timely delivery of high-quality
software products.
1. Agile Methodology: A flexible approach focusing on customer satisfaction and iterative
development. Agile methods promote adaptive planning, evolutionary development, early
delivery, and continuous improvement, encouraging rapid and flexible response to change.
2. Waterfall Model: A traditional sequential approach where the project is divided into distinct
phases. Each phase must be completed before the next begins. It’s suitable for projects with
well-defined requirements and low uncertainty.
3. Scrum: A subset of Agile focusing on completing work in fixed-length iterations known as
sprints, usually 2-4 weeks long. Scrum teams are cross-functional and self-organizing. Key roles
include the Scrum Master, Product Owner, and the development team.
4. Kanban: A visual approach to managing work using boards and cards. It emphasizes just-in-
time delivery without overloading the team members, focusing on delivering continuous
improvement, flexibility, and flow of work.
Object-Oriented Design
Object-Oriented Design (OOD) is a programming approach that uses objects as the fundamental
building blocks of software. In OOD, an object is an instance of a class that encapsulates data and
behavior related to that data. It emphasises-
1. Modularity: Dividing the system into separate modules or classes, each encapsulating a specific
functionality. This enhances maintainability and reusability.
2. Encapsulation: Combining data and methods that operate on the data into a single unit, or class.
It hides the internal state of the object from the outside world.
3. Polymorphism: Allows objects to be treated as instances of their parent class. It enables one
interface to be used for a general class of actions, making the software more flexible.
4. Inheritance: Enables new classes to inherit properties and methods from existing classes. This
promotes code reuse and can help to reduce redundancy in code.
Rumbaugh OMT Model
The Rumbaugh OMT (Object Modeling Technique) model, developed by James Rumbaugh, is a
methodology for object-oriented software development. It emphasizes comprehensive modeling to
understand and design complex systems.
1. Object Model: Describes the structure of objects within the system, including their attributes,
operations, and the relationships between them. It provides a static view of the system.
2. Dynamic Model: Focuses on system behavior over time. It describes how objects interact and
change state, capturing the temporal aspects of the system.
3. Functional Model: Details the processes and operations within the system. It shows how data
values are transformed within the system, mapping operations to objects.

Booch Methodology- is a well-regarded approach in object-oriented software development. It offers a

comprehensive set of engineering practices for software development, focusing on the use of object-
oriented concepts and notation. The methodology is characterized by its graphical notation system,
which is used to represent different views of the system. It covers six diagrams: class diagrams, object
diagrams, state transition diagrams, module diagrams, process diagrams, and interaction diagrams.
Each diagram serves to visualize various aspects of the software, from the structure of classes and
objects to their interactions and internal states. The Booch Methodology supports iterative and
incremental development, encouraging refinement and evolution of the design over time.

Class Diagram
Class diagram is a static diagram. It represents the static view of an application. Class diagram is not
only used for visualizing, describing, and documenting different aspects of a system but also for
constructing executable code of the software application
Public, private and protected in class diagram
The visibility of the attributes and operations can be represented in the following ways −
Public − A public member is visible from anywhere in the system. In class diagram, it is prefixed by the
symbol ‘+’.
Private − A private member is visible only from within the class. It cannot be accessed from outside
the class. A private member is prefixed by the symbol ‘−’.
Protected − A protected member is visible from within the class and from the subclasses inherited
from this class, but not from outside. It is prefixed by the symbol ‘#’.
Association class
In UML diagrams, an association class is a class that is part of an association relationship between two
other classes An association class is identical to other classes and can contain operations, attributes,
as well as other associations. For example, a class called Student represents a student and has an
association with a class called Course, which represents an educational course. The Student class can
enroll in a course. An association class called Enrollment further defines the relationship between the
Student and Course classes

UML Abstract Class

In UML class diagrams, an abstract class is a class that cannot be instantiated and is typically used as a
base class for other classes that will provide the implementation. It is represented by a class with the
keyword “abstract” before the name and its methods are usually represented as italicized and
underlined.

UML Interface
An interface is a collection of abstract methods that a class must implement. An interface defines a
contract for the behavior of a class, but does not provide an implementation. In UML, interfaces are
represented by a rectangle with the keyword “interface” before the name, and its methods are
usually represented as italicized and underlined.

Does UML explain Conceptual Modelling?

Yes, UML (Unified Modeling Language) is used for conceptual modeling in software development and
systems engineering. It helps in visualizing the design of a system at a high level, focusing on
structures and relationships rather than implementation details. Key UML diagrams for conceptual
modeling include:
1. Class Diagrams: Show classes, attributes, operations, and relationships.
2. Use Case Diagrams: Describe system functionality from the user's perspective.
3. Activity Diagrams: Illustrate the flow of activities and processes.
 4. Package Diagrams: These are used to group elements of a system into related groups, which is
helpful in conceptualizing the overall structure of a system.
5. Object Diagrams: They are akin to class diagrams but represent specific instances of classes
and their relationships at a particular moment in time.
6. Sequence Diagrams: They are more dynamic and focus on object interactions over time, useful
for conceptualizing the sequence of operations in a system.
These diagrams facilitate a shared understanding among stakeholders of what the system is intended
to do and how it's structured, without delving into coding specifics.
Association Aggregation Composition

Association relationship is Aggregation relationship is The composition relationship is

represented using an arrow. represented by a straight line with an represented by a straight line with
empty diamond at one end. a black diamond at one end.

In UML, it can exist between It is a part of the association It is a part of the aggregation
two or more classes. relationship. relationship.

It incorporates one-to-one, one- It exhibits a kind of weak relationship. It exhibits a strong type of
to-many, many-to-one, and relationship.
many-to-many association
between the classes.

It can associate one more objects In an aggregation relationship, the In a composition relationship, the
together. associated objects exist independently associated objects cannot exist
within the scope of the system. independently within the scope of
the system.

In this, objects are linked In this, the linked objects are Here the linked objects are
together. independent of each other. dependent on each other.

It may or may not affect the Deleting one element in the It affects the other element if one
other associated element if one aggregation relationship does not of its associated element is
element is deleted. affect other associated elements. deleted.

Example: A tutor can associate Example: A car needs a wheel for its Example: If a file is placed in a
with multiple students, or one proper functioning, but it may not folder and that is folder is
student can associate with require the same wheel. It may deleted. The file residing inside
multiple teachers. function with another wheel as well. that folder will also get deleted at
the time of folder deletion.

UML ARCHITECTURE
1. Use case view: -
It describes the use case that shows the behavior of the system as seen by its end users, analysts and
testers. The static aspect of this view is shown in use case diagram.
2. Design view: - It consists of classes, interfaces and collaborations required for the system. It
supports the functional requirements of the system. It specifies services that the system provides to
its end user. The static aspect is shown in class diagram and object diagram.
3. Process view:-
It focuses on threads and processes that form the system‟s concurrency and synchronization
mechanism. It addresses the performance, scalability and throughput of the system. Static aspect is
shown in class and object diagram.
4. Implementation view:-
It focuses on the components and files that are used to assemble and release the physical system. It
addresses configuration management of the system‟s releases. The static aspect of this view is shown
in component diagram.

UML BUILDING BLOCK- The building blocks of UML can be defined as −

 Things
 Relationships
 Diagrams
Things
Things are the most important building blocks of UML. Things can be −
 Structural
 Behavioral
 Grouping
 Annotational
Structural Things
Structural things define the static part of the model. They represent the physical and conceptual
elements. Following are the brief descriptions of the structural things.
Class − Class represents a set of objects having similar responsibilities.

Interface − Interface defines a set of operations, which specify the responsibility of a class.

Collaboration −Collaboration defines an interaction between elements.

Use case −Use case represents a set of actions performed by a system for a specific goal.

Component −Component describes the physical part of a system.

Node − A node can be defined as a physical element that exists at run time.
Behavioral Things
A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things
−
Interaction − Interaction is defined as a behavior that consists of a group of messages exchanged
among elements to accomplish a specific task.

State machine − State machine is useful when the state of an object in its life cycle is important. It
defines the sequence of states an object goes through in response to events. Events are external
factors responsible for state change

Grouping Things
Grouping things can be defined as a mechanism to group elements of a UML model together. There
is only one grouping thing available −
Package − Package is the only one grouping thing available for gathering structural and behavioral
things.

Annotational Things
Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments
of UML model elements. Note - It is the only one Annotational thing available. A note is used to
render comments, constraints, etc. of an UML element.

Relationship
Relationship is another most important building block of UML. It shows how the elements are
associated with each other and this association describes the functionality of an application.
There are four kinds of relationships available.
Dependency
Dependency is a relationship between two things in which change in one element also affects the
other.

Association
Association is basically a set of links that connects the elements of a UML model. It also describes
how many objects are taking part in that relationship.

Generalization
Generalization can be defined as a relationship which connects a specialized element with a
generalized element. It basically describes the inheritance relationship in the world of objects.

Realization
Realization can be defined as a relationship in which two elements are connected. One element
describes some responsibility, which is not implemented and the other one implements them. This
relationship exists in case of interfaces.

UML Diagrams
UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are
used to make a complete UML diagram and the diagram represents a system.
The visual effect of the UML diagram is the most important part of the entire process. All the other
elements are used to make it complete.
 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Activity diagram
 Statechart diagram
 Deployment diagram
 Component diagram

DEPENDENCY TYPES IN UML-

Type of dependency relationships, keywords, or stereotypes given below:
<<derive>> -It is a constraint that specifies the template can be initialized by the source at the target
location utilizing given parameters.
<<derive>> -It represents that the source object's location can be evaluated from the target object.
<<friend>> -It states the uniqueness of the source in the target object.
<<instanceOf>> -It states that an instance of a target classifier is the source object.
<<instantiate>> -It defines the capability of the source object, creating instances of a target object.
<<refine>> -It states that the source object comprises of exceptional abstraction than that of the
target object.
<<use>> -When the packages are created in UML, the use of stereotype is used as it describes that
the elements of the source package can also exist in the target package. It specifies that the source
package uses some of the elements of the target package.
<<substitute>> -The substitute stereotype state that the client can be substituted at the runtime for
the supplier.
<<access>> -It is also called as private merging in which the source package accesses the element of
the target package.
<<import>> -It specifies that target imports the source package's element as they are defined within
the target. It is also known as public merging.
<<permit>> -It describes that the source element can access the supplier element or whatever
visibility is provided by the supplier.
<<extend>> -It states that the behavior of the source element can be extended by the target.
 <<include>> -It describes the source element, which can include the behavior of another element at a
specific location, just like a function call in C/C++.
<<become>> -It states that target is similar to the source with distinct roles and values.
<<call>> -It specifies that the target object can be invoked by the source.
<<copy>> -It states that the target is an independent replica of a source object.
<<parameter>> -It describes that the supplier is a parameter of the client's actions.
<<send>> -The client act as an operation, which sends some unspecified targets to the supplier.

PURPOSE OF COMPONENT DIAGRAM- The main purpose of the component diagram are enlisted
below:
 It envisions each component of a system.
 It constructs the executable by incorporating forward and reverse engineering.
 It depicts the relationships and organization of components.

Aspect Use Case Diagram Sequence Diagram

Illustrates interaction between system
Purpose Shows system's functional requirements. parts.
Content Actors, use cases, relationships. Objects, classes, message sequences.
What the system does (user-system How the system does it (internal
Focus interaction). processes).
Visualization High-level, simplified overview. Detailed, temporal flow of interactions.
Scope Broad, external view of functionality. Detailed, specific action sequences.
Abstraction
Level High (external system behavior). Low (detailed internal functioning).
Audience Stakeholders, analysts (for requirements). Developers (for system design).

Components of Collaboration Diagram-

Four major components of a collaboration diagram include the following:
1. Objects. These are shown as rectangles with naming labels inside. The naming label follows
the convention of object name: class name. If an object has a property or state that specifically
influences the collaboration, this should also be noted.
2. Actors. These are instances that invoke the interaction in the diagram. Each actor has a name
and a role, with one actor initiating the entire use case.
3. Links. These connect objects with actors and are depicted using a solid line between two
elements. Each link is an instance where messages can be sent.
4. Messages between objects. These are shown as a labeled arrow placed near a link. These
messages are communications between objects that convey information about the activity and
can include the sequence number.

Explain and include in use case" in UML means:

Explain: Provide a clear definition of a concept, like inheritance or polymorphism.
Include in Use Case: Demonstrate the concept in a practical scenario using a UML diagram, showing
how it works in a real-world application.
Aspect Deploy Diagram
Process of making software operational in Visual tool for representing software system's
Definition a live environment. structure, behavior, or workflow.
 Aspect Deploy Diagram
To transition the software from To aid in understanding, documenting, and
development to a usable state for end- communicating various aspects of a software
Purpose users. system.
Involves building, testing, configuring, and Involves selecting the appropriate diagram type
Key Steps installing the software. and representing system elements graphically.
Tools like Jenkins for automation, Docker Tools like UML (Unified Modeling Language) for
Tools for containerization, and AWS or Azure for standard diagrams, and software like Visio or
Used cloud deployment. Lucidchart for creation.
A graphical representation, such as a flowchart
A deployed application ready for use by or architectural diagram, of the software
Outcome end-users or clients. system.

SDLC
The Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop, and test high-quality software. The SDLC aims to produce a high-quality software product
that meets or exceeds customer expectations, reaches completion within times and cost estimates,
and is efficient and bug-free.
Here's a brief overview:
1. Requirement Analysis: Identifying the specific requirements and needs for the software.
2. Design: Planning the software architecture and creating design specifications.
3. Implementation (or Coding): Actual coding of the software according to the design.
4. Testing: Checking the software for errors and bugs, and verifying it meets the required needs.
5. Deployment: Releasing the software to users.
6. Maintenance: Updating and improving the software over time based on user feedback and
evolving needs

Object-Oriented (OO) Testing

Object-Oriented (OO) Testing is a methodology for testing software systems developed using object-
oriented programming concepts. This approach focuses on verifying the functionality, reliability, and
performance of software where the architecture is based on objects and classes.
Techniques-
Class Testing: Examining individual classes for proper functionality.
State-Based Testing: Ensuring objects correctly transition between states.
Method Testing: Testing each method in a class for expected operation.
Integration Testing: Checking how different classes and objects interact.
Inheritance Testing: Verifying the behavior of subclassing and overriding.
Polymorphism Testing: Testing different object types under a common interface.
Encapsulation Testing: Making sure data hiding and access through methods work properly.
Exception Handling Testing: Ensuring proper management of error conditions.
Scenario Testing: Using real-life scenarios to test overall system functionality.

Aspect Object-Oriented Testing Conventional Testing

Unit of Testing Class is the unit. Module or subroutine is the unit.
Testing Isolation Tests operations as part of a class. Allows testing of individual operations.
 Aspect Object-Oriented Testing Conventional Testing
Focus On class composition. On procedural decomposition.
Approach Incremental testing. Sequential testing, often waterfall model.
Control Structure Hierarchical control structure. No hierarchical structure.
Allows top-down or bottom-up
Integration integration. Less defined integration order.
Unit, integration, validation, system
Testing Levels testing. Same levels, different approach

Advantages:
1. Reusability and Modularity: OO testing benefits from the modularity and reusability of classes
and objects, making the testing process more efficient.
2. Maintainability: The encapsulation of data and behavior in objects makes the system easier to
understand and maintain, simplifying the testing process.
3. Flexibility: OO design allows for easier updates and changes, facilitating more adaptable testing
strategies.
4. Integration Testing: The interaction between objects can be tested incrementally, making
integration testing more manageable.
5. Hierarchical Testing: OO Testing can follow the hierarchy of classes, allowing for systematic
and organized testing strategies.
Disadvantages:
1. Complexity in Relationships: The relationships between objects (like inheritance and
polymorphism) can introduce complexities, making it harder to isolate issues.
2. State-Based Testing Challenges: Testing objects in different states can be complex, especially
when state dependencies are involved.
3. Initial Learning Curve: Understanding the intricacies of OO concepts for testing purposes can
be challenging, especially for testers unfamiliar with OO programming.
4. Overhead in Testing Inherited Features: Testing inherited features in subclasses can lead to
redundancy and increased testing time.
5. Integration Issues: While integration testing is more manageable, the intricate interactions
between objects can sometimes lead to unexpected issues, requiring thorough and careful
testing.
Types of Interaction Diagram-
1. Sequence Diagrams: Focus on the order of messages exchanged between objects over time.
2. Communication Diagrams: Emphasize the relationships and interactions between objects,
showing message flow.
3. Timing Diagrams: Visualize the behavior of objects across a specific time period, highlighting
state changes and interactions.
4. Interaction Overview Diagrams: Combine sequence and activity diagrams, providing a high-
level view of control flow with focus on interactions.

Aspect Static Modeling Dynamic Modeling

Represents system structure and static Represents system behavior and
Definition elements. interactions.
Focuses On Classes, objects, relationships. Processes, state changes, interactions.
 Aspect Static Modeling Dynamic Modeling
UML
Diagrams Class, object diagrams. Sequence, state machine, activity diagrams.
Defines system architecture and data Models system behavior and response to
Purpose model. events.
Key Aspects Data structures, interfaces. Actions, timelines, workflows.
Application Useful in early design stages. Important throughout development.

Generalization:
 Represented by a line with a hollow arrowhead pointing from the subclass to the superclass.
 Indicates an "is-a" relationship where the subclass is a more specific version of the superclass.
 Example: A "Car" class as a superclass, and "ElectricCar" as a subclass.
Specialization:
 The inverse of generalization, it's the process of creating new subclasses from an existing class.
 Not represented as a separate symbol but is implicit in the generalization relationship.
 Example: "ElectricCar" is a specialization of the more general "Car" class.
Inheritance: This is the mechanism where one class (known as a subclass or derived class) derives
properties and methods from another class (known as a superclass or base class). In UML diagrams,
inheritance is represented by a line with a hollow arrowhead pointing from the subclass to the
superclass.
Polymorphism: In UML, polymorphism is not represented by a specific symbol but is implied through
the use of inheritance. It's the ability of different classes to respond differently to the same message
(method call). This concept is typically understood in a UML diagram when a subclass inherits from a
superclass and overrides or implements its methods.