SEG2105: Introduction to Software

Engineering
Practical Software Development using UML and Java

Table of Contents
SEG2105: Introduction to Software Engineering........................................................1
Practical Software Development using UML and Java..............................................1
Chapter 4: Developing Requirements..................................................................2
Chapter 6: Using Design Pattern..........................................................................9
Chapter 8: Modelling Interactions and Behaviour..............................................20
Chapter 9: Architecting and Designing Software................................................30

1
Chapter 4: Developing Requirements
4.1 Domain Analysis
 Definition: The process by which a software engineer learns about the domain to better
understand the problem
 Domain: the general field of business or technology in which the clients will use the
software
 Domain expert: a person who has a deep knowledge of the domain
 Benefits:
o Faster development
o Better System
o Anticipation of extensions

 Domain Analysis Documentation:

4.2 The Starting Point for Software Projects

4.3 Defining the Problem and the Scope

 Express problem:
o Difficulty the users or customers are facing
o An opportunity that will result in some benefits such as improved productivity or
sales

2
  Solution: Entailing developing software
 A good problem statement is short and succinct
 Defining the scope:
 Narrow the scope by defining a more precise problem
 List all the things you might imagine the system doing
 Exclude some of these things if too board
 Determine high-level goals if too narrow

4.4 What is a Requirements?

 Definition: A statement describing either:
o An aspect of what proposed system must do
o A constraint on the system’s development
 Must contribute in some way towards adequately solving the customer’s problem
 Set of requirements as a whole represents a negotiated agreement among the stakeholders
 Writing pitfalls to avoid
o Do not speculate

 Standard for Writing a Requirement

o Each requirement must form a complete statement
o Each requirement contains a subject and predicate
 Subject: a user type or the system under discussion
 Predicate: a condition, action or intended result

3
  Verb in predicate: “shall” / “will”/ “must” to show
 The whole requirement provides the specifics of a desired end goal or result
 Contains a success criterion or other measurable indication of the quality
 Writing pitfalls to Avoid
o Do not speculate: No room for general terms about the things that somebody probably
wants. Danger signs: vague subject type and generalization words such as usually,
generally, often, normally, typically
o Do not express suggestions or possibilities: Suggestions that are not explicitly stated
as requirements are invariably ignored by developers. Danger signs: may, might,
should, ought, could, perhaps, probably
o Avoid wishful thinking: wishful thinking means asking for impossible – 100%
reliable, safe, handle all failures, fully, upgradeable, run on all platforms
o Do not use vague indefinable terms: Many words used informally to indicate quality
are too vague to be verified. Danger signs: user-friendly, highly versatile, flexible,
to maximum extent, approximately, as much as possible, minimal impact
4.5 Types of Requirements
a. Functional requirements: Describe what the system should do
 What inputs the system should accept
 What outputs the system should produce
 What data the system should store that other systems might use
 What computations the system should perform
 The timing and synchronization of the above
b. Quality requirements: Constraints on the design to meet specified levels of quality
 All must be verifiable
 Examples: Constraints on
o Response time
o Throughput
o Resource usage
o Reliability
o Availability
o Recovery from failure
o Allowances for maintainability and enhancement
o Allowances for reusability
c. Platform requirements: Constraints on the environment and technology of the system
d. Process requirements: Constraints on the project plan and development methods.
4.6 Use-Cases: Describing how the user will use the system
 Definition: A use case is a typical sequence of actions that a user performs in order to
complete a given task

4
 Object of use case analysis: model the system from the point of view of how users
interact with this system or when trying to achieve their objectives.
 It is one of the key activities in requirements analysis

 A use case model consists of:

o A set of use cases
o An optional description of
diagram indicating how they are
related.
 A use case should:
o Cover a sequence of steps
o Describe the users’ interaction
with the system (not the
computations of the system)
o Be as independent as possible
from any particular user interface design
o Only include actions in which the actor interacts with the computer (Not actions a
user does manually)
 Extensions: Used to make optional
interactions explicit or to handle
exceptional cases. Keep the description of
the basic use case simple

5
  Generalization:
o Much like super classes in a class diagram
o A generalized use case represents several similar use cases
o One or more specializations provides details of the similar use cases
 Inclusions:
o Allow one to express commonality between several different use cases
o Are included in other use cases: Even every different use cases can share
sequences of actions. Enable you to avoid repeating details in multiple use cases
o Represent the performing of a lower-level task with a lower-level goal.

 Use Cases vs Scenarios

o Definition: A scenario is an
instance of a use case that
expresses a specific occurrence
of the use case with a specific
actor operating at a specific time
and using specific data.

 Modelling: Choosing use cases on which to focus

6
 o Often one use-case (or a very small number) can be identified as central to the
system. The entire system can be built around this particular use case
o There are other reasons for focusing on particular use cases: Some use cases will
represent a high risk because for some reason their implementation is problematic.
Some use cases will have high political or commercial value
 The benefits of basing software development on use cases
o Use cases can: Help to define the scope of the system. Be used to plan the
development process. Be used to both develop and validate the requirements. Form
the basis for the definition of test cases. Be used to structure user manuals.
 User stories vs. use cases
o The term “user stories” is used in agile development: Conceptually very similar to
use case and typically less formal.
4.7 Techniques for Gathering and Analysing Requirements
a. Observation:
 Read documents and discuss requirements with users
 Shadowing important potential users as they do their work, ask the user to explain
everything he or she is doing
 Session videotaping
 Balancing the requirements of different stakeholders
b. Interviewing
 Conduct a series of interviews and ask about: specific details, the stakeholders’ vision for
the future, if they have alternative ideas, for other sources of information and ask them to
draw diagram.
c. Brainstorming:
 Appoint an experience moderator
 Arrange the attendees around a table
 Decide on a trigger question
 Ask each participant to write an answer and pass the paper to its neighbour
d. Prototyping
 The simplest kind: paper prototype
o A set of pictures of the system that are shown to users in sequence to explain what
would happen
 The most common: A mock up of the system’s UI
o Written in a rapid prototyping language
o Does not normally perform any computations, access any database or interact
with any other systems
o May phototype a particular aspect of the system
 Use case analysis

7
 o Determine the classes of users that will use the facilities of this system (actors)
o Determine the tasks that each actor will need to do with the system
e. Level of detail required in requirements
 More detailed requirements are likely needed when:
o The system is large and complex
o There is a need to interface to hardware or other systems
o Clients and users are in a very technical domain (Engineer. Science, financial
analysis, etc)
o There could be large costs, safely issues or security issues if the requirements are
faulty
4.9 Reviewing Requirements
Each individual requirement should:
 Have benefits that outweigh the costs of development
 Be important for the solution of the current problem
 Be expressed using a clear and consistent notation
 Be unambiguous
 Be logically consistent
 Lead to a system of sufficient quality
 Be realistic with available resources
 Be verifiable
 Be uniquely identifiable
 Does not over-constrain the design of the system
Key quality of requirements
 The requirements should be:
o Sufficiently complete
o Well organized
o Clear
o Agreed to by all the stakeholders
 Traceability

8
Chapter 6: Using Design Pattern
6.1 Introduction to Patterns
1. Introduction
 Definition: The recurring aspects of designs are called designed patterns
o A pattern is the outline of a reuseable solution to a general problem encountered
in a particular context
o Many of them have been systematically documented for all software developers
to use
o A good pattern should: Be as general as possible. Contain a solution that has been
proven to effectively solve the problem in the indicated context
 Studying patterns is an effective way to learn from the experience of others => Improve
the design
2. Pattern description
 Context: The general situation in which the pattern applies
 Problem: A short sentence or two raising the main difficulty
 Forces: The issues or concerns to consider when solving the problem
 Solution: The recommended way to solve the problem in the given context
 Antipatterns (Optional): Solutions that are inferior or do not work in this context
 Related patterns (Optional): Patterns that are similar to this pattern
 References: Who developed or inspired the pattern
6.2 The Abstraction-Occurrence Pattern
(Abstraction: Generalized class, Occurrence:
Specialized class – Sub class)
 Context:
o Often in a
domain
model you
find a set of
related
objects
(occurrences)
o The members
of such a set share common information, but also differ from
each other in important ways
 Problem: What is the best way to represent such sets of occurrences in a class diagram>
 Forces: You want to represent the members of each set of occurrences without duplicating
the common information.

9
6.3 The General Hierarchy Pattern

 Context: Object in a hierarchy can

have one or more objects above them
(superior) and one or more objects
below them (subordinates). Some
objects cannot have any subordinates
 Problem: How do you represent a
hierarchy of objects, in which some
objects cannot have subordinates
 Forces: You want a flexible way
representing the hierarchy that
prevents certain objects from having
subordinates
 All the objects have many common properties and operations

6.4 The Player-Role Pattern

 Context: A role is a particular set of properties associated with an object in a particular
context. An object may play different roles in a different context
 Problem: How do you best model players and roles so that a player can change roles or
process multiple roles?

10
  Forces:
o It is desirable to improve encapsulation by capturing the information associated
with each separate role in a class
o You want to avoid multiple inheritance
o You cannot allow an instance to change class
 Solution: No multiplicity here because it depends on the context (for Player Role only)

 Antipattern:
o Merge all the properties an behaviours into a single “Player” class and not have
“Role” classes at all
o Create role as subclasses of the “Player” class
 Example

6.5 The Singleton Pattern

 Context: It is very common to find

classes for which only one
instance should exist (singleton) –
Should only exist one

11
  Problem: How do you ensure that it is never possible to create more than one instance of
a singleton class?
 Private Constructor: Prevents the class from being instantiated from outside.
 Static Instance Variable: Holds the single instance of the class.
 Public Static Accessor Method: Provides a global point of access to the single instance
6.6 The Observer Pattern
 Context:
o When an association
is created between 2
classes, the code for
the classes becomes
inseparable
o If you want to reuse
one class, then you
also have to reuse the
other

 Problem: How do you reduce the interconnection between classes, especially between
classes that belong to different modules or subsystems?
 1. Use Interfaces or Abstract Classes
 2. Event Bus or Message Broker
 3. Dependency Injection
 4. Publish-Subscribe Pattern
 5. Observer Aggregation
 6. Cross-Module Communication via Event-Driven Design
 7. Encapsulation of the Subject
 Antipattern:
o Connect an observer directly to an observable so that they both have references to
each other
o Make the observers subclasses of the observable
 Benefits of Decoupling in Observer Pattern
1. Improved Maintainability: Changes in one module do not propagate to others.
2. Flexibility: Observers and subjects can evolve independently.
3. Testability: Easier to mock or stub dependencies for unit tests.
4. Scalability: Observers and subjects can reside in separate modules or subsystems,
making it easier to scale the application.

12
6.7 The Delegation Pattern
 Context:
o You are designing a method in a class
o You realize that another class has a method which provides the required service
o Inheritance is not appropriate (Because the ISA rule does not apply)
 Problem: How can you most effectively make use of a method that already exists in other
class?
 1. Delegate Through Composition
 2. Use Interfaces to Define the Contract
 3. Leverage Method References (Java 8+)
 4. Dynamic Delegation with Reflection
 5. Decorator Pattern for Enhanced Delegation

 Key Benefits of Delegation

o Reusability: Leverage existing methods instead of duplicating code.
o Separation of Concerns: Keep logic centralized in the class where it belongs.
o Flexibility: Swap out delegate objects or methods dynamically if needed.
o Encapsulation: The delegating class hides the details of the delegation.

 Forces: You want to minimize development cost by reusing methods.

 Antipatterns:
o Overuse generalization and inherit the method that is to be reused
o Instead of creating a single method in the “Delegator” that does nothing than call
a method in the “Delegate” – consider having many different methods in the
“Delegator” call the delegate’s method
o Access non-neighboring classes
 Return specificFlight.regularFlight.flightNumber();
 Return getRegularFlight().flightNumber();
6.8 The Adapter Pattern
 Context:

13
 o You are building an inheritance hierarchy and want to incorporate it into an
existing class
o The reused class is also often already part of its own inheritance hierarchy
 Problem:
o How to obtain the power of polymorphism when reusing a class whose methods:
have the same function but not the same signature as the other methods in
hierarchy?
 1. Define a Target Interface
 2. Create the Adapter Class
 3. Delegate Method Calls
 4. Use Polymorphism
 Forces: You do not have access to multiple inheritance, or you do not want to use it

6.9 The Façade Pattern

 Context:
o Often, an application contains several complex packages
o A programmer working with such packages has to manipulate many different
classes
 Problem: How do you simplify the view that programmers have of a complex package?
 1. Provide a Simplified Interface
 2. Hide Internal Complexity
 3. Reduce Learning Curve
 4. Decouple Clients from Subsystems
 5. Provide Clear Usage Guidelines

 Forces:
o It is hard for a programmer to understand and use an entire subsystem
o If several different application classes call methods of the complex package, then
any modifications made to the package will necessitate a complete review of all
these classes.

14
6.10 The Immutable Pattern
 Context: an immutable object is an object that has a state that never changes after
creation
 Problem: How do you create a class whose instances are immutable?
 Mark the Class as Final:
 Make All Fields Private and Final
 Provide a Constructor to Set the Fields
 Do Not Provide Setter Methods
 Return Defensive Copies for Mutable Fields

 Forces there mut be no loopholes that would allow “illegal” modification of an

immutable object
 Solution:
o Ensure that the constructor of the immutable class is the only place where the
values of instance variables are set or modified.
o Instance methods which access properties must not have side effects
o If a method that would otherwise modify an instance variable is required, then it
has to return a new instance of the class.
6.11 The Read-Only Interface Pattern
 Context: You sometimes want certain privileged classes to be able to modify attributes of
objects that are otherwise immutable
 Problem: How do you create a situation where some classes see a class as read-only
whereas others are able to make modifications?
o Define a Read-Only Interface:
o Define a Modifiable Interface
o Implement Both Interfaces
o Control Access
 Benefits:

15
 o Separation of Concerns: The Read-Only and Modifiable interfaces separate the
concerns of different components (viewers vs. editors), making the system easier to
maintain and reason about.
o Flexibility: You can control who has read-only access and who can modify the data
by choosing which interface to expose to a given client.
o Reduced Risk of Accidental Modifications: By returning only the read-only interface
where modification is not allowed, you reduce the risk of accidental modifications in
parts of the code that should only view the data.
 Forces:
o Restricting access by using the public, protected and private keyword is not
adequately selective
o Making access public makes it public for both reading and writing
 Antipatterns:
o Make the read-only class a subclass of the “Mutable” class
o Override all methods that modify properties such that they throw an exception

6.12 The Proxy Pattern

 Context:
o Often, it is time-consuming and complicated to create instances of a class
(heavyweight classes)
o There is a time delay, and a complex mechanism involved in creating the object in
memory
 Problem: How to reduce the need to create instances of a heavyweight class?
o Define an Interface
o Create the Real Object (Heavyweight Class)
o Create the Proxy Class
o Lazy Initialization
 Benefits:

16
 o Reduced Memory Usage: The real object (RealImage) is only instantiated when
necessary. If the object is never accessed, it is never created, saving memory and
computational resources.
o Faster Initialization: If the heavyweight class is resource-intensive to initialize (e.g.,
loading from disk, making network calls, etc.), the proxy delays this initialization,
leading to faster application startup times.
o Lazy Loading: Resources are loaded only when they are needed, which can be
especially useful in scenarios with many objects, large data sets, or costly operations.
 Forces:
o We want all the objects in a domain model to be available for programs to use
when they execute a system’s various responsibilities.
o It is also important for many objects to persist from run to run of the same
program.

6.13 The Factory Pattern

 Context: A reusable framework needs to create objects, however the class of the created
objects depends on the application
 Problem: How do you enable a programmer to add new applications – specific class into
a system built on such a framework?
o Define the Product Interface
o Define the Abstract Factory
o Implement Concrete Factories
o Use a Factory Registry (Optional)
 Benefits of the Factory Pattern in This Scenario:
o Extensibility: Programmers can easily add new product classes by implementing the
Application interface and adding a new concrete factory. No changes are needed in
the core system.

17
 o Separation of Concerns: The creation logic is separated from the client code, ensuring
that the client only interacts with the abstract Application interface.
o Maintainability: Adding new product types is straightforward and does not require
modifying the existing code that depends on the factory.
o Decoupling: The client code is decoupled from the concrete classes, relying only on
the abstract factory interface.
 Forces: We want to have the framework create and work with application-specific classes
that the framework does not yet know about.
 Solution:
o The framework delegates the creation of application-specific classes to a
specialized class, the Factory
o The Factory is generic interface defined in the framework
o The factory interface declares a method whose purpose is to create some subclass
of generic class.

18
6.14 Detailed Example: Enhancing OCSF with some design patterns

6.15 Difficulties and Risks When Creating Class Diagram

a. Patterns are not panacea:
 Whenever you see an indication that a pattern should be applied, you might be tempted to
blindly apply the pattern
 This can lead to unwise design decisions
 Resolution: Always understand in depth the forces that need to be balanced, and when the
other patterns better balance the forces. Make sure you justify each design decision
carefully
b. Developing patterns is hard
 Writing a good pattern takes considerable work
 A poor pattern can be hard to apply correctly
 Resolution: Do not write patterns for others to use until you have considerable both in
software design and in the use of patterns.
c. Patterns – More Examples
 Factory pattern + Proxy Pattern
 Observer pattern
 Delegation: Spring Security Filter

19
Chapter 8: Modelling Interactions and Behaviour
8.1 Interaction Diagrams
Sequence diagrams and Communication diagrams
 Definition: Interaction diagrams are used to model the dynamic aspects of a software system
o They help you to visualize how the system runs
o An interaction diagram is often built from a use case and a class diagram. The objective is
to show how to set of objects accomplish the required interactions with an actor.

 Elements found in interaction diagrams

o Instances of classes: Shown as boxes with the class and object identifier underlined
o Actors: Use the stick-person symbol as in use case diagrams.
o Messages: Shown as arrows from actor to object, or from object to object

 Sequence Diagrams
A sequence diagram shows the sequence of messages exchanged by the set of objects
performing a certain task
o The objects are arranged horizontally
o An actor that initiates the interaction is often shown on the left
o Ther vertical dimension represents time
o A vertical line, called a lifeline, is attached to each object or actor
o The lifeline becomes a broad box, called an activation box during the live activation
period.
o A message is represented as an arrow between activation boxes of the sender and
receiver: A message is labelled and can have an argument list and a return value.

o An iteration over objects is indicated by an asterisk preceding the message name.

o If an object’s life ends, this is shown with an X at the end of the lifeline (Cannot cancel
Booking if it is not existed, Specific Flight and Booking have the same indent)

20
 Fragments: Allow multiple sequences to be represented in compact form (may involve all
participants or just subset)

o Alt: For alternative with conditions

 Multiple operands (separated by dashed lines)
 Each operand has guard condition (no
condition implies true)
 One will be choses exclusively – non-
deterministically if more than one evaluates to
true.
 Special guard: else: True if no other guard
condition is true

o Opt: For optional behavior

 To specify a guarded behavior fragment with no
alternative
 Special case of alt
 Equivalent to an alt with two operands: The first
is the same as the operand for the opt. The
second is an empty operand with an else guard.

o Loop (lower bound, upper bound): For loops

 Loop fragment may execute multiple times
 At least executed the minimum count

21
  Up to a maximum count as long as the guard is true (no condition implies true)

o Par: For concurrent behavior

 Two or more operands that execute in parallel

o Ref: For reference other sequence diagrams

8.2 State Diagrams
A state diagram describes the behaviour of a system, some part of a system, or an
individual object
 At any given point in time, the system or object is in a certain state: Being in a state means
that it will behave in a specific way in response to any events that occur.
 Some events will cause the system to change state. In the new state, the system will behave
in a different way to events (Depends on the time)
 A state diagram is a directed graph where the nodes are states, and the arcs are transitions.

22
 States:
o At any given point in time, the system is in one state
o It will remain in this state until an event occurs that
causes it to change state
o A state is represented by a rounded rectangle
containing the name of the state
o Special states:
 A black circle represents the start state
 A circle with a ring around it represents an end
state

 Transitions
o A transition represents a change of state in response to an event. It is considered to occur
instantaneously.
o The label on each transition is the event that causes the change of state.

23
 Activities in state diagrams: An activity is something that takes place while the system is in a
state

o It takes a period of time

o The system may take a transition
out of the state in response to
completion of the activity
o Some other outgoing transition may
result in: The interruption of the
activity and An early exit from the
state.

 Actions in state diagrams: An action is something that takes place effectively instantaneously
when:
o When a particular transition
is taken
o Upon entry into a particular
state
o Upon exit from a particular
state
 An action should consume
no noticeable amount of time

 Nested substates and guard conditions: A state diagram

can be nested inside a state. The states of the inner
diagram are called substates.

24
Action Ordering – Composite States: A composite state is a state that is composed of nested
substates. It represents a
higher-level state that can be
broken down into more
granular states, allowing the
model to capture more
complex behavior. Composite
states are used to:

1. Simplify Diagrams: By grouping related states together.

2. Show Hierarchical Behavior: By nesting substates within a parent state.
3. Reduce Redundancy: By reusing transitions and actions for all substates of a composite
state.

25
8.3 Activity Diagrams
An Activity Diagram is like a state diagram except most transitions are caused by internal
events, such as the completion of computation
 An activity diagram:
o Can be used to understand the flow of work that an object or component performs
o Can also be used to visualize the interrelation and the interaction between different use
cases.
o Is most often associated with serval class
 On of the strength activity diagrams is the representation if concurrent activities.
 Basic Notational Elements of Activity Diagrams

26
 Representing Concurrency: Concurrency is shown using forks, joins, and rendezvous.
o A fork: has one incoming transition and multiple outgoing transitions. The execution
splits into two concurrent threads.
o A rendezvous: has multiple incoming and
multiple outgoing transitions. Once all the
incoming transitions occur all the outgoing
transitions may occur.
o A join: has multiple incoming transitions
and one outgoing transition.
 The outgoing transition will be
taken when all incoming
transitions have occurred.
 The incoming transitions must
be triggered in separate threads.
 If one incoming transition
occurs, a wait condition occurs
at the join until the other
transitions occur.

27
 Swimlanes: Activity diagrams are most often associated with several classes. The partition of
activities among the existing classes can be explicitly shown using swimlanes.

8.4 Implementing Classes Based on Interaction and State Diagrams

 You should use these diagrams for the parts of your system that you find most complex
 Interaction, activity and state diagrams help you create a correct implementation.
 This is particularly true when behaviour is distributed across several use cases. (e.g. A state
diagram is useful when different conditions cause instances to respond differently to the same
event)

28
Class CourseSection{
States:
‘Planned’: closedOrCancelled == false && open == false

‘Closed’ (course section is too full, or being taught): closedOrCancelled == true &&
registrationList.size() > 0
}
Class CourseSection{
States:
‘Open’ (accepting registrations):
open == true

‘NotEnoughStudents’ (substate of ‘Open’):

29
 open == true &&
registrationList.size() < course.getMinimum()

‘EnoughStudents’ (substate of ‘Open’):

open == true &&
registrationList.size() >= course.getMinimum()
}
8.5 Difficulties and Risks in Modelling Interaction and Behaviour
Dynamic modelling is a difficult skill
 In a large system there are a very large number of possible paths a system can take
 It is hard to choose the classes to which to allocate each behavior:
o Ensure that skilled developers lead the process and ensure that all aspects of your models
are properly reviewed.
o Work iteratively:
 Develop initial class diagrams, use cases, responsibilities, interaction diagrams and
state diagrams
 Then go back and verify that all of these are consistent, modifying them as necessary
o Drawing different diagrams that capture related, but distinct, information will often
highlight problems.

30
Chapter 9: Architecting and Designing Software
9.1 The Process of Design
 Definition: Design is a problem-solving process whose objective is to find and describe a
way
o To implement the system’s functional requirements
o While respecting the constraints imposed by the quality, platform and process
requirements (including the budget)
o And while adhering to general principles of good quality.

a. Design as a series of decisions

A designer is faced with a series of design issues
 These are sub-problems of the overall design problem.
 Each issue normally has several alternatives solutions – design options
 The designer makes a design decision to resolve each issue. This process involves choosing
the best option from among the alternatives.

b. Making decisions
To make each design decision, the software engineer uses:
 Knowledge of the requirements, the design as created so far, the technology available,
software design principles and “best practices”, what has worked well in the past.
c. Design Space
The space of possible designs that could be achieved by choosing different sets of
alternatives is often called the design space

d. Component
Any piece of software or hardware that has a clear role
 A component can be isolated, allowing you to replace it with a different component that
has equivalent functionality.
 Many components are designed to be reusable
 Conversely, others perform special-purpose functions

31
e. Module: A component that is defined at the programming language level. (e.g. methods,
classes, and packages are modules in Java)
f. System:
A logical entity, having a set of definable responsibilities or objectives, and
consisting of hardware, software or both.
 A system can have a specification which is then implemented by a collection of components
 A system continues to exist, even if its components are changed or replaced
 The goal of requirements analysis is to determine the responsibilities of a system.
 Subsystem: A system that is part of a larger system, and which has a definite interface.

g. Top-down and bottom-up design

 Top-down design:
o First design the very high-level structure of the system.
o Then gradually work down to detailed decisions about low-level constructs
o Finally arrive at detailed decisions such as:
 The format of particular data items
 The individual algorithms that will be used.
 Bottom-up design
o Make decisions about reusable low-level utilities.
o Then decide how these will be put together to create high-level constructs
 A mix of top-down and bottom-up approaches are normally used:
o Top-down designs is almost always needed to give the system a good structure
o Bottom-up design is normally useful so that reusable components can be created.
h. Different aspects of design
 Software architecture:
o The division into subsystems and components: How these will be connected, How
they will interact, Their interfaces.
o Class design: The various features of classes.
o User interface design:

32
 o Algorithm design: The design of computational mechanisms
o Protocol design: The design of communications protocol
9.2 Principles Leading to Good Design
Overall goals of good design:
 Increasing profit/ reducing cost / increasing revenue
 Ensuring that we actually conform with the requirements
 Accelerating development
 Increasing qualities such as: Usability, Efficiency, Reliability, Maintainability,
Reusability.
a. Design Principle 1: Divide and conquer.
 Trying to deal with something big all at once is normally much harder than dealing with a
series of smaller things.
o Separate people can work on each part
o An individual software engineer can specialize
o Each individual component is smaller, and therefore easier to understand
o Parts can be replaced or changed without having to replace or extensively change
other parts.
Ex: UI layer, Business Layer, Database Layer
 Ways of dividing a software system
o A distributed system is divided up into clients and servers
o A system is divided up into subsystems
o A subsystem can de divided up into one or more packages
o A package is divided up into classes
o A class is divided up into methods.
b. Design Principle 2: Increase Cohesion where possible
 A subsystem or module has high cohesion if it keeps together things that are related to
each other and keeps out other things.
o This makes the system as a whole easier to understand and change
o Type of cohesion: Functional, Layer, Communicational, Sequential, Procedural,
Temporal, Utility
o Increasing in Cohesion = Decreasing in Coupling.
 Functional Cohesion: This is achieved when all the code that computes a particular result
is kept together – and everything else is kept out
o When a module only performs a single computation, and returns a result, without
having side-effects.
o Benefits to the system: Easier to understand, More reusable, Easier to replace
o Modules that update a database, create a new file or interact with the user are not
functionally cohesive.
 Layer cohesion: All the facilities for providing or accessing a set of related services are
kept together, and everything else is kept out.

33
 o The layers should form a hierarchy: Higher layer can access services of lower layers.
Lower layers do not access higher layer (top layer -> bottom layer, go with adjacent
layers)
o The set of procedures through which layer provides its service is the application
programming interface (API)
o You can replace a layer without having any impact on the other layers
o You can replicate the API

 Communicational cohesion (OOP): All the modules or manipulate certain data are kept
together (e.g. in the same class) – and everything else is kept out
o A class would have good communicational cohesion
 If all the system’s facilities for storing and manipulating its data are contained in
this class
 If the class does not do anything other than manage its data
o Main advantage: When you need to make changes to the data, you find all the code in
one place.
 Sequential cohesion: Procedures, in which one procedure provides input to the next, are
kept together – and everything else is kept out
o You should achieve sequential cohesion, only once you have already achieved the
preceding types of cohesion.
A -> B -> C (dependency in execution flow)
 Procedural cohesion: Procedures that are used one after another are kept together
o Even if one does not necessarily provide input to the next
o Weaker than sequential cohesion

34
 Temporal Cohesion
o

35