•
•
•
•
•
•
•
Software engineering is a discipline that encompasses aspects of software production, from
early system specification to maintain the system after it has been deployed, it involves the
appropriate use of theories and methods to solve problems while considering organisational
and financial constraints
The main analogy used to describe the scale of software projects is based on building
structures in the real world, it ranges from individual work tasks like a dog house to small
team projects like houses, and complex operating systems with extensive requirements set
out
The Ariane 5 failure was caused by a software failure due to an arithmetic overflow
condition, reuses software from the prior Ariane 4 did not account for the Ariane 5s faster
landing speed, leading to system shutdowns and incorrect compensation, such that is
ultimately led to the destruction of the Ariane 5 rocket.
The process of engineering software differs from hardware engineering in that software is
mutable, i.e., liable to change, and can be updated with very little cost, in contrast to
hardware which requires substantial investment to change, this mutability allows continuous
improvement in software but also introduces unique challenges
Elements involved in engineering include:
o software specification – these are the requirements engineering process of
understanding and defining what services are required from the system and
identifying the constraints on the systems operation and development. SRS, software
requirements specification is a technical document describing the software’s
functionality, features, design, limitations and goals. It is a blueprint or roadmap for
software being built, it outlines how an application should operate and how the
product development team should build it.
o Design
o Validation – software validation is the process of the evaluation of software during or
at the end of the development process to determine whether it satisfies the
specified requirements, as per the software specification
o Verification – verification falls under the same wing as validation, it determines
whether the software satisfies the expected requirements, ensuring that software is
bug free, it is equivalent to software testing, which is checking the products of a
given development phase against the conditions imposed at the start of the phase
The software cris refers to the difficulty of writing correct, understandable and verifiable
computer programs, excavated exacerbated by rapid increases in computer power and the
complexity of the programs being tackled
Software engineering is important because society increasingly relies on software systems
that need to be produced reliably, economically, and quickly, Proper engineering techniques
inherently cost less and are in the long term more effective as such
o Bug free nature of well made software as a result of good strategical implementation
of the software development process, from following specification, to good testing
and validation throughout the process of development, leads to building a product
that is while more expensive to build that simply muddying out something that may
work in the long term, costs less to operate and causes less problems with say
possibly incompatible software developers who do not well understand what code is
doing due to bad choices during the development process, good design avoids
needing checking in the first place, and good design leads to choices made that make
•
•
•
•
•
•
•
it easier for future software developers to understand what the software does at the
code level
Software engineering is important because our modern society increasingly relies on
software systems that need to be produced reliably, economically, and quickly; proper
engineering techniques are more effective in the long term, which is the focus on software
development for meeting the requirements of the customer, as such the business who needs
the software to operate their e.g., social media platform
Despite the various methodologies employed to tackle the software crisis, there is
unfortunately no single solution for all the cases, such that software projects are large,
complicated, and prone to problems
User requirements are statements in natural language describing user expectations of the
system
o Good requirements are valid, consistent, complete, realistic and verifiable, a
requirements document is an official statement of all the requirements being set out
by say the business who needs the software
Functional requirements are specific statements of what the system should do, defining its
functions, while non-functional requirements are global statements on the system’s overall
qualities
The unified modelling language, abbreviated as UML, is a general multi purpose modelling
language intended for software intensive systems. It contains two categories of diagrams,
covering the structural/static diagrams and the behavioural dynamic/timing diagrams
o SysMl is an extension of UML for systems engineering, introducing new types of
diagrams such as requirements diagrams
The language of requirements is crucial for clear communication and avoidance of
misunderstandings/confusion. It often includes domain specific terminology and may be
supported by diagrams, tables and mathematical notations
Requirements engineering is a systematic process involving:
o Feasibility studies – this assesses the potential for success of the proposed plan or
project by defining its expected costs and projected benefits in detail, where it is a
good idea to have a contingency plan
▪ This is a typical term used in business
o Requirements elicitation
▪ The requirements gathering, asking what are the requirements of the
project, what if this, what if that etc. This is asking questions and getting
responses, this step requires stakeholders to answer in their part of what is
done and why
o Requirements analysis
▪ This is more the step taken by organising answers to the first part, in such,
finding which solutions are optimal, what are the trade offs with various
possible implementations, in this part they may be the odd question but it
isn’t the main point as this is about seeing which solution may be better
under various constraints, e.g., finding which is the fastest or cheapest, this
is more about how is something to be done and why des that way make
more sense than another
▪ Another way to think about this is that the elicitation needs to com before
the analysis, as otherwise, we are analysing nothing, which may not be
useful
▪
•
•
•
•
So in conclusion of this, first we elicit questions, usually from stakeholders,
and the answers are developed via requirements analysis, another way of
thinking about it is elicitation being the process of finding out what the
customers and potential customers say they think they want, as such
producing a wishlist of sorts, then distilling thw wishlist to produce a list of
actual requirements together with dependencies between them, involving
saying some things on the wishlist are out of scope for one reason or an
other, the analysis is an assessment of the requirements set out in usually
natural English by customers/potential customers, analysing these set out
requirements and coming to a conclusion on what to do in effect
▪ Requirements are typically expressed in the language of another domain and
need to be obviously understood by all stakeholders, commonly supported
by diagrams tables and mathematical notations
• Various tools and methods are employed in this process including
images, as mentioned before plain English, UML diagrams,
propositional logic, and formal specification languages, such that
they are used to specify the language of requirements
The principles of modelling involve making the right model choice for the right job at
different levels of abstraction, ensuring all abstraction levels are tied to reality, and maintain
independent yet consistent views on the same system
Diagram types
o The behavioural diagrams in UML depict the dynamic behaviour of the system, with
the inclusion of how it operates, interacts and changes, they include activity,
sequence, tate machine and use case diagrams
o Activity diagrams show graphical representations of step wise workflows, while
sequence diagrams illustrate how processes operate with one another in a time
sequence
o State machine diagrams describe the different states of a system and transitions
between them, while use case diagrams provide a high level representation of user
interaction with them
Information hiding in software engineering is the principle of hiding internal details of
components and showing only the necessary information to the outside world, thus reducing
system complexity and increasing robustness of a system
A class in object oriented design serves as a blueprint in defining them structure/attributes
and behaviour/methods of objects, it encapsulates data and operations, allowing for
instantiation and creation of objects
o Attributes in a class represent the data stored by instances and they convey the state
or characteristics of an object instance, such as pages, or title in a class called Book
o Operations of a class, also called methods, define the actions that can be performed
on or by objects of that class, they manipulate attributes or perform specific tasks
o Encapsulation is a concept in which the internal state of an object is hidden, and only
a prescribed group of functions, that being the public methods, are accessible from
outside the class, while private methods are hidden and accessible from only within
the class
▪ Such that public methods within a class are the only methods able to access
these private attributes, provided again that they are within the same class.
o
•
•
•
•
•
•
•
Visibility modifiers such as public, private and protected, control the accessibility of
class members, where as mentioned, public members are accessible from the
outside class, while private is only accessible from within the class
UML class diagrams
o A UML class diagram is a structural diagram showing classes in a system and their
relationships, this includes information about class attributes, operations, and
visibility,
o Static and non-static members in a class differ int hat the static members belong to a
class itself and are shared by all instances, while non static belongs to the
instance/object of that class.
o UML class diagrams can be translated into java code by converting the attributes and
operations into instance variables and methods, respectively in the java class
▪ An example of a class and its instances are book as a general template, with
instances like the hobbit or captain underpants or something
o UML class diagram consist of rectangles divided into three sections
▪ Top: class name
▪ Middle: attributes with + - ~ # access modifiers for public, private, package
private and protected respectively
▪ Bottom: Operations (methods) with the same access modifiers
o When an attribute or method is static in a class, as mentioned, this means that it
belongs to the class as a whole, such that it is shared by all instances, in UML, we
represent this by underlining these members, members referring to both the
attributes and methods
Constructors in object-oriented design are special operations that are used to create a new
instance of a class, initialising the new object’s properties and setting its initial state.
UML class diagrams, when converted into java code, involve attributes becoming instance
variables, operations becoming methods and visibility indicators transforming into java
access modifiers
Software reuse in object oriented design employs the reuse of existing software or
knowledge to build new software, facilitated by encapsulation, inheritance and
polymorphism
o Polymorphism describes the concept that you can access objects of different types
through some interface
o Encapsulation in object oriented sign involves the bundling date with methods that
manipulate it, restricting direct access to some object components for information
hiding
A class versus an instance of a class is a distinction between a blueprint defining type and
specific realisations of that type with concrete attribute values
UML class diagrams depict constructors as operations without a return type responsible for
initialising new instances of a class
The significance of encapsulation lies ion grouping data and operations without a return type
responsible for initialising new instances of a class
•
•
•
•
•
•
•
Constructors
o Constructors play a vital role in grouping data and operations, hiding details from the
rest of the system, and allowing interaction by means of using public methods,
establishing a clear interface
o Constructors play a vital role in object-oriented design such that they create new
instances of a class, initialising object attributes and setting up necessary states or
connections
The inherent difference between static and non-static members in classes is that the static
members are shared across all instances, while non static members are again, unique to each
instance of the class
o UML underpins static members by underlining them, distinguishing them from
instance members
Translating UML class diagrams into java involves the attributes becoming instance variables,
operations becoming methods and visibility indicators becoming java access modifiers
Attributes in Java derivative from UML class diagrams are translated into instance, preserving
their visibility and type
A class diagram exercise scenario for a student may for example involve a student class with
attribute such as name, student number, programme of study, along with the methods for
setting and getting these attributes, and the behaviours like attending class or doing
assignments
The facebook illusion and teams in general
o This in software engineering refers to the misconception that a single person, such as
well, Facebook founder Mark Zuckerberg, can program large, complex systems, like
Facebook ALONE, this puts emphasis on the need for group-based software
engineering
o The properties of a good team in software engineering include the active
contribution from all members, a clear division of labour, and a good understanding
of the individual responsibilities, also requiring good communication,
complementing the weaknesses of a group, and effective leadership
Typical roles in a software engineering team include the customer interface manager, design
manager, implementation manager, test manager and the planning and quality managers all
of these imply their own roles
o A customer interface manager manages the teams relationship with customers, they
clarify the requirements, ensures responsiveness to customer requests and confirms
understanding of the requirements
o A design manager coordinates design documentation, ensures that standards are
met, and guides the team in UML and design methodology, while ensuring high
quality, well documented designs
o The implementation manager tasks include ensuring the quality of the
implementation, addressing programmer strengths, maintaining design clarity,
adherence to coding standards, and integrating code into the entire system
o The role of a test manager involves overseeing the quality of the teams testing,
ensuring that timely test plans, comprehensive testing of all classes and methods,
and enduring team members understand the testing strategies, they essentially
ensure that the testing process is eloquent
o
•
•
•
•
•
A planning ands quality manager is responsible for the role of team planning,
reporting plan status, meeting frequency, minutes protocol, version control usage,
code inspection, documentation quality and meeting the quality standard
Meeting minutes
o Minutes of meeting provide structure, continuity, memory aid, and progress
monitoring, including the topics discussed, decisions made, progress since the last
meeting and action items for the next meeting
o The structure of the minutes of meeting is typically inclusive of three parts, that
being the
▪ Topics and decisions
▪ Progress made since the last meeting
▪ A to do list of goals assigned to individuals
o The importance of continuity and memory in minutes of meetings lies in helping
attendees remember discussions from the last meeting, ensuring a clear
understanding of ongoing topics and tasks, and the provision of continuity over time
o Minutes of meetings aid the project progress by containing a to do list of goals
assigned to individuals, allowing structured monitoring of project progress and
breaking down larger tasks into manageable units
o The typical contents of meeting minutes include
▪ The date and time of the meeting
▪ The people attending the meeting
▪ Topics discussed during the meeting
▪ Action items for the next meeting
▪ Any special items that are specific to the context of the meeting
o The recommended length for minutes meetings is concise, fitting onto a double
sided page of A4 for a one hour meeting, in such capturing the main points and
decisions without a straight transcription of everything said
▪ Simply, it is an extrapolation of points made during the meeting such that
revisiting the meeting minutes document is an easy process that makes it
easy to understand what commitments were made, what progress was
tracked and the such
In class design, the responsibilities involve maintain the knowledge through object attributes
and performing actions through behaviours/operations, representing the class’s purpose and
services
o Identifying classes and responsibility is done by examining the nouns and verbs in
the requirements specification, ensuring all system responsibilities are identified
through system walkthrough and use case diagrams
o Responsibilities assigned to classes are identified by examining the context in which
the responsibility was found, using requirements specifications and class definitions,
and distributing responsibilities evenly across the system
Guidelines for class responsibility include stating the responsibilities as generally as possible,
keeping related information together, and maintaining information with related operations
shared among related objects
Class responsibilities are crucial in representing the purpose of the class and defining the
services it provides within he system
The difference between a class and an instance of a class is that the class is a blueprint
defining a type, including its data and behaviour, while an instance/object is a concrete
realisation with specific attribute values
•
•
•
•
•
•
•
•
•
•
•
•
UML class diagrams depict constructors as operations without a return type, responsible for
initialising new instances of a class
Encapsulation in object-oriented design involves the budling of data and operations together,
hiding details from the rest of the system, and allowing interaction through public methods,
establishing a clear interface
Constructors play a vital role in object-oriented design by creating new instances of a class,
initialising object attributes, and setting up necessary state or connections
The difference between static and non-static members in classes is that static members are
shared across all instances, associated with the class itself, while non static members are
unique to each instance
UML indicates static members by underlying them in class diagrams, signifying their
association with the class itself rather than the instance #
In class design, responsibilities involve maintaining the knowledge through object attributes
and performing actions through behaviours/operations, representing the class’s purpose and
services
Identifying classes and responsibilities is done by examining nouns and verbs in the
requirements specification, enduring all system responsibilities are identified through the
system walkthroughs and use case diagrams
Responsibilities assigned to classes are identified by examining the context in which the
responsibility was found, using requirements specifications and class definitions, and
distributing responsibilities evenly across the system
Guidelines for class responsibility include stating responsibilities as generally as possible, as
such, wee keep the relate information together, and maintain information with related
operations shared among related objects
Shared responsibilities, as defined in class design, refers to the responsibilities that need to
be divided among several classes due to their compound nature, this often is done through
relationships between classes, such as composition, aggregation or hierarchy, in other words,
certain tasks of behaviours are complex and involve multiple classes working together to
achieve a common goal
o On the other hand, unassigned responsibilities occur when a class is missing to
handle certain responsibilities or when a responsibility could be assigned to more
than one class, resolving unassigned responsibilities may require adding new classes
or reassigning responsibilities through walk throughs, ensuring a comprehensive
coverage of tasks in the system
CRC cards, or class responsibility collaborator cards play a crucial role in class design, they
help specify the responsibilities, including attributes and behaviours of a class and outline its
collaborations with other classes. CRC cards provide a tangible and visual representation,
aiding in the conceptualization and refinement of class designs
The design approach in class design involves a systematic process, it begins with thinking
about the data and operations that belong together, identifying candidate classes, CRC cards
are then created, reflecting on the design to divide or merge responsibilities effectively. This
process is followed by initialising a UML design to specify responsibilities effectively, this
process is followed by then after designing or merging the responsibility as needed, initiating
•
•
•
•
•
•
a UML design to specify the responsibilities and collaborations formally in the widely
recognised UML format
A class hierarchy is a structured organisation of classes based on inheritance
o Inheritance establishes a relationship where subclasses inherit features from their
parent classes, reducing redundancy of e.g., code and improving organisation
▪ And this implicitly makes designs more readable
o Class hierarchy is a key concept in object oriented design, it provides a clear
structure for organising and reusing code
In the realm of object oriented programming, inheritance is a fundamental mechanism
wherein a new class/subclass is derived from an existing class/superclass, this allows the
class to inherit feature such as methods and attributes from the superclass while having the
flexibility to add new features or modify preexisting ones.
Superclass and subclass are terms used to define the relationship between classes in an
inheritance hierarchy, a superclass is a general class from which other classes are derive from
it.
o Super classes provide a common set of attributes and methods
o Subclasses by contrast are derivatives from super classes that are more specific than
the superclass, inheriting its features and potentially adding to them or overriding
them to serve a derived but special function
Abstract classes and methods add another layer of complexity to class design, wherein
abstract classes cannot be instantiated, and they often contain abstract methods, which are
declared without an implementation
o Abstract classes cannot have instances, they serve as an abstraction to be built upon
through subclasses per se
o The purpose of these abstract classes is to define a template for future subclasses,
by having these abstract methods, we can ensure that the subclasses implement
certain behaviours, promoting a consistent structure and behaviour among all the
subclasses
o Abstract classes serve as a foundation for creating related classes with shared
characteristics
▪ This actually makes it easier to design and program them in the first place,
say for instance we want to have a School design with students, but these
students may have different permutations depending on their level of study,
such that there are different levels of students with varying operations on
their information, such that all students have common attribute such as
name, age, home address etc, but need different function to extrapolate
information about their specific level of study. We implement a hierarchical
design such that we have an abstract student class covering these common
attributes and behaviours pertaining to them, then the specific classes that
inherit from it, subclasses, will have the same attributes as the student
superclass but their own attributes and behaviours
In the unified modelling language/UML, the representation of inheritance involves a hollow
arrow pointing from the subclass to the superclass, this symbolizes a generalisationspecialisation relationship between classes. UML diagrams are essential in visually capturing
the structure and relationships between classes, aiding in system comprehension
The substitution principle, a key concept in object oriented programming, allows a subclass
instance to be used wherever an instance of its superclass is expected, thus promoting
•
•
•
•
•
•
flexibility and reuse. As objects of a derived class can seamlessly replace objects of their base
classes without the need to affect the functionality of the program.
Refining a class hierarchy involves the optimisation of the organisation of classes, this
includes, but is not limited to moving common responsibilities as high up as possible in the
hierarchy, eliminating nonfunctional or redundant unneeded classes, and ensuring that
subclasses add or modify functionality MEANINGFULLY.
o A well refined class hierarchy contributes more to a more maintainable and scalable
system, scalability is an important aspect in the software development process that
enables prior designed software to be easily transferable/mutable
Interfaces in object oriented programming are contracts that define a set of abstract
methods, implementing classes must provide concrete implementations of these methods,
the interfaces enforce certain behaviours and allow for multiple inheritance of types,
enhancing the flexibility in designing complex systems
o Implementing interfaces in java is done through the use of the implements keyword,
such that classes that implement an interface must provide concrete
implementations of all the abstract methods defined in the interface, this ensures
that classes adhering to the interface fulfil specific behaviours.
Multiple inheritance of interface refers to a class that implements multiple interfaces, this
allows the class to inherit the abstract methods of all the interfaces that it implements,
multiple inheritance promotes greater flexibility and code reuse, as a class can exhibit
multiple behaviours defined by different interfaces
Comparing abstract classes and interfaces in java reveals the distinctions in their usage, such
that
o Abstract classes can have both abstract classes, without a body, and methods with
an implementation, it is employed when classes share a common structure and
behaviour
o An interface on the other hand can only have abstract methods without
implementations, serving the purpose of implementing the same method signatures
across different classes, thus it INTERFACES
The characteristics of methods
o Those characteristics of the methods in interfaces differ from those in abstract
classes, such that in interfaces, all the method are implicitly abstract and public,
while in contrast, abstract classes can have abstract methods but can also provide
specific implementations unique to the abstract class
▪ Think of it such that abstract classes can be superclasses or subclasses of
other classes
o Interfaces act as contracts for behaviours, while the abstract classes can offer
common implementations shared with subclasses
Choosing between an abstract class and an interface depends on the design goals
o An abstract class is suitable when code needs to be shared among several closely
related classes
o Interfaces are preferred when various implementations share method signatures but
not necessarily the same method implementation, or when specifying behaviour for
disparate classes
▪ Method signatures are the combination of the method name and the
parameter list in say java, it is used to distinguish methods/operations with
•
•
•
•
•
the same name but different parameters that go into it, so an operation may
be different in behaviour depending on the parameters it takes
▪ Disparate as in different, not being able to be compared, such as explained
by the above with the method signatures/interfaces
The role of interfaces in enforcing a contract is significant, such that interfaces define a
contract that a class agrees to perform, any class that implements the interface commits to
providing specific behaviours/methods declared by the interface, this as such ensures
consistency in how different classes can be used with the system
Default methods in interfaces introduce a level of flexibility in interface evolution, these
methods have a default implementation, enabling interfaces to evolve without breaking the
classes that implement them. New methods can be added to the interfaces with default
implementations, allowing for strong backwards compatibility
Marker interfaces, although empty with no methods or fields, serve a specified/specific
purpose, they indicate to the JVM/java virtual machine or other frameworks that the class
implementing the interface will exhibit some special behaviour or requires a special
processing, marker interfaces provide a way to communicate additional information about c
a class’s intended usage
Some more superclass subclass abstract inheritance shit
o Super classes, also known as the parent or base class, is a general class that provides
common attributes and behaviours that inherit from it, it occupies a higher level in
the inheritance hierarchy and serves as a template for more specific classes
o Subclasses on the other hand, are classes that can add new attributes and methods,
or modify the inherited ones to create more specific functionality, subclasses
represent more specialized types within the hierarchy
o The difference between abstract and concrete classes lies in their instantiability.
Abstract classes cannot be instantiated and often contain abstract methods which
are intended to be implemented by subclasses. Concrete classes on the other hand
are regular classes that can be instantiated, providing complete implementations of
their methods. The purpose of an abstract class is to provide a common definition of
a base class that multiple subclasses can share, it may include abstract methods
without implementations expecting the subclasses to provide specific
implementations, abstract classes contribute to code organisation and reuse
Collaborations
o Collaborations in object-oriented programming represents the relationships where
one object/client utilises the services/responsibilities of another object/server to
fulfil its own responsibilities.
o Collaborations are one-way interactions designed to achieve specific goals and are
crucial for defining object relationships.
o Identifying collaborations involves examining the dependencies among
responsibilities, collaborations become apparent when a class needs to use another
class to fulfil its responsibilities, either by accessing data or by invocation of
methods. Recognising these relationships is essential for designing effective and
interconnected classes
o In collaborations, the client is the class that requests a service, while the server is the
class that provides the service, the server fulfils its own responsibilities by offering
services to the client, this distinction helps understanding the flow of control and
information within the system
o
•
•
•
•
•
•
•
•
•
•
Collaborations are typically implemented in code through public method calls
between classes. In this interaction, the client class calls methods of the server class
to access its services, effectively fulfilling its responsibilities, code implementation of
collaborations is foundational to object-oriented programming.
Compositions
o Composition, as a class relationship is a strong form of association, it implies that the
part, per se, cannot exist independently of the ‘whole’, the ‘part’ cannot exist
without the ‘whole’, it is made up/composed from the whole.
o UML diagrams denote this by a filled diamond and this signifies ownership, if the
whole is destroyed, the parts composed of it/owned by it will also be destroyed,
emphasizing a close and dependent relationship
Aggregation
o Aggregation is another class relationship, it is a weaker form compared to
composition, it is represented by an unfilled diamond in UML, aggregation indicates
that a whole-part relationship, in such case, the parts are able to exist independently
of the whole, an aggregation implies a looser association between the classes
Inheritance
o Is a kind of
Aggregation
o Is made up of
Composition
o Owns a
The above relationships contribute to modelling the structure and interactions of different
components in a system. Each type of relationship serves a specific purpose in designing
effective and modular systems.
UML class diagrams in general play a significant role in showing the relationship between
classes, these diagrams visually represent associations such as aggregation, composition and
inheritance
o UML diagrams aid in understanding the structure of a system and the interactions
between its various components
Collaborations, when translated into code, are typically realised through public methods calls
o This means that one object calls the methods of another object to utilise its services,
this implementation is foundational to object-oriented programming, facilitating
effective communication between classes
Storyboards in system design are sequences of sketches that illustrate a scenario or user
interaction with the system
o This draws inspiration from the film industry
o Storyboards provide a visual representation of the flow and design of the user
interface; they offer a tangible way to conceptualise and communicate the user
experience
o Task analysis, a core component of storyboarding, ensures that important tasks are
covered in the storyboard, they provide insights about user classes and tasks, they
identify the key usability aspects and help better understand the domain
▪ Task analysis contributes to creating user-centric and effective system
designs
UML activity diagrams are essential tools in software modelling, offering a visual
representation of a process or system’s workflow, such done using standardised symbols,
•
•
•
depicting the sequence of actions and decision points, such providing a dynamic view of the
system’s behaviour over time
o UML activity diagrams contribute significantly to the system's modelling by capturing
a modelling processes, decision points, concurrency, and synchronization. They offer
insights into how different components interact with each other over time, aiding in
understanding complex system behaviours.
Transitioning to coding practices, coding conventions play a crucial role in maintaining code
readability and consistency
o Coding conventions encompass guidelines for layout, including rules for indentation,
naming conventions, and overall code structure.
o Adherence to coding conventions enhances collaboration, reduces bugs and
promotes uniformity
o The significance of coding conventions lies in facilitating easier code reading,
understanding and maintenance. By promoting a consistent coding style,
conventions help identify bugs, maintain code structure and ensure a seamless
collaborative development process
o Common elements in coding conventions include rules for indentations, spaces vs
tabs for example, bracing styles for classes and methods, and guidelines for
maximum line length and method length
▪ These elements collectively contribute to a standardizes and maintainable
codebase
o In the context of version control, check style emerges as a valuable tool, it is an
automated tool designed to ensure that code adheres to specified coding standards,
by enforcing rules that are specific to different projects or teams
▪ Check style saves time in ode reviews and aids in maintenance of coding
standards consistently
o The order rules within a java source file and the recommended order of modifiers
further contribute to coding conventions
▪ Following these rules ensures a structured and organised codebase,
enhancing code readability and maintainability
Version control systems / VCS are pivotal in managing changes to code, especially in team
environments, they record changes over time, allowing devs to recall specific versions later
on. Two notable VCS are subversion/SVN and Git, they differ in their approach, SVN being
centralised, and Git being distributed
o Branches in VCS, like those present in Git, allow for the development of parallel
versions that diverge from the main line, merging, a critical aspect of version control
systems/VCS consolidates the changes from different branches back into the main
branch, ensuring a coherent project history
o Understanding and handling conflicts, situations where changes in different branches
are incompatible with each other, is crucial in version control
▪ Conflicts will require manual intervention to reconcile differences and
maintain the integrity of the merged version
o Git’s approach to distributed development allows each developer to have a full copy
of the project history, promoting independent work on local branches and seamless
integration of changes back into the main repository.
In the realm of documentation, Javadoc, a documentation tool available in Java plays a
significant role in that it generates API documentation for comments in the source code,
•
•
•
•
•
•
•
•
providing a clear and consistent format for documenting classes, interfaces, methods and
fields
o Javadoc comments follow a specific structure, beginning with /** and ending with
*/, and includes @tags for parameters, return values and exceptions
o They contribute to the overall understanding of code by developers and assist in
automatic generation of documentation
The prior flashcards touch upon GUI development in java, specifically the evolution from
AWT/Abstract Window Toolkit API to Swing and JavaFX
o JavaFX, with its advanced features like CSS styling, offers a modern approach to GUI
development
o The structure of a JavaFX application involves extending the Application class,
overriding the start method and creating a stage and a scene
o JavaFX uses layout panes for effective layout management, ensuring responsive and
organised displays, FXML, an XML based language, separates the GUI structure from
application logic, simplifying the GUI design and improving code maintainability
o Canvas in JavaFX provides a platform for drawing images using various features like
circles, lines, and rectangles, it involves accessing the graphics context to set stroke
and fill colours and draw shapes
Shifting focus to software engineering, the flashcards introduce the concept of the software
crisis, a period marked by challenges in developing large complex software systems, the
waterfall model, such being a sequential design process, is discussed as an approach to
software development with distinct phases such as requirements, design, implementation,
testing and maintenance
The waterfall model
o The waterfall model’s advantage include providing a clear, structured approach, but
it has its drawbacks
o It proves to be rather inflexible to changes and makes it challenging to backgtrack to
previous stages, making it unsuitable for projects with uncertain or rapidly changing
requirements
Effort distribution in software engineering involves balancing tasks among requirements
engineering, design and testing, this allocation ensures a comprehensive approach to
software development
Software maintenance encompasses corrective, adaptive, perfective and preventive
maintenance, addressing diverse needs post deployment, Boehms spiral model offers an
iterative approach with a focus on risk analysis, proving beneficial for large, complex and high
risk projects
The global spready of teams and resources marks a shift in software development, teams are
now dispersed worldwide, utilising components from various sources, including open source
parts and web services
Modern trends in software engineering highlight the rise of agile methods, a transition from
creating to utilizing software, the impact of open source software and increased diversity in
development methods
Ethical practices and professional standards are crucial in software engineering, emphasizing
public interest, client and employer priorities, high professional standards, and maintaining
integrity, with ethical leadership while supporting colleagues and continuous learning is
advocated
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Core principles in software engineering includes a well managed development process,
dependability, performance, effective specification and requirements management and the
ruse of stable developed software
The V model in software engineering emphasizes the verification and validation at each and
every stage of development, ensuring a clear path for checking the project throughout its
evolution
The incremental model involves dividing a clear path for checking the product throughout its
evolution
o Each increment builds on the previous one, allowing partial implementation to be
delivered and tested early on in the development cycle
Agile methodologies focus on iterative and incremental development, fostering collab
oration between cross functional teams. The agile manifesto prioritises individuals, working
software, customer collaboration and responsiveness to change
Agile methods have advantages such as client involvement, adaptability, collaboration and
suitability for smaller teams, however the challenges include the difficulty in the process of
scaling up for large projects, and managing the changing requirements
Extreme programming / XP is known for its extreme approach to iterative development and
frequent new versions,
Incremental delivery faces challenges in identifying common facilities needed by all
increments and managing system visibility and structure
Rapid software development emphasizes the speedy delivery through techniques like
prototyping, iterative development, and the use of software tools
Lightweight agile methods, such as incremental development and delivery, extreme
programming / XP, rapid programming and scrum offer flexible approach es to software
development
Incremental development and delivery involves designing, implementing and testing the
product incrementally until completion, it allows for early delivery, improves risk
management and simplifies complex projects
The process of prototyping involves creating preliminary versions of software to explore
design options and understand user needs, benefits of this process include improved
usability, a closer match to user needs, enhanced design quality and reduced development
effort.
User stories in agile development describe software features from an end user perspective,
aiding in understanding and prioritising requirements
Scrum, an agile framework, manages iterative development through sprints, daily stand ups,
sprint planning reviews and retrospectives, the scrum master facilitates the process and
ensures adherence to agile practices
Exceptions in java are objects representing errors or unexpected conditions, they disrupt the
programs normal flow and are handled using try catch blocks
o Designing custom exceptions in java involves extending existing exception classes to
provide more meaningful error information
o The throw early, catch late principle encourages throwing exceptions as soon as an
error is detected and catching them at a higher level for proper handling
o Squelching exceptions by using empty catch blocks can hide errors, leading to further
issues, it is recommended to handle or propagate exceptions properly
In summary, these flashcards cover a wide range of software engineering concepts,
methodologies and best practices, from traditional models such as the waterfall model to
•
•
•
•
•
•
•
•
•
•
•
•
•
•
modern agile methods, along with their ethical considerations, and specific java
programming principles. The comprehensive nature of these topics reflects the diverse
landscape of software development.
Creating custom exceptions in Java is a straightforward process, by extending an existing
exception class and adding a constructor to pass the error message, developers can tailor
exceptions to specific error conditions
The decision of whether to catch or propagate exceptions in java involves a best practice
debate, it is recommended to catch exceptions when they can be meaningfully handled and
to let them propagate otherwise
o An example illustrates a scenario in java programming where this decision-making
process is crucial based on the ability to effectively handle errors
Java categorises exceptions into two types, those being
o Checked exceptions, which must be caught or declared
o Unchecked exceptions, these are runtime exceptions and errors, which are not
required to be caught or declared
In depth custom exception design involves defining new exception classes for specific error
conditions, these classes should extend either runtime exception or exception, depending on
whether they are checked or unchecked (declared or not declared for runtime exceptions
and errors).
Moving into the design principles of software engineering
Subsystems are groups of classes that collaborate to perform specific functions, they serve as
abstractions to simplify complex systems, enhancing communication and system
understanding
The purpose of subsystems is to simplify communication between classes, making the
application easier to understand and modify
Collaboration graphs visualise the flow of information between classes and subsystems,
managing system complexity effectively.
The subsystems design process involves analysing class hierarchies and collaborations to
identify subsystems to be used, contributing to a well structured application, subsystems
support contracts, redefining external class collaborations to subsystem-level interactions
Identifying a subsystem involves looking for groups of classes with strong dependencies,
common goals, or functionalities that can be logically grouped, subsystem cards specify
subsystem contracts and how they are delegated to classes within the subsystem
To simplify collaborations with subsystems, we must focus on minimising the external class
interactions and contracts, this improves encapsulation and simplifies the design for better
maintainability
Minimising collaborations of a class involves reducing direct interactions with other classes,
simplifying design and enhancing maintainability, similarly, minimising delegations aims to
reduce the chain of method calls among classes, enhancing clarity and reducing
dependencies
An example of an inventory system illustrates the complexity that can arise with
interdependencies among classes, through the use of subsystem design, the system can be
streamlined into fewer, more streamlined steps.
Nested subsystems are suggested when a subsystem has too many contracts, further dividing
it into smaller, more manageable parts, checking the design involves reviewing subsystem
design to reduce complexity, improve maintainability and ensure functionality
•
Integration testing is a crucial level of software testing where individual units are combined
and tested as a group to expose faults in their interaction’s, it ensures that combined parts of
an application function correctly, especially in complex systems
o Common issues in integration testing include mismatched data types, incorrect data
formats, timing issues, and communication errors between modules, stubs and
drivers are used to simulate missing components and isolate the part of the system
that is being tested
o Top down integration testing starts from the top of the system hierarchy and
progresses downwards, integrating modules step by step using stubs for lower
modules.
o Bottom up integration testing begins with testing the lower level modules and
gradually integrates them into the higher level module s by making the use of drivers
for the higher modules
o Integration testing may pose challenges such as complexity, time consumption and
requiring a thorough understanding of system interactions, frequent errors include
mismatched parameters, units of measurement differences and out of range method
arguments
o A case study of the (planet) Mars Climate Orbiter emphasizes the importance of
PROPER integration testing
▪ A failure in integration due to units of measurement mismatch led to an
extremely costly mission failure
o Stubs and drivers play a vital role in integration testing by simulating missing
components
▪ Stubs mimic already called components
▪ While drivers mimic calling components
o In summary, integration testing focuses on testing interfaces between components,
fixing communication errors that occur when integrating different parts of a system,
it comes after unit testing and before testing the entirety of the system, ensuring
that the parts work well together/integrate nicely and setting the stage for the next
phase of testing the whole system