Software Engineering with Objects (M363) Final Revision By Kuwait10

Prepared by Kuwait10
www.kuwait10.net
Jan 12, 2014

M363
Software Engineering with
Objects
(Fianal Rivision– 1st Semester 2013/2014)

Contents
Unit 1 (Approaches to Software Development)...................................................................................... 2
Unit 2 (Requirements Concepts) .......................................................................................................... 8
Unit 3 (From Domain Modelling to Requirements Analysis) .................................................................. 11
Unit 5 (Classes and Associations)........................................................................................................ 17
Unit 6 (Interactions) .......................................................................................................................... 25
Unit 7 (States and Activities) .............................................................................................................. 35
Unit 9 (From Model to Implementation) ............................................................................................. 47
Unit 10 (Components, Patterns and Architecture)................................................................................ 52
Unit 11 (Product Quality: Metrics, Verification, Validation, Testing) ....................................................... 57
Unit 13 (Process Quality Management, Human Resources, Quality Assurance) ....................................... 66
Unit 14 (Human Factors and Professional Issues) ................................................................................. 72
Quick Review ................................................................................................................................... 74
Study Plan........................................................................................................................................ 77

Note that:
All SAQs and Exercises in each unit are required.

Unit 1 (Approaches to Software Development)
Software
Software Engineering
System 
System Boundary 
Systems Environment
Domain 

A collection of computer programs that provide instructions to tell computer
what to do.
Concerned with the theories, methods and tools, which needed to develop
the SW.
An assembly of components that connected together in an organized way.
A conceptual line that divides the system (scope of a system).
It distinguishes between the internal and external components of a system.
Things which are not part of the system, but which can either affect the
system or be affected by it.
A particular area of interest.

The characteristics of software that affect its development: 
 Malleability: software is easy to change.
 Complexity: Software is often complex.
 Size: It is likely that there will be more errors in a large piece of software.
The Characteristics of a good software system: 
 Useful: Meet users' needs.
 Usable: Have interface which is easy to use and user's friendly.
 Reliable: Errors are must be minimized.
 Flexible: Software is easy to change as times goes.
 Available: Available in the target environment.
Maintainability and legacy system:
 A software system should be both available, and flexible.
 In order to be maintainable, a software system should be written and documented in such a way
that changes can readily be made.
 Maintainability is more about how the software system came into being rather than Its basic
characteristics .
 Legacy systems (are lacking in flexibility): 
o Large and critical to the business.
o Have been changed a number of times.
o Often difficult to understand because of either a lack of documentation or a lack of
experience.
o Difficult to maintain because of the above factors. 
Divide and conquer:
 Since the computing technology increased, the need to build large and complex System is
increased. The only way till how to reduce size complexity is modularization.
 Modularization:
Decompose system to a smaller sub-system with separate boundaries (modules). 
 Examples of modules are:
o Whole programs or applications.
o Software libraries.
o Classes.
 There are two forms of decomposition: 
o Partitions: independent modules, which are easy to use.
o Projection: dependent modules, common elements between modules.
~2~

Partitions

Projection

Coupling and cohesion:
 A component depends on another if a change to one requires a change to another.
 Another important issue is not only the nature of dependency but also the number of
dependencies.





Coupling 
The degree of interdependence among
different modules.
A good software is loosely coupled system.
class A is coupled to the class B if any of the
following applies:
o A inherits from B.
o A has an attribute of class B.
o A has a method that uses an
instance of class B as an input or
output argument.
o A knows of a public attribute of
class B.





Cohesion 
How closely the activities within a single
module are related to each other.
A highly cohesion module performs one
task.
Low coupling and high cohesive are
competing. A developer should try to
achieve the best balance between them.

Architecture and components:
 The structure of the items that make up a complete software system.
 It includes:
o The responsibilities for these items.
o Their interconnections.
o The appropriate technology.
 We have used the term item intentionally in our definition of system architecture.
 In this course, we shall use the term component (could be a module or class with certain
properties).
An introduction to software development:
 Software development as an engineering activity.
 Software development is a human activity that involves the activities :
o Implementation.
o Analysis.
o Testing .
o Design.
~3~

There





are some common characteristics between software development and engineering:
Concerned with meeting a clear set of requirements.
Use a defined process with clear activities.
Regard validation and verification.
Make sensible use of tools and standards.

The role of development processes:
 Each activity has its input and produces one or more outputs.
 The sequence in which software development activities are carried out is called a life cycle. 
 This has three key elements:
o Methods (describe the technical activities).
o Tools (allow computer support for the methods).
o Procedures (holds the methods and tools together).
 We should distinguish between a customer and a user.
 Customer: someone who pays for a software system.
 Users: people who use it on a day-to-day basis.
Main activities in Software Development Process (Life Cycle): 
(1)
Analysis

(2)

(3)
Main Activities
Design
Implementation

(4)

(5)

Testing

Maintenance

(6)

(7)

Quality
Project
management management

1. Analysis:
a. Requirements elicitation.
b. Requirement specification.
2. Design: how will you solve the problem?
3. Implementation: convert the design to a programming code.
4. Testing: you apply what you have done, so that you can determine whether or
* The previous four stages are the basic ones.
5. Maintenance: allows system to evolve within time in order to:
a. Correct errors.
b. Adapt SW to a changing environment.
c. Introduce enhancements.
d. Improve SW in anticipation of future changes.
6. Quality management: ensure that the characteristic of good SW is achieved:
a. Reliable.
b. Flexible.
c. Usable.
d. Available.
7. Project management: is concerned with controlling the cost of developing such systems.
Project notebook:
A record of your notes, thoughts, drawings, ideas and decisions as you work on a project.
Glossary:
A document that cross- references the different words that are to be used on the project, and explains
how they interrelate
~4~

The models of SW development:
(1)
Waterfall Model 
It is the classic model where the
five activities (analysis, design,
implementation, testing, and
maintenance) are arranged into a
single sequence.
waterfall model has not proven
satisfactory in practice because:
 A working version of the
software system will not
be available until late in
the testing activity.
 Errors will be detected in
testing activity.
 Real projects rarely
follow a purely
sequential life cycle.

(2)
Iteration Model 
In which a developer has to
iterate around one or more of
the activities in a life cycle.

(3)
Incremental Development 
Here the idea is to divide the
system into a number of
independent or reasonably
independent "chunks".

An advantage of such model is
that iteration allows a group
of people, usually developers, to
perform a review of an activity or
the outputs from that activity.

The process begins by developing
one chunk (the core) and adding
successive increments to it over
time.
Incremental development is a
way of dealing with the
complexity of requirements, and
is analogous to the
modularization.

Iterative and incremental methods have been widely adopted in
software development.



A prototype is not a completed working version of the software.
Prototype can take several forms: 
o Could be a paper-based model.
o A mock-up of the human–computer interface.
o A working version of a subset of the functions required.
o An existing piece of software that has some relevance to the users’ needs.



Model Driven Architecture: MDA defines an approach whereby business-oriented decisions and
specifications can be separated from implementation and platform decisions.
The idea is to distinguish between platform-independent models (PIMs).




Agile development: is an umbrella term used to describe a variety of (agile) methods that
encourage continual realignment of development goals with the needs and expectations of the
customer.

Risks affecting large projects:
 If the size of a project is increased, errors are also increased.
 In large projects, the number of team members is also large and this may lead to the following risks:
o Effective communication becomes more difficult.
o There are also risks when developers have little or no experience of the problem domain.

~5~

Dealing with risks:
 Risk assessment is an important feature of software development.
 There are four steps that are repeated with each iteration of the spiral: 
1. Determine the objectives, the alternatives and their constraints.
2. Evaluate the alternatives, identify and resolve the associated risks.
3. Develop and verify a (partial) solution or product.
4. Review that solution and plan the activities for the next iteration.

Traceability:
 It must be possible to trace the history of each requirement from its origin in the problem domain,
through the various intermediate activities, so that it is possible to reconstruct the significant
events that led to the final, operational software system.
 This ability, to trace the history of each requirement, is known as traceability.


When you write down what you know about a problem, it helps to clarify your
understanding of that problem. Furthermore, writing and drawing helps you to explore the
problem and the potential solutions.

Modeling:
 Modeling: is a way of thinking about things and ideas in the "real world".
 A model, in terms of software development, is an abstract representation of a
specification, a design or a system, from a particular point of view. 
 In Software development, models are:
o A way of understanding the problems involved
o An aid to communicate especially between developers.
o A component of the methods used in development activities.
 A modeling language is based on diagrams and their construction, meaning and use.
What are the required characteristics of a standard modeling language?
1. Expressive.
3. Unambiguous.
5. Supported by suitable
2. Easy to use.
4. Widely used.
tools.


There are two rules within a diagram based modeling language:
o Syntax: determine what diagrams exist and what symbols are used for.
o Semantic: what these symbols mean.

~6~



The Unified Modeling Language (UML): is a standard modeling language, which is
diagrammatic, but also allowing developers to add text, and is easy to use, efficiently
expressive unambiguous and widely used, there are tools to support UML.



Models illustrate points of view: 
o Static model: describes objects and their relationship.
o Dynamic model: describes the behavior of SW over time.

Views in UML:
 In a given model, there are a number of distinct elements such as classes, use cases,
associations and so on.
 In UML, an element is an atomic constituent of a model. Classes and associations are the model
elements to be found in class diagrams.
 A diagram is a graphical presentation of a collection of model elements.
Case Tools:
 Computer-aided software engineering (CASE) tools were created to support the professional
software engineer in the complex task.
 Developers use a CASE tool in order to:
o Coordinate access to the different models of the problem.
o Help with the collaboration between team members.
o Store multiple versions of the different models.
o Check the consistency and integrity of diagrams and models.
o Generate project reports and other documents.
CASE tools examples:
 Process management tools.
 Project management tools.
 Risk analysis tools.
 Requirements management tools.
 Metric tools.
 Modeling tools.
 Programming tools.
 Interface design tools.
 Test management tools.

~7~

Unit 2 (Requirements Concepts)
Requirements: The functions and qualities we want of a product.
Requirements Engineering: The process of reaching an agreed set of requirements.
Stakeholders of the system: Developers; users, and clients. 
Software products problems usually resulted from:
 Lack of understanding of the requirements.
 Lack of clear agreement.
Requirements need to be: 
 Consistent.
 Verifiable.
 Independent of design.





Necessary and traceable.
Non-ambiguous and realistic.
Complete.

A requirement has to be traceable, realistic, and design independent.
Scenario: Specific sequence of activities that might occur when a system is used. 
The requirements engineering process:
(1)
(2)
The inputs of a requirements
The outputs of a requirements
engineering process are:
engineering process are:
 The information from
 The main output of a
which the requirements
requirements
can be derived such as
engineering process is
the stakeholders needs.
the contract.
 Other inputs come from
 The requirements
existing knowledge of the
document and the
domain and associated
models of what the
regulations.
system is intended to do
Examples:
 Stakeholder needs.
 Domain information.
 Existing documentation.
 Regulations.
 Organizational standards.

(3)
Activities of requirement
engineering process:
 Requirements elicitation.
 Requirements analysis
and negotiation.
 Requirements
documentation.
 Requirements validation.

Techniques for elicitation:
 Interviewing.
 Brainstorming.
 Focus groups.
 Team meetings.
Modeling techniques:
 Activity diagrams.
 Use cases.

What is the difference between requirements "elicitation" and requirements "analysis"?
 Elicitation is the process of capturing requirements from the users.
 Analysis involves identifying what kind of requirement each one is.
The activity where requirements are categorized and prioritized, and examined for their properties of
consistency, completeness and non-ambiguity is called:
Analysis and negotiation.

~8~

Types of requirements:
Functional Requirements (FR) 
Describes an action that the product must take if
it is to carry out the work it is intended to do.
Functional requirements are:
 Specifications of the product’s
functionality.
 Actions that the product must take (check,
calculate, or record).
 Derived from the fundamental purpose of
the product.
 Not a quality.

Non-Functional Requirements (NFR) 
A requirement about a quality that the product
must have (or speed or security).
Examples of NFR:
 X must validate the user’s identity and
password within 3 seconds.
 X must be usable by users with limited
dexterity.
 X must operate in arctic climates.
 X must work fast, secure, etc.

NFR Types: 
Types of functional requirements: 
1. Look-and-feel requirements.
The product shall use only two colors.
 Business requirement (tasks).
2. Usability requirements.
 Technical solution requirements.
How easy to learn is the software and how easy
to use is it.
Example of functional requirements:
3. Performance requirements.
 X must check a user’s identity (Functional,
Speed, capacity, accuracy, and reliability.
business requirement).
4. Operational requirements.
 X must check a user’s password (Functional,
"The product shall be usable at altitudes up to
business requirement).
1500 m, in icy and wet conditions".
 X must produce a statement of the user’s
5. Maintainability and portability
account (Functional, business
requirements.
requirement).
"The product shall be portable to all of the
 X must employ the company’s proprietary
operating systems".
password-maintenance system (Functional,
6. Cultural and political requirements.
technical solution requirement).
The language used in the interface should be
formal.
The needed steps to eliciting functional
7. Legal requirements.
requirements are as follows:
8. Security requirements.
 Understand the domain, determining the
Security covers confidentiality, integrity and
business processes.
availability (CIA).
 Determine the scope of the new system.
In a distributed computing system, security
 Draw up a set of use cases.
becomes a major issue (Passive interception or
 Describe each use case by one or more
active).
scenarios.
Security problems that arise with a distributed
 Work through each step of each scenario.
system are that:
 Search out and remove ambiguity.
The communication medium is insecure.
Communications will pass through many thirdparty systems.
Intruders: Hackers, competitors and
fraudsters.
Threats and attacks against assets:
 Disclosure of confidential information.
 Modification (loss of integrity).
 Denial of use or service.
 Repudiation.
~9~

Fit Criteria:
 A fit criterion is a precise and testable statement of a requirement. 
 The process of attaching a fit criterion to a requirement helps to clarify the requirement.
 The parties that need fit criteria are developers, testers, and clients.
A Fit Criterion For A Functional Requirement
Specifies the completion of the function of the
product. 
Examples:

A Fit Criterion For A Non-Functional Requirement
Specifies a value on a particular scale of
measurement. 
Examples:

If FR is:
"Send an email to the student after a marked TMA
has been uploaded by the tutor".
Then the fit-criteria might be:
An email should indeed be sent to the student.

If NFR is:
"The credit card number should be accepted
securely".
The credit card number should be revealed to a
third party in less than 0.0001% of cases.

If FR is:
"The system shall accept a credit card number
from a client".
A valid credit card number has been stored in the
system.

If NFR is written as:
"The credit card number should be accepted within
five seconds".
Then this statement contains its own fit criterion
(quantity time).

Representing the requirements:
Why is it important that requirements be documented? 
1. Requirements documents are an aide-memoire to record decisions agreed among the system’s
stakeholders.
2. They are the starting point from which the system is designed and built, and are the basis for
the validation of the system.
3. Requirements documents as a contract with the client.



Documentation may take many forms.
The following information should be recorded for each requirement:
o Requirement number.
o Events/use cases.
o Description.
o Rationale (Why it is important or necessary).
o Source.
o Fit criteria (acceptance criteria, written in a quantified manner).
o Dependencies.
o Conflicts.
o History.

~10~

Unit 3 (From Domain Modelling to Requirements Analysis)
The main concepts in a business domain are: 
1. Business resources (people, products).
2. Business processes (activities).
3. Business rules that constrain the processes.
Business Rules:
 There is a clear distinction between the business processes and the constraints:
o Renting a car (processes).
o The car allocated is the lowest mileage car (rule).
 Properties of business rules representation:
o Be correctly represented.
o Be represented independently of other models.
o Support verification and validation.
o Traceability should be possible.
 Business Rules representation techniques:
o Using natural language (should be well defined and structured).
o Using UML and OCL: Object Constraint Language, which is a formal language, used to
represent constraints in UML.
o You could not use UML as it to represent business rules because there is no UML notation to
model business rules explicitly and independently



Verification: The set of activities that ensure that the rules are correctly modeled.
Validation: Ensures that they are the most appropriate rules for the business.

Business Processes:
 Business processes define what is done, by whom, and in what order.
 The main reason we look at business processes is to get an understanding of what a business does.
 Representing Business Processes:
o Activity diagrams are used as the technique for modelling business processes. 
o An activity diagram shows a process as a set of activities, showing their sequences. 
o Activity diagram can be an aid:
1. Help investigate the workflow (Workflow is a sequence of activities).
2. Help in understanding the basic behavior of a system.
3. Can be used to model concurrent systems.
4. Can record scenarios of use cases.
Elements and symbols of activity diagram: 
Activities

Decision Node

Start node

Merge Node

End node

Guard

Transition
Swimlane

Synchronization bar
(Fork/Join)

~11~

[condition]

Activity diagram examples: 
Preparing a Cup of Coffee with milk:

Using decision node:

What are the business process and business rules
in the library system?

Borrowing and returning books to the library:

Draw the activity diagram of issuing a book in the
above library system?
Business processes:
Find book on a shelf; wait in the queue; issue a
book, and return a book.
Business rules:
 There is a limit to the number of books a
member can take out.
 A loan is for a period that is normally two
weeks.

~12~

Use cases:
 A use case is something that an actor (user) needs to do with the help of a software system.
 Use cases are a way of capturing functional requirements. 
 The main purpose of use cases is to help with the elicitation and modelling of requirements.




Use case analysis is related to an activity called user-centered design, which is part of the
discipline of human–computer interaction (HCI).
User-centered design focuses on people, their work, and their environment.
User-centered design and use cases are more concerned with external functionality.

The main elements in use case diagram: 
Actors

Relationships
(Association)

Use cases

Note symbol
Used to clarify an
aspect or a task.
Can be used with any
UML diagram.

Use cases examples:
A use case diagram for a hotel chain:

A use case diagram for a hotel chain, showing the
system boundary:

~13~

Each use case description should contain the following parts:
 Use case identifier and name.
 Initiator: name of the actor who initiates the process.
 Precondition: a condition that must hold before this use case can be carried out. 
 Post-condition: a condition that must hold after the use case has been completed. 
 Main Scenario: a single sequence of steps that describe the main success scenario.
 Goal: a short description of the goal.
There are two scenarios for making reservation in a hotel:
1. Main scenario:
The guest wants to reserve a double room at the Ritz Hotel for 14 July. A double room is available
for that date, and so the system makes a reservation for the guest.
2. Unsuccessful scenario:
The guest wants to reserve a single room at the Savoy Hotel for the first week of August.
There is no single room that is free for seven days in August, but there is one room available for four days
and another of the same type for the following three days. The system presents that option to the guest,
who rejects it.
What is the relationship between a use case and a scenario? 
A use case is a related set of scenarios. Scenarios are instances of a use case.
Conditions example:
Precondition
There must be a reservation for the guest, there
must be at least one room available, and the guest
must be able to pay for the room.

Post-condition
The guest will have been allocated to a room for
the period identified in the reservation, the room
will have been identified as being in use for a
specific period, a bill will have been opened for
the duration of the stay, and a key will have
been issued.

A textual description of a use case in the hotel domain:

~14~

Relationship between actors (generalization/specialization):

Receptionist and guest as specializations of reserver.
Relationship between use cases:
Inclusion 
Two or more use cases have an overlapping
(common) area of functionality.

In UML, we use «include» stereotype.




Extension 
A use case has a main success scenario but
also alternative scenarios which demand a
variation on the original use case.
In UML, we use «extend» stereotype.

A stereotype is a way of attaching extra classifications to a model. 
A UML stereotype name is always enclosed between double angle brackets «...». 

A use case diagram for a lending library:

~15~

Including the log on use case in the hotel domain:

Factors that are used to determine priority of a use case:
1. Risks include complexity of requirements.
2. Coverage requires that the initial set of use cases should give an overall view of the system.
3. Criticality is measured in terms of business value.



The walkthrough technique can be used to specify acceptance tests.
Acceptance testing consists of a series of tests carried out by the customer in conjunction with the
developer, which act as a final check.

Problems with use cases:
 The focus may end up being top-down and function-oriented.
 Difficulties in deciding the size and scope of each use case.
 A danger of missing some of the requirements.
Needed tasks to prepare use cases for large project:
 Define the context for the model by identifying the actors.
 Analyze the behavior that each actor.
 Identify the common behavior («include» and «extend»).
 Draw a model that shows the use cases, the actors and the relationships between them.
 Annotate the use case.
Prototyping for and with the user:
 A prototype is not intended to be a complete working version of the software.
 One of the main uses of prototyping is to help with the design of the user interface.
What is the purpose of a prototype?
It is a way to improve the analysis and identification of requirements.

~16~

Unit 5 (Classes and Associations)
Class and object models in UML: 
A class model is a static model that describes the objects and the relationships that are
needed between them.
The search for classes:
 The first step in building a class model is to identify objects.
 We look first for objects because objects are instances of the classes.
The following categories are useful sources of relevant objects: 
1. Tangible objects (rooms, books, and vehicles).
2. Roles (employees, guests, and members).
3. Events (room reservations, vehicle registrations, and transactions).
4. Organizational units (departments, and teams).
To identify the classes:
 A list of nouns makes an excellent starting point.
 In addition, we should pay particular attention to events.
Classes and properties:
 Attributes: properties of objects.
 Associations: properties represent relationship between classes.
Classes and objects:
 An object stands for something real in a domain expert’s world (such as a specific customer).
 A class describes all possible objects of that type, defining what the objects have in
common.
Object Diagrams
An object diagram is a visual representation of an
object model, showing a snapshot of the system at
some point in time.

Class Diagrams
A class diagram represents what all possible
instances of the class have in common, rather than
the particular values of any given instance.

~17~

Associations:
Associations are relationships between two types. 

When explaining association, we need to understand the following:
1. Multiplicity.
2. Association names and role names.
3. Assumptions about meaning.
4. Navigation expressions.
5. Association between pair of classes.
6. Association between a class and itself.
Multiplicity

How many of one sort of thing can
be related to another sort of
thing. 
How many instances (objects) of
one class can be linked with a
single instance (object) of a class.
Sometimes, labels are been added
to the ends of some of the
associations. These labels are role
names.

Association
names and
role names
Assumptions
about
meaning

Placing association name in the
middle.
As with all parts of the notation, it
is important to give a symbol
precisely the meaning that is
defined.

~18~

Navigation
expressions

Several
associations
between a
pair of
classes

Associations
between a
class and
itself

The term navigation expression is part of OCL, it provides a way of naming another object
or its attributes relative to a starting object, by referring to intermediate role names.
The general structure:
Object_name.attribute_name
Object_name.role_name.attribute
Example:
jack.currentRoom.floor
There can be more than one
association between any two
classes.

Recursive association represents
an association between a class
and itself. 

Why a class model is not sufficient to describe a system?
 Reason: It is a static model that describes the elements of a system (classes) and their relationships
(associations), and it does not describe behavior over time.
 You need a dynamic model to do so.
Navigation:
 Navigability: Possibility to reach objects in one class from objects in an associated class.
 Navigability specifies the direction of potential messages between objects of related classes.

Qualified associations:
 Suppose that one of your classes has an attribute that acts as a unique identifier.
 In UML, you can model this using a qualified association.
 A qualified association is an association at one end of which there is a qualifier. 

~19~

Association class (Attributes on associations):

* Each link from an instance of Store to an instance of Item has the attributes quantityInStore and price
Derived associations:
 To avoid association redundancy, UML provides derived associations. 
 By preceding a role name with a "/", you indicate that an association is derivable.

* The family has children. Then by using the age attribute, you could figure out those children that are
teenagers, and children who are still living at home.

~20~

Relationship between classes:
has- a 
Aggregation

Describes a whole–part
relationship, where a whole class
is composed of part class.

In UML, you simply add an open
diamond to the end of the
association to indicate the class
that is to act as the whole.

Composition

It is a stronger form of
aggregation.
It describes a relationship where
composed objects are part of at
most one composing object.
In UML, a solid black diamond is
used to represent composition.

is-a 
Inheritance
(Generalization
and Specialization)
Generalization/specialization is a
relationship between two types.
If type B specializes type A, an
instance of B has all the features
of an instance of A but in
addition has features special to
type B.
In this case, B is a specialization
of A, and A is a generalization of
B.
Generalization/specialization
represent inheritance
relationship between two
classes.






A sub-class inherits all features from super-class and it may have additional ones.
Also some operations may be overridden in the subclass:
The operation have the same name and parameter as the one in the superclass, but it differs in the
implementation.
This case is known as overriding.

~21~

Exercise:
Use the below class diagram to answer the below questions:

1. How many classes are there, Nominate them.
2. What kind of relationship are there in the diagram?
3. Represent in your language the above class diagram?
Solution:
1. There are 5 classes: Person, Adult, Child, TaxOffice and School.
2. Relationship are:
 Inheritance between Person (Super class); and Adult & Child as sub-classes
 Has-a relationship: where a school may has zero or more children, TaxOffice has zero or more
adults.
3. A person could be an adult or a child. Where children attend a school, and that adults are allocated to
a tax office.

Exercise:
Draw the class diagram for the below paragraph:
"A document has several parts. Photo is a part; picture is a part; and text is another part. Text is either a
paragraph or a sub -document."
Solution:
Obtain classes (nouns): document, photo, picture, text, paragraph, and sub-document
Keys that represent relationship: has-a: composition; is-a: inheritance.

Constraints on classes:
 A constraint can be expressed in a natural language, such as English, or we may use a special
notation defined by UML.
 Invariants: Boolean expressions that always remain true {age >18}.
 Some common kinds of constraint are:
o Constraints on the values of attributes.
o Constraints on associations.
o Uniqueness constraints (which can sometimes be converted to qualified associations).
o Finding invariants by considering loops in associations.

~22~







You can use English (most common) to write constraints in curly brackets or OCL Object Constraint
Language.
Constraints are also passed on from superclass to subclass, which introduces a dependency
in a model.

Dependency tells one class depends on another in some way: a change in one class affects
dependent classes.
Several ways of which class A depends on class B:
o A uses instance of B that is passed on parameter to some operation.
o A creates new instance of B.
o A is subclass of B.

Constraints across association:
Constrains could be added to association either formally or informally.
Informal Way
Formal Way
Attaching a note explaining the constraint.
Using special notation in curly brackets:
 {subset}: an instance is a subset of another
(figure 27)
 {xor}: notation is used to specify that an
instance of the class must participate in
exactly one of the associations.

~23~

Constraints on attributes:
 In referring to objects you may use:
o self.attribute
o self.role_name.attribute

Finding invariants by considering loops in associations:
 Associations in a class model can form loops.
 Some loops may be totally independent or hidden.
 In other loops, a restriction that should be expressed as a constraint.
 Example: A train must be associated with two employees (a driver & a guard).




The problem: this model could not reflect the fact given employee can't be both the driver and the
guard for the particular train.
We can modify this and add it as a constraint as (self.driver <> self.guard):

~24~

Unit 6 (Interactions)
Design by contract (DbC):
 The process of developing software based on contract between objects.
 A form of contract exists when an object sends a message to another object.
 The sender (client) requests service from receiver (supplier).


The contract is expressed by:
o Precondition: requiring something from the client object.
o Post-condition: requiring something from the supplier object.



Benefits from identifying roles in terms of clients and suppliers are:
o Enabling designers to specify the responsibilities of objects.
o Allowing clearer software to be built.
o Leading to greater confidence in the correctness of the software.

Assertions:
Assertions are statements that are either true or false, which involve preconditions, postconditions, and invariants that are used to placing constraints on the relationship between
classes.
How can Design by contract help to improve quality?
 DbC complements many of the other tools that the software engineer uses to improve quality.
 These tools could be classified into:
o Static analysis tools: tools used to analyze code to detect defects before execution.
o Dynamic analysis tools: tools used to testing.
Critical Systems
 It is so important to build an error free system especially in what is known as a critical system.
 Critical Systems are software systems where failure may have catastrophic consequences such as:
o Loss of life (safety-critical systems).
o Loss of business (business-critical systems).
o Failure to meet significant objectives (mission-critical systems).


In developing critical systems, the developer will use:
o Formal methods.
o Analysis tools to make the systems as error-free as possible.
o Use Design by Contract (to trace the software from requirements through to code).

Contracts in real world:
In business, contracts are specifications of the obligations of, and benefits to, the parties involved in an
agreement.
The form of contract should be written as below:
1. A description of the task.
2. A set of constraints that are assumed to be true before you can start (pre-condition).
3. A set of constraints that must be true afterwards (post-condition).

~25~



Objects relate to one another in two basic ways:
o Associations (composition, aggregation).
o Generalizations (inheritance).

Contracting, subcontracting and inheritance:
 Subclass should respect all contracts agreed by superclass.
 The subclass must neither strengthen the precondition (make the precondition more restrictive),
nor weaken the post-condition (deliver less service).
Starting Dynamic Modelling:
 Dynamic modelling: Show how the objects interact by sending messages to implement the
required functionality of the software system.
 Interaction diagrams: Notations representing dynamic modeling that are used to help make and
record decisions relating to the class behavior
 There are two types of interaction diagrams:
o Sequence diagram.
o Communication diagram.
Interaction Diagram (represent dynamic modeling)
Diagram
Sequence Diagram
Communication Diagram
(Collaboration Diagram)
Definition
 It shows the flow of messages
 It shows the objects and their links.
from object to object, as time
 It shows the flow of messages as they
passes by.
pass along the links between objects.
 It is an object diagram with added
message sends.
Strengths
 It make the time relationship
 It make the interconnections between
clear.
objects clear.
Weaknesses
 It may not be easy to see
 Actual sequence of messages is difficult
overall patterns of message
to see, so a sequential numbering
flow.
system for messages is used.
Notes

An object cannot send a message to
another object unless it has a
reference to it.
This means either:
 There is a link from the sender
to the receiver (associations
between classes).
 Or the sender has obtained a
reference to the receiver
(answer to an earlier message,
or a message argument).

The main elements in sequence diagram:
Object
The message




Every message has a multi-stage
number (1.1).
The numbers specify the sequencing.

Lifeline

theRitz : Hotel

~26~

Activation

Interaction diagrams example:
Sequence
Diagram

Communication
Diagram

Class 
Guest
Hotel
Room

Operations 
checkIn(g : Guest)
setRoom(r : Room)
identifyGuest(s : String)
findAFreeRoom()
SetOccupant(g : Guest)

There are two main differences between communication diagrams and sequence diagrams:
 A communication diagram shows in one place all the links of interest between objects, whereas a
sequence diagram does not.
 The time ordering of messages is clear in a sequence diagram, but in a communication diagram,
numbering is needed to show the time ordering of messages.

~27~

Message results and parameterized interactions:
 In each use cases there may be more than one scenario (the main one & the other alternatives).
 The sequence diagram shows one of these cases.
 To model interaction diagram for a range of different concrete scenarios you may:
o Use prototypical interaction style (model more than one scenario in the same diagram by
using parameters).
o Use conditional behavior on an interaction diagram
o Construct separate unconditional diagrams for a range of different concrete classes.
 The advantage of constructing only unconditional diagrams is that each on its own is
easier to understand.
 The disadvantages are that you have to draw more diagrams.
In object oriented, there are two types of methods:
1. Accessor methods: that does not change state of an object (getters).
2. Mutator methods: that change state of an object such (setters).
Creation and deletion:
Creating an destroying an object in
a sequence diagram:

Object creation in
a communication diagram:

* Java provides garbage collection to remove
references that are not used for a time.
Levels of detail:
Problems of adding more details to interaction diagram:
 Can easily get details wrong.
 The diagram may get too big and, and difficult to understand.
We can summaries the uses of interaction diagram as follows:
 They can show how a use case is turned into object interactions.
 How a class provides an operation.
 How a component can be used.

~28~

Design Decisions:
1. Managing associations:
 By examining the Interaction diagrams:
o You can also see the overall pattern of message traffic.
o You can collect information on the directions of the messages.
 The direction is an important to determine which class holds which operations.
 The direction in which an association is used is called its navigability.
 The direction in which an association is navigated is significant when implementing the association.
o For example, if no Guest object sends messages to any Room object, there is no need to
implement the association in this direction.
 Each navigability arrow on an association identifies a dependency.
For example: hotel depends on both Room and Guest. In contrast, Guest depends on neither Hotel
nor Room:

2. Link manipulation:
 We need to decide how associations are to be represented and write the appropriate code.
 The actual implementation of links is best encapsulated within methods that hide the chosen
representation.
 Use association role names to name the links-manipulated methods, especially if association has a
multiplicity > 1.
 You have to consider link direction when implementing methods as follows:
o In the case of a unidirectional association, the class from which links will be navigated
should be responsible for those links.
o In the case of a bidirectional association, making the class at one end of the association
responsible for managing the links in both directions.

~29~

Manipulation association as follows:
Favourite Association
 It is Unidirectional so only represent (favourite) association based on
one direction (in source class).
 In this case in Guest class with a method named: setFavourite(Room).
Occupant It is bidirectional so methods should be implemented in both classes
accommodation
using role names as follows:
association
 In Guest class: setAccommodation(Room).
 In Room class: setOccupant(Guest).
Hotel–Guest
 It is marked as unidirectional, we have provided methods addGuest and
association
removeGuest only at the Hotel.
Forks or cascade:
 During an interaction diagram if an object needs to send a message to another object where no
direct associations found, either you implements this as forks or as cascades.
o A fork centralizes control in the sender.
o Whereas a cascade delegates responsibility to another object.

Fork: 

Cascade: 

Company can send a message to Job to get back
person id, then send person id to Person class to
get their ages.
In this pattern, the company contacts two classes
directly, using the value returned from first as
parameter sent to second.

Company send getAgeofPerson() to Job class,
where Job class send another message getAge() to
Person class.
So there is no direct interaction between Company
and Person.
~30~

How to choose which to use Fork or cascade pattern?
 It is better to use guidelines of Law of Demeter, which tends to favor cascades.
 The goal of it is to reduce coupling which in turn simplify implementation.


The Law of Demeter allows an object to send messages to: 
o Any objects communicated as parameters of the current method.
o Any new objects that the object has created in the current method.
o Any objects to which the object has direct links (neighbors).
o Itself.

The Law of Demeter states that a method, say m, in a class A should not refer to another class, say B,
unless B is the class of: 
 An instance variable used in the method m.
 A parameter to th e method m.

Summary:
To move toward design and using interaction diagram you have to do the following:
1. Start from use cases: take each scenario, in cooperation with class model to determine methods of
each class and scenario, which lead you to build sequence diagram.
2. A most important point is where the initial message come from, usually because we start with use
cases, we assume that an interface will be used to initiate first message.

3. The aim of interaction diagram is to determine exactly all operations and its classes, you can use
association with role names found in class model, and manipulate them as methods in classes
based on association direction.

~31~

Exercise:
This figure shows a class model for a Company.
For each association, decide which end should manage the association, and what methods must be
defined.

Solution:
Company: addDepatment(department d), removeDepatment(department d).
Department: addEmployee(Employee e), removeEmployee(Employee e).
Employee: setDepartment(Department d).
Exercise:
This figure shows a fragment of a hotel system, extended to give each Guest a Bill.
Suppose we wish to implement a use case printBill(Guest jack).
It has been decided that the user interface will send the initial message printBill(jack) to the Hotel.
1. Draw two sequence diagrams, showing fork and cascade solutions.
2. Which of your solutions would the Law of Demeter exclude, and why?

Solution:
1a. Fork:

1b. Cascade:

2. The guidelines identified within the Law of Demeter would exclude the fork solution, because it
involves the Hotel sending the message print( ) to the Bill.
The Bill is not an object known to the Hotel through a permanent association.
~32~

Exercise:
Draw a communication diagram that is equivalent to the following sequence diagram:

Solution:

~33~

Exercise:
This figure shows a class model for lending books where there is a requirement to record both past and
current loans.
Represent a prototypical in interaction for the borrowing of a book.
Draw both a sequence diagram and a communication diagram that sends the message borrow(b) to an
instance of LibraryMember from aUserInterface, where b is a reference to the object representing the
book that the library member m wants to borrow.

Solution:
Our aim for each interaction diagram is to show that the corresponding post-condition has been met.

~34~

Unit 7 (States and Activities)
1. Conditional message sends in sequence diagrams:
 In sequence and communication diagrams, you can use guards to show conditions.
 Guards are conditions (Boolean expressions that is either true or false) insert in square brackets
[condition].
 Examplex:
Using one conditional message:

o [room available] = Guard.
o r = Reference to the room object found by the findAFreeRoom() message.
Using more than one conditional message:

o In sequence diagram, we can use a branch to the lifeline of an object.

~35~

2. Iterative message sends in sequence diagrams:
 UML uses the * notation for a repeated message send.
 The * notation attached to a guard, generating an iteration clause such as: *[i := 1..10] to send
one message ten times.
 Example:
Using iteration notation:



Using iteration with parameter:
A company might print a year’s reports by sending to an instance of a Department class the
message printReportForMonth(i), using an iteration clause*[i := 1..12]; so it will be:
*[i := 1..12] printReportForMonth(i).

3. Concurrency:
 In concurrence systems, an object can do more than one thing at the same time.
 There are two cases for an object; either:
o Active (an object that owns a thread of control)
o Passive (it sends a message as a result of receiving it, so it waits a message to arrive).
 Active objects and active classes are shown in UML by a thick black border.
 Example:

There are two ways to synchronize two communicating active objects:
Synchronous
Asynchronous
Sender blocks until receiver has finished
The sender sends a message, and continue
processing.
regardless of what the receiver is doing.
(Return)

~36~

4. Timing:
 Sometimes, the time taken to send, process or return messages is important.
 We can identify timing constraints as Boolean expressions on a sequence or communication
diagram using two distinct properties defined in UML:
o The receiveTime.
o The sendTime.

Exercise:
This figure shows part of a lift controlled through a graphical user interface (GUI).
Add timing constraints to show that:
o A mouseUp must occur within 1 ms of a mouseDown.
o Two successive mouseDown events must be separated by at least 1 s.
o The transmission time of the message from the button to the lift must be less than 500.

Solution:
{b.sendTime – a.sendTime < 1 ms}
{d.sendTime – a.sendTime >= 1 s}
{d.sendTime – a.sendTime >= 1 s}

~37~

Design issues:
1. Interface:
 It is better to use an object identifier as a parameter:
checkIn(Jill)
checkIn(newResident : Guest)
 User interfaces should communicate with the business model entirely in terms of business
objects, and not via external names or identifiers.
 The need for the interface to do the mapping from external identifiers to objects may require
the business model to support extra queries, such as getAllGuests().

2. Preconditions:
 Use cases specify how the system changes by specifying a precondition and a post-condition.
o The precondition says what can be assumed about the initial state.
o The post-condition says what must be true afterwards.
 There are two strategies used in order to ensure that the precondition is true:
Defensive Programming
Design by Contract
 Requires that preconditions are always
 It is the responsibility of the sender of the
checked by the operation itself.
message to guarantee the precondition of
the operation.
 It’s the responsibility of receiver to check
precondition.
 The operation can therefore assume that
the precondition is true.
 Using if condition to ensure that
 If the sender of a message is faulty and
precondition is true.
does not check the preconditions in case
 Disadvantages:
of DbC, then the receiver will no longer
o Conditions are repeatedly checked in
guarantee the pos-tcondition.
both the client and the supplier.
o It create difficulties with when state
changes are made.

~38~

3. Strategies for implementing use cases:
 There are three strategies for choosing which objects in a software system are to receive messages
from the user interface:
One Central Class 
Actor Classes 
Use Cases as Classes 
Making the interface sends all The message should be sent to A new class is identified for
messages to a single object.
the software object
each use case.
corresponding to the realworld actor object who
There might be classes such as
initiated the operation. (Use
CheckerIn, and CheckerOut,
actors as classes)
each would have a method
with a name like "run".
Advantages
Minimizing the dependency of Clearer structure.
This strategy employs what
the user interface on the rules
are known as use case objects.
and concepts of the business
domain.
Working with use case objects
lets you change or even
There is good traceability from
replace the software to
use cases to code.
implement a given scenario.
Each use case can be
understood in isolation.
One central class becomes
overloaded with use cases.
Solution:
Divide the software system
into several packages.
Each package could still make
use of one class to respond to
messages from the interface.

Disadvantages
Traceability is more difficult
than one central class.
Limitation of reusability.
There is a further complication
when there are two actors
that can initiate an interaction.
It is more difficult than others
are. 

~39~

The large number of extra
classes that must be defined.
Many of the use case classes
can be very similar, resulting in
duplicated code.

Exercise:
Redraw the sequence diagram so that use case objects are used, according to the classes and operations
shown in the table.

Solution:

State Machines:
A State machine:
Amodel that shows how an object changes from state to state in response to events.
 Terms: 
o State: Represents situation in the life of an object (it is not an action).
o Event: Represents sending a message to object (it is not always change the state).
o Action: Represents object's reaction to an event (something an object does).
o Transition: Occurs as a response to an event, and cause change of state.
State Machine
Refers to the technique used to model
behavior of an object in terms of states and
transitions.

Statechart Diagram 
A graphical representation of a state machine
showing states, transitions and events that
captures life history of an object.
It contains:
Initial state.
Final state.

~40~

The main elements in statechart diagram:
States
Transition
(boxes with rounded (arrows between
corners)
states)

occupied

Events/Action

Initial/Final State

Avents (use blackslash):
accept(aGuest) /
vacateReoom()/
Actions:
setOccupant(aGuest)
removeOccupant()

Guard
[]

Example of statechart diagram:



Action consequence:
An action could have an action consequence: which is an ordered series of individual actions that
are associated with a particular event.
setOccupant(aGuest);
aGuest.setRoom(self)



Two objects of the same class respond differently to the same message, because it depends on the
values of its attributes.



Selftransition: Originates in one state and returns to the same state.



Guards:
o A Boolean condition that is applied to a transition.
o A guarded transition can only take place when the specified guard is true.
o Example (a full hotel or an empty hotel?):

~41~






Entry and exit events and actions:
o Entry event: Triggered every time an object enters a state.
o Exit event: Triggered every time an object leaves a state.
o In the case of a self-transition, both the entry and the exit events will occur.
The use of entry and exit events allows you to reduce the complexity of some state machines.
Example of using entry and exit events for a Room object:



An internal transition:
o A special transition that does not involve a change of state.
o Typically used to handle an interrupt where you want some action to take place that does
not affect the current state.
o It written inside the state.
o Example of an internal event:



The final state:
o Used to show the point where the object has finished processing and will be destroyed.
o Differences between final and initial state:
 There can be zero, one or more final states but at most one initial state.
 A final state can have several incoming transitions and no outgoing transitions
 An initial state has no incoming transitions and only one outgoing transition.



State machines have several benefits:
1. They are a means of elaborating the potential operations within a class.
2. They help to understand the behavior of an object over its lifetime.
3. They help to understand how an object must respond to events.
4. They are a means of ensuring correctness.

Variation of events and actions:
 Events are classified as:
o External events: those that involve a system and its actors (e.g. pressing of a button).
o Internal events: those that involve the objects within a system (e.g. exceptions).
 UML defines four different types of event: 
Call Event
Signal Event
Change Event
Time Event
Request to invoke a
An asynchronous
Occurs when a
The expiry of a
specific operation
signal, such as mouse
Boolean expression
specific deadline.
click.
becomes true after a
Entry and Exit event
change in value.
are both signal events.
Synchronous
Asynchronous
Asynchronous
Asynchronous

~42~



A simple telephone statechart diagram:

Action and activity:
 An object may be expected to do some work while it is in a certain state.
 UML provides the special do transition to identify what activity should be performed after any entry
actions.
do / activity
 Remember that the main reason for constructing a state machine is to show the response of an
object to external events rather than to show the internal processing that follows such events.
 A simple heater state machine:



Similarities and differences between statechart and activity diagram:
Similarities
Differences
They have a number of common model
There are some important differences between
elements, such as the use of an initial state.
actions and activities.
 An action is an executable atomic
computation that results in a change
of state, it cannot be interrupted by an
event
 An activity is a substructure, and can
lead to a number of actions.

~43~

Exercise:
Complete the following table based on this figure.

Solution:
Current state
Enrollment
Being Taught
Enrollment
Final Exams
Being Taught
Being Taught

Event
Term started
Classes end
canceled
closed
Student dropped and seminar size > 0
Student dropped and seminar size = 0

~44~

New State
Being Taught
Final Exam
Final state
Final state
Being Taught
Final state

Looking inside states:
There are two categories of states:
Simple State
A state that contains no substructure.

Composite State
Whereas a state that has other states nested
within it.

Packages:
 There are three main reasons for partitioning a software system:
o To manage size and complexity.
o To hide information.
o To make logical decomposition.
 A UML package is a much more general idea than a Java package.
 A package can be used to group almost anything we please (for example use cases can be grouped
into packages).








Each package defines a namespace.
Package must always have different names.
One package can be associated with another.
Package cannot have any associations or take part in any interactions.
However, a class in one package can have an association with a class in another package.
One package can contain other packages.
Package diagrams are designed for: 
 Organizing a large project into components.
 Depicting the overall structure of a system.
 Assisting testing.

Stereotypes:
 You need a way of allowing elements in different packages to see each other.
 UML allows you to mark individual elements of a package as:
o Public (+).
o Private (–)
o Protected (#).
o Package (~).
~45~





In UML, there are two stereotypes in which you may see other packages:
o <<import>>: When you import a package, all public elements of that package is visible.
o <<access>>: In this case also, all public elements of target package will be visible to source
package.
Example of using import between package:

Subsystems:
 A subsystem is a special kind of package that can be instantiated.
 A subsystem is a package of elements that are treated as a single unit.
 It is a solution to the common problem of wanting a package to take part in interactions.
 A structure of subsystem in UML:
o Specification elements such as use cases, constraints and the relationships between them.
o Operations needed to meet the specification.
o Elements of realization that are needed to implement the behavior defined by the
other groups (classes, and associations).
 Example:

Exercise:
A typical accounting system consists of three distinct concerns:
1. Accounts received.
2. Accounts payable.
3. Nominal or general ledger, which a company uses to reconcile income and expenditure.
Draw the accounts package to illustrate these different concerns.
Solution:

~46~

Unit 9 (From Model to Implementation)
Java offers three kinds of support for checking pre-and post-conditions:
 At compile time: Statements are rejected unless the supplier object supports it.
 At built-in error checking at runtime: Various kinds of error conditions (e.g. divide by zero).
 At Java’s assertion mechanism: A built-in mechanism for specifying conditions that it must be true
at a specific point in the code.
Assertions: 
 In general terms: Something that is either true or false.
 In DbC: Preconditions, post-conditions and invariants.
 In Java: Statements that evaluate to true or false which are used to check preconditions, and
post -conditions during execution.
Two main types of assertions in DbC:
 Pre-condition: What must be true at the method’s start.
 Post-condition: What must be true at the finish.
Translate assertions into code:
 True assertion must have no effect.
 False assertion indicates an error and must be treated as an error (by using assertion mechanism).
Assertion handling mechanism:
 A programming construct, which at runtime allows an assertion to be executed.
 When an assertion evaluates to false, the assertion mechanism will alert the user.
Implementing pre-conditions:
 Using assert statement before method body.
Implementing post-condition:
 Using assert statement, if it is simple post -condition.
 Using AssertionChecker inner class: in case method changes any of attribute values.
o In Java, it is legal to declare a class inside a method. These classes, called local inner classes.
o This inner class contains two methods that used to implement the pre-and post-conditions:
 boolean precondition();
assertCheck.precondition();
 boolean postcondition()
assertCheck.postcondition();
Executing an assertion using Java:
Example of using assert statement:
public BankAccount(int anAmount, int anOverdraftLimit) {
assert anAmount >= 0 && anOverdraftLimit >= 0; //precondition assertion
// code for the constructor goes here
assert getBalance() == anAmount &&
getOverdraftLimit() == anOverdraftLimit; // postconditon assertion
}
* The precondition constrains the values of the arguments of the constructor to be correct (initial
balance & overdraft limits).
* The post -condition characterizes what the initial state should be in terms of the values of the
arguments.
~47~

Assertions in the constructor:
 Class invariants are to be considered as part of both the pre-and the post-conditions.
 A constructor, just like methods, may have pre-and post-conditions.
 A major responsibility of the constructor is to create a valid object that satisfies its class invariant.
Exercise:
Implement post-condition of the deposit method which is written as follows:
public void deposit(int anAmount) {
// a method that credits the balance with 'anAmount'
assert anAmount > 0; // precondition
setBalance(getBalance() + anAmount);
// postcondition: check that new balance == old balance + anAmount
Solution:

}

When to use assertions?
 On describing the conditions under which software elements will and will not work (preconditions)
and the conditions that they will achieve (post-conditions)
 A precondition violation indicates a defect in the client.
 A post-condition violation indicates a defect in the supplier.
What does assertion mean in Java? 
In Java, an assertion is a statement of what must be true at a particular point in the execution of a
method.
In terms of design by contract, what does it mean: 
a. If a precondition assertion is false:
The client code has not met its responsibilities
b. If a post-condition assertion is false:
The supplier code has not met its responsibilities.
~48~

Controlling inheritance:
 Advantages of assertions:
o It can be used to apply the notion of a contract in the development of an object-oriented
system.
o It serve to document classes in terms of their contractual obligations.
o It serve to facilitate testing.
 A "client–supplier contract" exists between classes that are related to each other via association.
What is substitutability? 
 Substitutability happened between instances of two classes that are related in
generalization relationship (is-a, superclass & subclasses).
Substitutability illustrates that an instance of the more specific element can be used in place of the more
general element. 



Under the rules of the Java language, an instance of a subclass is presumed to be substitutable for
an instance of the superclass.
To be substitutable, the class and its subclasses must honor the same contracts. This means:
o Preconditions: should be the same, or demand less (weaken precondition).
o Post-conditions: should be the same, or deliver more (strengthen post-condition).

Inheritance and meaning:
 The subclass inherits all methods and attributes from superclass.
 There are two cases of inheritance:
o Inheritance without overriding for methods
 Guarantees that a subclass will honor its parent’s contracts.
 Specialization can be established through any added methods.
o Inheritance with overriding:
 In terms of contract, the contract may be broken in subclass, unless:
 Its precondition is the same or weaker (allows more input).
 Its post-condition is the same or stronger (provides a better service).
 The invariant is the same or stronger.

~49~

Software Components (SC):
 It is units of code that can be flexibly plugged together to build software applications. 
 SCs are plugged together to generate larger components or subsystems.
 It have some specific object oriented principles. These are:
o A component encapsulates data and functions.
o A component comes with a specification that clearly separates the component ’s interface
from its implementation;
o A component is known to clients only through its interface.
 Interface: a set of related operations corresponding to some specific service.
 There are two types of interface:
o Provide interface: defines the operations that the component offers to other. 
o Required interface: defines the operations that the component will need to request
from other components. 
 In Java:
public interface name {
method header;
}


Components are represented in UML as stereotyped boxes, where the stereotype can be graphical
or textual:
Graphical
Textual



Components may put together through their provided and required interfaces:

~50~

Specifying components and their interfaces:
 A component is a container of software artefacts and its specification.
 In UML an interface is represented as a box. The stereotype «interface» is used to distinguish it
from a class definition.




In Java, a class can implements an interface, the class should implement all operations found in the
interface.
Interface is used to represent multiple inheritance since a class can implement more than one
interface:
public class X implements Y {
}
// Y is an interface

Realization of interfaces (a class using an interface):
Realization

~51~

Using stereotyped dependency arrow:

Unit 10 (Components, Patterns and Architecture)
Architectural Patterns:
It codify recurrent software architectures, by describing the key elements of the architecture and how
they fit together
Software Architectures: 
A high-level abstract description of the structure of a major parts in the software system, and how they
put together and how they are interrelated
Architectural View:
 A model of the architecture that captures the concerns of a group of stakeholders of the system.
 Some of the architectural views are:
The Functional View
The Process View 
The Deployment View 
(Logical view) 
Cornerstone of most
Addresses concurrent aspects of Maps the software elements
architectural descriptions, and it the system at run-time, including onto the run-time, it describes
describes:
all system processes and system the environment into which the
start-up and shutdown.
system will be deployed
 The main functional
elements.
 Their responsibilities.
 Interfaces.
 Primary interactions.
In this course, we are primarily
concerned with the functional
view of a system.
The layers pattern:
 One style of software architecture is Layers pattern.
 Layer is a logical partitioning of a system.
 Layers pattern organizes the large-scale functional structure of a system into discrete layers of
distinct, related responsibilities.
Advantages
Disadvantages
 Separation of concerns (each layer
 Replication (there may be a need to
addresses a specific concern).
replicate information across layers).
 Lowered coupling (the dependency
 Performance (there may be a need to
between layers kept low).
perform extra transformations at each
layer).
 Reuse (general services).
 Flexibility (changes are localized).

~52~

o There are two flavors of Layers pattern based on number of layers: 
o Three-layer pattern:
 The presentation layer (handles the interaction between the users and the system).
 The domain layer (defines the work).
 The data source layer (handles the storage of persistent data).
o Five-layer pattern (involves extra mediating layers):
 The application layer (mediates between the presentation and domain layers).
 The technical services layer (mediates between the domain and data source layers.
 The Layers pattern has been widely applied to enterprise systems, it can be regarded as a way
of managing the complexity of enterprise systems. 
The Presentation Layer
The Application Layer
The Domain Layer
The Technical Services Layer
The Data Source Layer
List five characteristics of enterprise system. 
Enterprise systems are characterized by:
 Large quantities of data.
 Often used by many users simultaneously.
 Require many diverse user interfaces to handle different types of users.
 Integrated with other systems.
 Tend to be large and complex.
Frameworks:
 It represent already exist chunks of architecture and code that can be reused in developing new
systems.
 Frameworks components would be stored in a component repository.
 Ingredients that make up a framework are: the architecture, component repository, and
documentation.
 Frameworks help in the reuse of components because it will guide the user to the component
required, so that general search methods are not required.
Product lines:
 A set of related software products for different customers, reusing major parts of the software from
customer to customer.
 The product-line process:
1. Product-line initiation.
2. Domain analysis.
3. Architecture specification.
4. Component collection.
5. Specific-requirements capture.
6. Architecture specialization.
7. Component selection and specialization.
8. Integration and release.
~53~

Design patterns
 A design pattern codifies a solution to a recurring design problem.
 Design patterns help in the interaction between the actors and the system.
(1)
Model
View
Controller
Pattern
(MVC)

MVC was first introduced in the late 1970s in Smalltalk. Many UI component libraries
today are based on MVC principles.
Intent:
Split user interface interaction into three distinct roles:
How it works?
It identifies three roles
1. The model:
 Contains data and behaviour and is not a visual object.
 Resides in the business layer.
2. The view:
 The graphical manifestation of the model in the user interface.
 Resides in the presentation.
3. Controllers:
 Handles all user inputs which affect the model
 Resides in the presentation.
When to use it?
Use this pattern to separate the presentation from the model.
The advantages of this separation are many, including:
 Separation of concerns.
 Ease of testing.
 Flexibility.

(2)
Application
Controller
Pattern

Intent:
To have a centralized point for handling screen navigation and the flow of an application.
How it works?
Two main responsibilities:
1. Deciding which domain logic to run.
2. Deciding on the view that will display the response.
When to use it?
When the UI has many different screens, which should be targeted by the user according
to well-defined rules.

~54~

(3)
Observer
Pattern

Also known as Publisher–Subscriber.
This pattern is often used within user interfaces.
Intent:
To design a one-to-many dependency between objects.
How it works?
The pattern realises a change-propagation mechanism in which one object has the role of
the subject (publisher), and its dependants the role of observers (subscribers).
Responsibilities of publisher and observers are:
1. The push model is one in which the subject sends information when notifying its
observers.
2. The pull model is one in which the subject sends the notification only.
When to use it use it:
When the number or the identity of the observers of an object is not known.
When the object and its observers should not be tightly coupled.

(4)
Singleton
Pattern

Intent:
To ensure that a class has only one instance, and to provide a global point of access to it.
How it works?
The Singleton class defines:
 Class name: Singleton, with <<singleton>> stereotype.
 A private attribute (uniqueInstance).
 A public operation getInstance(), that lets other objects access its unique class
attribute uniqueInstance.
 A private operation creat() responsible for creating its own unique instance.
When to use it?
When there must be only one instance of a class.

~55~

(5)
Factory
Pattern

Intent:
To define a specialized object for the creation and initialization of other objects.
How it works?
There are two types of objects: The specialized object is called a factory, while the
Object (or objects) to be created is called the product.
The pattern has three classes: Client, Factory, and Product.
1. Clients requiring products for some purpose use the factory to create them.
2. A class Factory is responsible for the creation of products.
When to use it?
This is a general pattern for object creation and initialization, which increases the
flexibility of the system, by localizing the creation and initialization of objects within the
factory.

* Singleton Pattern & Factory Pattern are patterns that used to solve specific design problems.
Which design pattern is used to create complex instance hierarchy? 
Factory Pattern.

~56~

Unit 11 (Product Quality: Metrics, Verification, Validation, Testing)
What is quality?
Software that is fit for its purpose and is of sufficiently high quality.
Some of customer’s expectations:
 The product will not conflict with other software that they use.
 The product will boost productivity.
 The product will be simple to use.
To establish whether quality is appropriate, we can check:
How the product operates against what was both explicitly required, and implicitly expected by the
customer.
There are three general types of requirements:
1. Product operation requirements.
2. Product revision requirements.
3. Product transition requirements.
Software quality factors (SQFs) affected by the requirements types:
Product Operation
Product Revision
Requirements 
Requirements 
How the product will be used?
Factors:
 Correctness.
 Reliability.
 Efficiency.
 Integrity
 Usability.

How the product will be
changed?
Factors:
 Maintainability.
 Flexibility.
 Testability.

* Increasing integrity within a
system could affect efficiency.
Primary software quality factors:
1. Correctness.
2. Integrity.
3. Maintainability.
4. Usability.

~57~

Product Transition
Requirements 
How the product will be
modified for different operating
environments?
Factors:
 Portability.
 Reusability.
 Interoperability.

How to measure the primary SQFs? 
Correctness
 A popular measure for assessing correctness is defects per thousand lines of
(KLOC) 
code (defects per KLOC).
 Defects are reported by a user of a software product after the product has
been released.
Maintainability
 There is no way to measure maintainability directly, and so we must measure
(MTTC) 
it indirectly.
 A simple measure is mean time to change (MTTC), which is the average of the
times it takes to analyses a bug report, design a modification, implement the
change, test it and distribute it.
 The lower the MTTC, the more maintainable the software product is.
Integrity 
 Integrity is measured by considering the proportion of attacks on a product.
 Examples:
o Denial of service (the user is prevented from accessing a service). 
o Man in the middle and replay (false communications). 
o Accidental attacks (failure of the product). 
o Input attacks (data cause an application to function incorrectly). 


For each type of attack, both threatattack and securityattack can be given values
between 0 and 1.
Threatattack
Securityattack
)‫الهجمات (المحاوالت‬
‫عدد صد الهجمات‬



The integrity against attacks of this type, integrityattack, is defined to be:



The integrity of the software product is defined to be the sum, over all attack
types, of integrityattack:

Exercise: 
A web server has been running for a month.
From the log files for that month we see that of:
2000 accesses,
100 attacks were made.
Of these, 50 were denial-of-service attacks, of which 10 were successful,
25 were password guessing, of which none were successful)
and 25 were accidental attacks, of which 25 were successful.
Calculate threatattack and securityattack for each type of attack.
Solution:

The integrity of the server is thus 0.995 + 1 + 0.9875 = 2.9825.

~58~

Verification & Validation:
Verification 
 A process of ensuring that the design of a
system corresponds to its specification.









Are we building the product right?

Validation 
A process of checking that a software
system is consistent with the customer’s
requirements.




How to carry out verification:
Make sure that all system descriptions are
self-consistent.

Are we building the right product?
How to carry out validation:
Make sure that all system descriptions are
consistent with the customer’s
requirements.

Consistency with a customer requirement means that the requirement is met.
Completeness means that everything that should have been "said" in a system description has been
"said".
Analytical completeness means consider only requirements with fit criteria.

Testing:
 Testing is the process of exercising software to check that it does what it is supposed to. 
 Testing can be an aid on:
o Find bugs to improve software quality.
o Improve customer’s confidence.
 There are four distinct types of testing that occur during a software development project:
Usability Testing
 Test the functionality and user interface to ensure that they are
fit for the intended users.
Developmental Testing
 Checks that developmental activities have been carried out
correctly.
 It consists of three stages:
1. Unit testing (test classes).
2. Integration testing (test units together).
3. System testing (test completed system).
Requirements-Based
Testing

Regression Testing





Checks that a system meets the customer’s requirements.
It is carried out by QA staff.
Requirements-based testing consists of acceptance testing,
which is performed by the customer.
Occurs during system maintenance, and checks that fixing one bug has
not introduced others.

The relationship between system and acceptance testing:
 System testing is an in-house activity.
 Acceptance testing is a formal testing of an entire system, conducted by the customer.

~59~

Developmental Testing
(1) Unit Testing
(Verification)
Test units of functionality (classes) in
isolation.

(3) System Testing
(Validation)
System testing consists of checking that a completed
software system performs in accordance with its
requirements specification.

Unit testing should consist of five parts:
 Interface testing.
 Boundary condition testing.
 Local-data testing.
 Control-structure testing.
 Error-handler testing.
(2) Integration Testing
(Verification)
Test units in combination.

System testing should consist of the following generic tests:
 User-command testing.
 Interface and protocol testing.
 Start-up and initialization testing.
 Restart testing (Recover).
 Performance testing.
 Stress testing.
 Security testing.

One major problem with integration
testing is complexities of dynamic
binding caused by inheritance and
polymorphism.

A system test matrix:
An important document in system testing, as it relates
classes/ packages that will be executed when the various
system tests are carried out.

~60~

Measuring software quality factors:
 The quality of a software product can be measured by obtaining values for each factor.
 The measurement of these metrics varies in difficulty because some of the factors are subjective
and require questionnaires or checklists.
 The relationships between software metrics and SQFs:



When measurements are made, the following formula can be used to estimate a value, Fq, for each
software quality factor q:
Fq = w1*v1 + w2*v2 + ... +wn*vn
Where:
v1, v2, ... = Measured values for the metrics which relate to q,
w1,w2, ...
= Weightings indicating the relative importance of the metrics with respect to q.

~61~

Measuring system complexity:
Complexity could be measure by two approaches:
Lines-of-code metric 
McCabe’s cyclomatic-complexity metric 
(LOC)
Counting the number of lines in a piece Measures the complexity of method by counting number of
of code.
independent paths in method.
LOC may be an indicator of: 
 The number of errors.
 Maintenance effort.
 The number of person-years
needed for system development.
 Measuring complexity of specific
code.

Number of independent paths = number of decision points,
each one of the following add 1 to scyclomatic complexity,
start counting from 1:
 If.
 Loops (while, do while, for).
 Switch for each non-default case test.
 Try for each catch block but not the final block.
 &&, ||.

Exercise: 
Compare the complexities of the following two pieces of code using the LOC and cyclomatic-complexity
metrics.

Solution:
LOC: for both code A and Code B is 7 lines. The complexity according to the LOC metric is the same.
Cyclomatic complexity: Code A has cyclomatic complexity 3, whereas code B has cyclomatic complexity
1, which suggests that code A is the more complex of the two.
Object-oriented Complexity metrics:
 It is generally accepted that object-oriented systems require two levels of complexity metric:
o One to measure method complexity.
o Second to measure the complexity of the class structure.
Object-Oriented Complexity metrics are: 
#
Metric
1.
Depth-of-inheritance-tree (DIT)
2.
Coupling-between-objects (CBO)
3.
4.

Number-of-children (NOC)
Response-for-a-class (RFC)

5.

Lack-of-cohesion-in-methods (LCOM)

6.

Weighted-methods-per-class (WMPC)

Description
Number of hops through an object’s superclasses.
Number of relationships the class has with other
classes.
Number of immediate children for that class.
Size of the response set for the class, which consists of
all the methods of this class.
Number of pairs of methods that do not make reference
to the same attributes, minus the number
of pairs of methods that do.
Sum of the cyclomatic complexities of each method of
the class
~62~

Testing Techniques:
Black Box Testing 
Used to test that each aspect of the customer’s
requirements is handled correctly by an
implementation.
We design test cases by looking at the specification.
A strategy for black box testing (using
partitioning):
1. For each method in the class, determine the
input data space.
2. Partition the input data space into
subdomains.

3. Test all subdomains given by the case
analysis.

White Box Testing 
Used to check that the details of an
implementation are correct.
We design test cases by looking at the
specification.
A strategy for white box testing:
1. Basis-path testing:
 Based on the cyclomatic-complexity metric
which ensures that all reachable
statements in a method are tested.
 The cyclomatic-complexity metric counts
the number of independent paths through
a method body.
 It therefore provides us with an indication
of the maximum number of tests that
need to be performed in order to traverse
paths.
2. Loop testing:
Simple loops
for, while, do..while.
Nested loops
Loops which have, within their
body, other loops.
Concatenated Loops that follow each other.
loops

Advantage:
It allows all possible user-perceived functions to be
tested.
Disadvantage:
for many subsystems the number of subdomains
can be enormous, and hence the effort involved in
testing them all.
Problems with black box testing:
Results indicate poor coverage levels.

Problems with white-box testing:
The main problem is that white-box testing alone,
by concentrating on the code of an
implementation, may not reveal customer
requirements.
In general, the solution is to combine black-box and white-box testing.

~63~

Exercise (Black Box Testing): 
In an airline reservation system, a Booking class has a
method, which has been designed using a design by contract.
This method has two inputs:
- A command which is a String called summary.
- And flightNo which is an integer between 1 and 999.
Determine a suitable set of a black box test for the method
described above.

Solution:

Exercise (White Box Testing): 
Given the following fragment of code:
for(int i = 1; i < x; i++)
temp = temp + i;
Generate a test data for the white box testing for the following cases.
You need to specify the value(s) of x to do the required testing:
1. Skip the loop entirely.
2. Pass the loop exactly once.
3. Pass the loop twice.
4. Pass the loop 20 times.

~64~

Solution:
1.
Any value of x < = 1.
2.
x=2
3.
x= 3
4.
x = 21

Formal technical reviews (FTR):
A process to critique a product of the software development process with a view to improving it.
Inspection:
A formal, efficient, and economical method of finding errors in design and code.
Personnel
Processes
The standard list of personnel:
The Software Formal Inspections Guidebook
1. Moderator: manage the inspection and to
define:
provide leadership.
 Entry criteria: depend on the product, but
2. Scribe: records information about each defect
in general require that the product is
found.
sufficiently mature to be used as it stands
3. Author: developer of the product.
after the inspection process is complete.
4. Reviewers: do the actual inspecting.
 Exit criteria: are usually that all major
defects found have been corrected.
The inspection process consists of seven stages:
1. Planning.
2. Overview.
3. Preparation.
4. Review.
5. Report.
6. Rework.
7. Follow-up.
Making the most of inspections:
1. Inspect the product, not the producer.
2. Set an agenda and stick to it.
3. Limit debate and rebuttal.
4. Note defects, but don’t attempt to fix them.
5. Take written notes to record the defects.
6. Limit the number of participants and insist upon advance preparation.
7. Develop a checklist for each product to be reviewed.
8. Allocate resources and schedule time for inspections.
9. Provide meaningful training for participants.
10. Review early inspections.

~65~

Unit 13 (Process Quality Management, Human Resources, Quality Assurance)



Developing software is not easy, it needs good management; and that management is not easy
either.
Process quality is determined by a number of management activities:
(1)
Project management:
Project and
 Activity concerned with ensuring that a software project is completed
people
within the estimated time. 
management
 Concerned with controlling costs and making sure that the software is
produced on time.
People management:
 A combination of management and leadership.
 Concerned with enabling staff to work successfully.
People need to be managed at two levels:
1. Organization level:
Matrix organization is a popular way of organizing a software development
company, and it allows people to be managed appropriately at an
organizational level.

2. Project Level (team organization):
Each project manager must decide how to organize his/ her project team so
that the team members can most effectively collaborate to develop the
software.

(2)
Quality management:
Quality
An activity that takes place throughout the software development.
management The critically important concern of total quality management (TQM) is customer
satisfaction. This leads to the concept of a quality chain.
Quality chain: 
A succession of stages responsible for the final quality delivered to customer.
Quality circle: 
A way of involving everybody in the production of quality products.
(3)
It concerns with managing different versions of items.
Configuration Configuration management aims to solve the problem of keeping track of all the
management successive versions each item goes through, as well as the interdependencies
between them
~66~

Project Management:
The process of project management: 
1. Planning a project.
2. Estimating the work content, assigning that work to people and scheduling it.
3. Monitoring the progress of that work.
Risk analysis and risk management:
Risk analysis and management process involve: 
1. Identify risk.
2. Assess risk seriousness: Estimate the likelihood (probability) of the risk event occurring, and then
estimate its impact.
The method used will depend on the nature of the project:
o Informal approach: score the likelihood of each risk as "high" or "low", and only worry
about the high-risk events.
o Formal approach: estimate a numerical value for each likelihood and impact, and then
calculate the expected cost.
3. Dealing with risk:
a. Risk avoidance.
b. Risk retention (acceptance).
c. Risk reduction (most commonly used risk management strategy).
d. Risk transfer.
A Project manager decides to send all software engineers on a UML training course so all the has a
common understanding of current best practice in using UML.
This strategy to deal with such risk is known as… 
Risk reduction.
What are the primary concerns of the manager of a software development project? 
The primary concern is to be sure that the software is delivered: on schedule; within budget; to
specification.
Risk Categories: 
1. Project risks are those risks directly associated with the management of the project (budgetary,
scheduling, and personnel).
2. Technical risks are those risks concerned with the development and technical aspects of the
project (design, implementation, and maintenance).
3. Business risks are those risks that derive from the client and user environments (e.g. changes in
the client organization).
Estimation:
There are two system factors to estimate time and resources for a project:
 System size (number of functions or users).
 System complexity (subjective measure and relates to the interdependencies between elements of
the system).
Estimation Methods:
 Estimation by analogy: Software is built similar to one built before.
 Estimation by work breakdown: Work is broken down into smaller chunks that can be estimated by
analogy
 Function Point analysis (FBA).
 COCOMO.
~67~

Function Point Analysis (FPA):
It is a well-established technique for estimating the size and complexity of a software project.
How to calculate FP?
(1) Count of externally visible use cases = FU.
(2) Count the classes in the requirements class model = FC
(3) Find adjustment factors (WU and WC) depend on complexity of use cases and classes.
Weights for use cases (WU: 4 to 7).
Weights for classes (WC: 7 to 15).
(4) Calculate function points (FP) as:
FP = FU × WU + FC × WC
COCOMO (COnstructive COst MOdel):
 It is used to find effort in terms of size and in terms of project duration.
 This is done converting from code size (in KLOCs) to effort in person-months and to optimal project
duration in months.
Basic COCOMO, recognizes three classes of software project:
 Organic: relatively small, simple projects.
 Semi-detached: intermediate projects in terms of size and complexity.
 Embedded: complex software projects, such as a flight-control system for an aircraft.
Exercise: 
Perform a FPA and apply the basic COCOMO model to obtain the effort and the duration to develop a
software system for the library using below use case and class diagrams.
Assuming that:
 The weight of each use case is 7 and the weight of each class is 9.
 The summation value for all of the 14 complexity factors is 25.
 The system is small and it will be written using Java language.

Solution:
FPA
Number of use cases: Fu = 6
Weight of each use case: Wu = 7
Number of classes: Fc = 3
Wight of each class: Wc = 9
According to these information:
FP = Fu * Wu + Fc * Wc
= 6*7 + 3*9 = 42 + 27 = 69
Apply FP adjusted equation:

COCOMO
LOC = 60 (Java) per function point, so LOC = 60 *
62.1 = 3750 (approximately).
So our system has 3.75 KLOC.
Obtain parameters for E and D

The optimal duration is:

~68~

Exercise: 
Given the following diagrams and tables:

(1) Apply the DIT, CBO and NOC metrics to the abstract class Account.
Assume the class that has no parent is a direct subclass of the Object class.
(2) Perform a FP analysis and apply the basic COCOMO model to obtain the effort and the duration of
the above system assuming that:
The weight of each use case is 6 and the weight of each class is 10.
The summation value for all of the 14 complexity factors is 40.
The system is simple and it will be written using Java language.
Hint: FPadjusted = FP × ( 0.65 + 0.01 × ∑Fi )
Solution:
(1)
DIT = 1
CBO = 3
NOC = 2
(2)
Fu = 5 and Fc = 7.
FP = 5*6 + 7*10 = 100
FPadjusted = FP × ( 0.65 + 0.01 × ∑Fi )
= 100*(0.65 + 0.01*40) = 100*(1.05) = 105
LOC = 30 * 105 = 3150
Effort (E) = a(KLOC)b
= 2.4*(3.15)1.05
= 8 person – month
Duration (D) = c(E)d
= 2.5*(8)0.38
= 5.5 months

~69~

Estimation by Work breakdown and scheduling:
The technique of producing project plan involves two stages:
 Distribution of effort throughout software development process.
 Resource balancing.
Models to represent project plan: 
PERT Charts
Gantt Charts
(Project Evaluation and Review Technique)
A project management chart where activities are
A project management chart that emphasize the
shown as boxes with lines joining them.
times at which things happen.

Monitoring
Monitoring is the day-to-day process of tracking, the progress of a project.
There are two ways of monitoring:
1. Collecting data on expenditure:
Knowing for each activity how much of budget is spent. It is done at end of each week.
2. Monitoring by deliverable:
Monitoring actual completion of work through acceptance of each activity’s deliverable (output).
Quality management:
 An activity takes place throughout the software development process.
 Quality cannot be added to a system at the end, it must be built in from the start.
 It concerns of how we assure the quality of the final software product.
Quality management process involves:
1. Adding quality to a project plan.
2. Considering the principles and components that constitute a software quality management system.
3. Exploring the ISO standards.
Quality management systems (QMS):
An organization-wide mechanism for building quality into projects and for managing the quality control
process.
~70~

Elements of quality management system:
 Quality manual: Document describes organization's QMS (e.g. standards and guidelines).
 Quality plan: Mechanism for focusing the QMS onto the project.
 ISO 9000: International standards published by International Standards Organization (ISO).

Configuration management:
It is the task of managing configuration items, which involves identifying the components of a continuously
evolving system for the purposes of controlling changes to the configuration, and maintaining integrity and
traceability throughout the system’s lifetime.
Configuration item:
Items produced during the development and maintenance of software, which are stored, retrieved,
changed, and stored again, and so on.
These items include:
 UML diagrams.
 Individual Java programs or classes.
 Architectures and patterns.
 Test plans and test cases.
Configuration Repository:
A library of configuration items that would normally be stored in machine-readable form in a project
repository or library or database.
The use case diagram for the documentation of the configuration:

Distinguish between the terms configuration item, version, and variant.
A configuration item is any elementary work product produced during a project.
A configuration item will exist in many versions, which are revisions of the original item.
It may also possess a number of variants, which are essentially the same as the original item except that
they differ in some well-defined part of their description; variants may themselves exist in many
versions.

~71~

Unit 14 (Human Factors and Professional Issues)



Human factor: A discipline that tries to enhance the relationship between people and technology.
Human factors can be categorized into:
1. Product-related human factors.
2. Process-related human factors.
 The process-related human factors can be divided into three categories:
(1)
Related to software engineer as a person.
PersonThere are two types of person-related factors:
related
(1) Individual factors: they are concerned with the competence and motivation of
individual software engineers.
(2) Social-related factors: means that other person-related skills that concerned with
social behavior and communication.
(a) Working as part of a team.
There are several factors that affect functioning of a team:
 Team structure.
 Team goals.
 Team leadership.
 Team building.
(b) Communicate effectively with others:
There are several factors that affect communication of a team:
 Structure.
 Paths.
 Media.
 Types of communication: 
o Formal impersonal media: for documenting decisions
(documentation, and schedules).
o Formal interpersonal media: for developing a shared
understanding (reviews, and inspections).
o Informal interpersonal media: for keeping team members
informed (group meetings).
o Electronic media: for collaborating (email, bulletin boards, and
Wikis).
(2)
Related to tasks the engineer is undertaking.
Task-related There are three aspects of software development tasks that exert a particular influence
on human performance:
 Task complexity.
 Task familiarity.
 Task variability.
(3)
Related to environment in which the engineer works.
Environment (1) Physical space in which the work is done.
-related
1. Privacy.
2. Outside awareness.
3. Personalization.
(2) Methods and tools that support the software engineer.
1. Ease of learning.
2. Ease of use.
3. Availability of training and support.

~72~

Summary:

What factors affect the functioning of a team? 
Team structure, team goals, team leadership and team building.
Classify each of the following examples in terms of human factor type: person-related human factor,
task related human factor, environment related human factor. 
1. The usability of the debugging tool.
Answer: Environment related human factor.
2. Stress in the engineer’s personal life.
Answer: Person related human factor.
3. The similarity between this code module and others the engineer has implemented.
Answer: Task related human factor.
4. Noise in the office.
Answer: Environment related human factor

~73~

Quick Review
Activity Diagram (Unit 3)

Definition:
A technique for modelling business processes,
and it shows a process as a set of activities with
their sequences.

Use Case Diagram (Unit 3)

Class Diagram (Unit 5)

Definition:
It is a way of capturing functional requirements.

Definition:
It represents what all-possible instances of the
class have in common, rather than the particular
values of any given instance.

Disadvantages:
 The focus may end up being top-down and
function-oriented.
 Difficulties in deciding the size and scope
of each use case.
 A danger of missing some of the
requirements.

Disadvantages:
It is a static model that describes the elements of
a system (classes) and their relationships
(associations), and it does not describe behavior
over time.

Advantages:
 Help investigate the workflow.
 Help in understanding the basic behavior
of a system.
 Can record scenarios of use cases.

~74~

Object Diagram (Unit 5)

Definition:
It is a visual representation of an object model,
showing a snapshot of the system at some point in
time.

Sequence Diagram (Unit 6)

Communication Diagram (Unit 6)

Definition:
It is an object diagram with added message
sends, to show the flow of messages as they pass
along the links between objects.

Advantages:
It makes the time relationship clear.

Disadvantages:
It is a static model that describes the elements of a
system (objects) and their relationships (links), and it
does not describe behavior over time.

Definition:
It shows the flow of messages from object to
object, as time passes by.

Advantages:
It makes the interconnections between objects
clear.

Disadvantages:
It may not be easy to see overall patterns of
message flow.

Disadvantages:
Actual sequence of messages is difficult to see.

~75~

State Machine/Statechart Diagram (Unit 7)

Package Diagram (Unit 7)

Component Diagram (Unit 9)

Definition:
A technique used to model behavior of an object
in terms of states and transitions and events that
captures life history of an object.

Definition:
A technique used to group elements of a system.

Interface Diagram (Unit 9)

It designed for organizing a large project into
components, and depicting the overall structure
of a system.

Advantages:
 They are a means of elaborating the
potential operations within a class.
 They help to understand the behavior of
an object over its lifetime.
 They help to understand how an object
must respond to events.
 They are a means of ensuring correctness.

~76~

‫‪Study Plan‬‬
‫السبت‬
‫‪11-Jan‬‬

‫األحد‬
‫‪12-Jan‬‬

‫االثنين‬
‫‪13-Jan‬‬

‫الثالثاء‬
‫‪14-Jan‬‬

‫األربعاء‬
‫‪15-Jan‬‬

‫الخميس‬
‫‪16-Jan‬‬

‫الجمعة‬
‫‪17-Jan‬‬

‫الفترة األولى‬

‫-‬

‫2 & 1 ‪Units‬‬

‫6 ‪Unit‬‬

‫9 ‪Unit‬‬

‫11 ‪Unit‬‬

‫31 ‪Unit‬‬

‫راحة‬

‫الفترة الثانية‬

‫-‬

‫5 & 3 ‪Units‬‬

‫7 ‪Unit‬‬

‫01 ‪Unit‬‬

‫11 ‪Unit‬‬

‫31 ‪Unit‬‬

‫41 ‪Unit‬‬

‫السبت‬
‫‪18-Jan‬‬
‫الفترة األولى‬
‫الفترة الثانية‬

‫األحد‬
‫‪19-Jan‬‬

‫حل‬
‫االختبارات‬
‫السابقة‬
‫‪(Problem‬‬
‫(‪Solving‬‬

‫حل‬
‫االختبارات‬
‫السابقة‬
‫‪(Problem‬‬
‫(‪Solving‬‬

‫االثنين‬
‫‪20-Jan‬‬

‫الثالثاء‬
‫‪21-Jan‬‬

‫مراجعة عامة‬



‫‪M363 Final‬‬

‫~77~‬

Software Engineering with Objects (M363) Final Revision By Kuwait10

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Software Engineering with Objects (M363) Final Revision By Kuwait10 (20)

More from Kuwait10 (6)

Recently uploaded (20)

Software Engineering with Objects (M363) Final Revision By Kuwait10