Software Construction

Course Introduction
Isma ul Hassan
Email:[email protected]
Fall 2017
Textbooks
• Software Essentials: Design and Construction, Dingle A. (2014) CRC
Press.

• Code Complete: A Practical Handbook of Software Construction,

McConnell S., 2nd Edition (2004), Microsoft Press
Evaluation
Course
• Quizzes (15%)
• Assignments (10%)
• Sessionals (10+15=25%)
• Final (50%)
Lab
• 25 % lab tasks and assignments
• 50 % final or project
Plagiarism
• Don’t take someone else's material and present it as his or her own. Doing
so means committing plagiarism.

• “material" means ideas, words, code, suggestions, corrections on one's

work, etc.

• Plagiarism on an assignment or an exam will result in

• failing that assignment or that exam
• loosing points

• Penalties will be according to extent of plagiarism

Deadlines

Deadlines are firm

Each late day will reduce the assignment's grade

Fundamental Ideas
MODERN SOFTWARE
• Size and complexity
• Tremendous growth in the use and application of software has driven
dramatic advances in software development processes
• Despite all the improvements in design, implementation, and testing
techniques, software development remains difficult. Why ?
Modern Software
“Modern software must provide more than basic functionality”
• Security concerns exist for all software deployed on the Internet, as
do expectations of data privacy.
• Software applications are often embedded, e.g., in cellphones and
microwaves.
• Commercial software must provide a responsive user interface for a
general audience, often augmented with user tutorials.
• E-commerce applications directly support online sales but may also
depend on the data mining of customer histories to generate
additional purchase suggestions and so forth.
Fundamental Ideas
SOFTWARE DESIGN
• Most ideas start simply
• Software development is the same
• One starts with an initial product, receives feedback and then expands the
size, breadth, and/or complexity.
• Hence, we start with a simple example to underscore the
need to explicitly model and design
Example
• Say a programmer assumes the task of designing and implementing a
simple math tutor for elementary school children.
• Without taking time for design, a developer may code a repetitive loop that
controls a multistep query and response cycle:
(1) generate a simple addition problem,
(2) output problem,
(3) prompt for solution,
(4) accept input,
(5) check input against expected answer, and
(6) respond affirmatively or negatively.
Flow Chart
Problems
• Looping never terminates, regardless of whether a given answer is
correct or not.
• Error processing is missing—what happens if the student enters non-
numeric data?
• The form and content of a sample problem is not defined—are
negative numbers acceptable?
• User satisfaction is not considered: the same problem is repeated,
over and over, until a correct answer is received.
• Overall, there is no specification of system design with respect to
use, response, and repetition.
• The failure to design intentionally often yields narrowly scoped and
weak software.
Software Design
• Minimally, a designer
should determine
required domain
knowledge, form and
bounds of input, error
processing, and output.
Software Design
• To design intentionally, a software developer must state expectations
and restrictions.
• Furthermore, if extensions are anticipated, design decisions must
yield modifiable software.
• Will multiplication be incorporated into the design? How important is
support for mixed-mode arithmetic?
• Might it be desirable to retain a history of problem sessions?
• In short, for a viable, commercial product, software developers
should not just sit down at the keyboard and pound out code.
Software Design
• Software design is complicated.
• Why?
• Modern software must address broad expectations of use and longevity, as
well as variety in targeted audiences and deployment
 Fundamental Ideas
SOFTWARE UTILITY
• Software use is no longer confined to experts.
• Software systems target a wide range of users, possibly multinational, with
differing levels of expertise.
• Software systems are more likely to be distributed and consist of several
components integrated together.
• Hence, design priorities shift from computer performance issues, such as
data storage and processor clock cycles, to user expectations, such as
responsive interfaces and meaningful error processing
SOFTWARE UTILITY
Example
• An online reservation system must process requests to reserve an item,
whether the item is a library book, a plane ticket, or a seat in a theater.
• Typically, a reservation system must be accessible in-house and/or
externally, often via different browsers.
• Software applications hosted on a LAN (local area network) or the web,
rather than a dedicated machine, must service remote requests, handle
distributed data and other background processes such as message passing,
synchronization, recovery, traffic flow, etc.
• Fortunately, network software handles most background responsibilities
for an application. Still, application software must be designed to work
within the confines of network protocols. What works correctly on a single
processor does not necessarily work well when distributed across a
network
SOFTWARE UTILITY
• Customers expect a responsive interface that is usable, secure, and
robust.
• Vendors expect customer histories and retention of personal data.
• These expectations are not functional. That is, satisfying these
expectations does not directly address the core functionality of the
system: making a reservation.
• Software characteristics such as data persistence, usability, and security
are considered nonfunctional requirements because their fulfillment
does not immediately meet the strictly functional requirements of the
software.
• Nonfunctional components include the user interface, error handling,
storage of persistent data, performance tracking, security, and other
requirements
Fundamental Ideas
SOFTWARE PRODUCTION
• Modern software must meet expectations of responsive UIs, data
retention, portability, and longevity.
• How then should software be produced?
SOFTWARE PRODUCTION
• Software construction is complex and thus expensive, requiring
significant skill and experience.
• The cost of software development provides the incentive to maximize
usage and extend lifetime.
• Software is thus typically decomposed into modules so that these
components may be more easily reused and/or modified.
• Adherence to standards and convention, including design guidelines
and patterns, supports reuse.
• Design for reuse drives development. After all, it costs nothing to copy
software
Fundamental Ideas
SOFTWARE MAINTAINABILITY
• More than just bug fixes: it is the ability to update software to extend
the UI, improve performance, expand error handling, migrate to a
new platform, support a new localization release, and/or add new
functionality.
• Many software professionals, concerned by the negative association
of bug fixes with the term “software maintainability,” prefer an
alternate phrase: software evolution
Fundamental Ideas
SOFTWARE ENGINEERING
• Software engineering is the formalization of software project
management and software development techniques
• Software engineering brings a business orientation to the technical
work of defining, modeling, designing, and constructing complex
software
Fundamental Ideas
Software Development Life Cycle (SDLC)
Fundamental Ideas
MODELS
• What is a model?
• How is modeling related to design?
• What models are used for software development?
• Why should one bother modeling?
Fundamental Ideas
Software Process Methodologies
• Software process methodologies model the organization of different
stages of the software development life cycle.
• The classic methodology is the waterfall model, a strictly linear
staging that fails to accommodate change.
• Other methodologies offer a more responsive progression
MODELS
MODELS
• Incremental or iterative methodologies seek to improve upon the
waterfall model by endorsing incremental development with
feedback between requirements analysis and design.
• The most modern popular approach that uses this methodology is
agile software development
MODELS
• Extreme Programming (XP) is a well-known agile software
development methodology.
• It relies on very short development cycles, with continuous customer
feedback, so that requirements are identified and implemented
incrementally.
• These short development cycles, or bursts, typically require code
reviews and unit testing
MODELS
• Rational Unified Process (RUP) is a methodology built on top of object
orientation: object-oriented design
• It is a staged approach, like waterfall, but with continuous integration.
Adaptation for different platforms and customization for localization
and so forth can thus be accommodated.
MODELS
• Another methodology that modifies the waterfall model is the
“spiral” model.
• It focuses on prototyping and iterative development but includes risk
management; that is, explicit specification of objectives, alternatives,
and constraints.
• Validation is based on acceptance criteria.
MODELS
• With an emphasis on writing tests first, test-driven development
(TDD) relies on a short development cycle just like XP.
• The initial step is to write (automated) test cases that define system
requirements, or redefine functionality that warrants modification.
• Without an adequate code base, these initial tests will fail. The next
step is to write code so that the test cases pass, followed by a step
that refactors the code to sustain design principles and remove
duplicate code
MODELS
• Models support both abstraction and generalization.
• Complex systems are typically reduced to a number of interacting
subsystems.
• Understanding a large system requires an understanding of its
constituent parts.
Fundamental Ideas
Requirements Analysis and Specification
• Initial stage of the software development life cycle should establish project
scope and software requirements.
• The primary goal is to define functionality: what does the user need the
software to do?
• The task of defining requirements is more challenging than it might seem:
users often do not know what should be required, may confuse wants with
needs, cannot fully or accurately describe technical expectations or
product characteristics, or may have unrealistic expectations.
• Even with concerted effort then, specifications may be ambiguous,
inconsistent, and/or incomplete. Re-examination of requirements is often
warranted, even in the midst of other stages of the SDLC.
Requirements Analysis and Specification
• The requirements document specifies system functionality and use, that is,
the what (and maybe the why) but not the how.
• A requirements document serves as a touchstone for all subsequent stages;
it is not static.
• Details may change as target audiences expand, technology changes, or
budget allocations fluctuate.
• Nonetheless, core functionality, as well as interface and performance
expectations, should be fairly stable.
• The requirements document should also specify system requirements such
as compatibility with other packages and portability to a variety of
platforms.
Requirements Analysis and Specification
• Many different models may be used to reflect functional
requirements.
• State machines, decision tables, state charts, and flowcharts are often used

• Requirements document specifies system requirements such as

integration expectations, compatibility constraints, and performance
criteria.
• It details what the system should do; it is not a design document; it
does not specify how the system works.
Requirements Analysis and Specification
• Nonfunctional properties (NFP) should be included as requirements,
where a nonfunctional property is defined as a software characteristic
that does not directly advance the goal of realizing core functionality.

• Also known as software qualities or nonfunctional requirements,

NFPs embody software’s appeal: usability, scalability, reliability, etc.
NFPs are difficult to model, implement, and assess.
Modeling
UML
• UML provides standard diagrams to represent design, and to a limited
extent, to document software architecture.
• It is just a tool.
• It does not make modeling any easier; it often makes the
representation of models easier
• UML defines three types of diagrams:
• Structural
• Behavioral
• Interaction
Structural Modeling
• Structural diagrams document the static structure of the software
system and how different portions relate to each other
Behavioral Modeling
• Behavioral Modeling Diagrams capture interactions within a model as
well as system states and state transitions.
• By modeling dynamic behavior, one can track system use and
response under both normal and abnormal conditions.
• Behavioral diagrams record the effects of an operation or event and
thus define functionality and identify error conditions and responses.
Behavioral Modeling
Interaction Modeling
• Interaction diagrams are a subset of behavior diagrams and model
interactions between components, system, and environment
Structural Modeling
Class Diagram
• Structural model: a view of a system that emphasizes the structure of
the objects, including their classifiers, relationships, attributes and
operations.
• Core Element
• Class: a description of a set of objects that share the same attributes,
operations, methods, relationships and semantics.
UML Class Diagrams
⚫ Class diagrams in UML can be expressed at different level of detail.
⚫ At the first stage of developing a model, look at the world and
identify the essential objects and represent them as class.
⚫ The simplest way is to write the name of the class in a box

Patient
Classes
A class is a description of a set of
ClassName objects that share the same attributes,
operations, relationships, and semantics.
attributes
Graphically, a class is rendered as a
rectangle, usually including its name,
operations attributes, and operations in separate,
designated compartments.
Class Names

The name of the class is the only required

ClassName tag in the graphical representation of a
class. It always appears in the top-most
attributes compartment.

operations
Class Attributes

Person

name : String An attribute is a named property of a

address : Address class that describes the object being modeled.
birthdate : Date In the class diagram, attributes appear in
ssn : Id the second compartment just below the
name-compartment.
Relationships

In UML, object interconnections (logical or physical), are

modeled as relationships.

There are three kinds of relationships in UML:

• dependencies

• generalizations

• associations
Generalization Relationships

Person
A generalization connects a subclass
to its superclass. It denotes an
inheritance of attributes and behavior
from the superclass to the subclass and
indicates a specialization in the subclass
of the more general superclass.
Student
Generalization Relationships (Cont’d)
UML permits a class to inherit from multiple superclasses,
although some programming languages (e.g., Java) do not permit
multiple inheritance.

Student Employee

TeachingAssistant
Association Relationships
If two classes in a model need to communicate with each other,
there must be link between them.

An association denotes that link.

Student Instructor
Association Relationships (Cont’d)
We can indicate the multiplicity of an association by adding
multiplicity adornments to the line denoting the association.

The example indicates that a Student has one or more

Instructors:

Student Instructor
1..*
Association Relationships (Cont’d)

The example indicates that every Instructor has one or more

Students:

Student Instructor
1..*
Association Relationships (Cont’d)
We can also indicate the behavior of an object in an association
(i.e., the role of an object) using rolenames.

teaches learns from

Student Instructor
1..* 1..*
Association Relationships (Cont’d)
We can also name the association.

membership
Student Team
1..* 1..*
Association Relationships (Cont’d)
We can specify dual associations.

member of
1..* 1..*
Student Team
1 president of 1..*
Association Relationships (Cont’d)
We can model objects that contain other objects by way of
special associations called aggregations and compositions.

An aggregation specifies a whole-part relationship between

an aggregate (a whole) and a constituent part, where the part
can exist independently from the aggregate. Aggregations are
denoted by a hollow-diamond adornment on the association.

Engine
Car
Transmission
Association Relationships (Cont’d)
A composition indicates a strong ownership and coincident
lifetime of parts by the whole (i.e., they live and die as a
whole). Compositions are denoted by a filled-diamond
adornment on the association.

Scrollbar
1 1

Window Titlebar
1 1

Menu
1 1 .. *

Software Design (UML)

Noun Identification: A library System
A Possible Class Diagram
Behavioral Modeling
Use Case Diagram
• A use case defines a goal-oriented set of interactions between
external actors and the system under consideration

• Actors are parties outside the system that interact with the system
• An actor may be a class of users or other systems
Behavioral Modeling
Use Case Diagram
Behavioral Modeling
Use Case Diagram
• Include relationship: use case fragment that is duplicated in multiple
use cases

• Extend relationship: use case conditionally adds steps to another first

class use case
• Example:
Use Case – ATM Example
• Actors:
• ATM Customer
• ATM Operator
• Use Cases:
• The customer can
• withdraw funds from a checking or savings account
• query the balance of the account
• transfer funds from one account to another
• The ATM operator can
• Shut down the ATM
• fill the ATM cash dispenser
• Start the ATM
Use Case – ATM Example
 Use Case – ATM Example

• Validate PIN is an Inclusion Use Case

• It cannot be executed on its own
• Must be executed as part of a Concrete Use Case

• On the other hand, in extend use case a Concrete Use Case can be
executed