DEVELOPING USE CASES

• Use case → a list of actions or event steps typically defining the

interactions between a role (known in the Unified Modeling
Language (UML) as an actor) and a system to achieve a goal. The
actor can be a human or other external system.
• A use case tells a stylized story about how an end user interacts
with the system under a specific set of circumstances.
• Regardless of its form, a use case depicts the software or system
from the end user’s point of view.
• The first step in writing a use case is to define the set of “actors” that
will be involved in the story.
• Actors represent the roles that people (or devices) play as the system
operates. An actor is anything that communicates with the system or
product and that is external to the system itself.
• An actor and an end user are not necessarily the same thing.
• A typical user may play a number of different roles when using a
system, whereas an actor represents a class of external entities
(often, but not always, people) that play just one role in the context
of the use case.
• Ex: consider a machine operator (a user) who interacts with the
control computer for a manufacturing cell that contains a number of
robots and numerically controlled machines.
• After careful review of requirements, the software for the control
computer requires 4 different modes (roles) for interaction:
programming mode, test mode, monitoring mode, and
troubleshooting mode. Therefore, 4 actors can be defined
→programmer, tester, monitor, and troubleshooter.
• It is possible to identify primary actors during the first iteration and
secondary actors as more is learned about the system.
• Primary actors → interact to achieve required system function and
derive the intended benefit from the system. They work directly and
frequently with the software.
• Secondary actors → support the system so that primary actors can
do their work.
• Once actors have been identified, use cases can be developed.
• A number of questions should be answered by a use case: -
1. Who is the primary actor, the secondary actor(s)?
2. What are the actor’s goals?
3. What preconditions should exist before the story begins?
4. What main tasks or functions are performed by the actor?
5. What exceptions might be considered as the story is described?
6. What variations in the actor’s interaction are possible?
7. What system information will the actor acquire, produce, or change?
8. Will the actor have to inform the system about changes in the external
environment?
9. What information does the actor desire from the system?
10. Does the actor wish to be informed about unexpected changes?
• Ex: basic SafeHome requirements define 4 actors:
1. homeowner (a user),
2. setup manager (likely the same person as homeowner, but playing a different role),
3. sensors (devices attached to the system), and
4. the monitoring and response subsystem (the central station that monitors the SafeHome
home security function).

• For the purposes of this example, we consider only the homeowner actor. The
homeowner actor interacts with the home security function in a number of
different ways using either the alarm control panel or a PC.
• The homeowner:
1. Enters a password to allow all other interactions,
2. Inquires about the status of a security zone,
3. Inquires about the status of a sensor,
4. Presses the panic button in an emergency, and
5. Activates/deactivates the security system.
• Considering the situation in which the homeowner uses the control panel,
the basic use case for system activation follows:
• Template for detailed descriptions of use cases:
Lakshmi M
B
Lakshmi M
B
 DESIGN CONCEPTS
• Software design encompasses the set of principles, concepts, and
practices that lead to the development of a high-quality system or
product.
• The goal of design is to produce a model or representation that
exhibits firmness, commodity, and delight.
• It changes continually as new methods, better analysis, and broader
understanding evolve.
DESIGN WITHIN THE CONTEXT OF SOFTWARE ENGINEERING

• Software design sits at the technical kernel of software engineering

and is applied regardless of the software process model that is used.

• Beginning once software requirements have been analyzed and

modeled, software design is the last software engineering action
within the modeling activity and sets the stage for construction (code
generation and testing).
• The flow of information during software design is illustrated in the
figure.
• Data/Class Design - transforms class models into design class
realizations and the requisite data structures required to implement
the software. The objects and relationships provide the basis for the
data design activity.
• Architectural Design - defines the relationship between major
structural elements of the software, the architectural styles and
patterns that can be used to achieve the requirements defined for the
system, and the constraints that affect the way in which architecture
can be implemented. The architectural design representation—the
framework of a computer-based system—is derived from the
requirements model.
• Interface Design - describes how the software communicates with
systems that interoperate with it, and with humans who use it. An
interface implies a flow of information (e.g., data and/or control) and
a specific type of behavior. Therefore, usage scenarios and behavioral
models provide much of the information required for interface
design.
• Component-Level Design - transforms structural elements of the
software architecture into a procedural description of software
components. Information obtained from the class-based models and
behavioral models serve as the basis for component design.
DESIGN PROCESS
Software design is an iterative process through which requirements are
translated into a “blueprint” for constructing the software.

Software Quality Guidelines and Attributes

• 3 characteristics used for evaluation of quality:
1. The design should implement all of the explicit requirements contained in the
requirements model, and it must accommodate all of the implicit requirements desired by
stakeholders.
2. The design should be readable and understandable for those who generate code and test
the software.
3. The design should provide a complete picture of the software, addressing the data,
functional, and behavioral domains from an implementation perspective.
Quality Guidelines:
1. A design should exhibit an architecture that (1) has been created using recognizable architectural
styles or patterns, (2) is composed of components that exhibit good design, and (3) can be
implemented in an evolutionary fashion, thereby facilitating implementation and testing.
2. A design should be modular; i.e., the software should be logically partitioned into elements or
subsystems.
3. A design should contain distinct representations of data, architecture, interfaces, and
components.
4. A design should lead to data structures that are appropriate for the classes to be implemented and
are drawn from recognizable data patterns.
5. A design should lead to components that exhibit independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.
7. A design should be derived using a repeatable method that is driven by information obtained
during software requirements analysis.
8. A design should be represented using a notation that effectively communicates its meaning.
Quality Attributes:
1. Functionality - assessed by evaluating the feature set and capabilities of
the program, the generality of the functions that are delivered, and the
security of the overall system.
2. Usability - assessed by considering human factors , overall aesthetics,
consistency, and documentation.
3. Reliability - evaluated by measuring the frequency and severity of failure,
the accuracy of output results, the mean-time-to-failure (MTTF), the ability
to recover from failure, and the predictability of the program.
4. Performance - measured using processing speed, response time, resource
consumption, throughput, and efficiency.
5. Supportability - combines extensibility, adaptability, and serviceability.
DESIGN CONCEPTS
• An overview of fundamental software design concepts:
1. Abstraction
2. Architecture
3. Patterns
4. Separation of Concerns
5. Modularity
6. Information Hiding
7. Functional Independence
8. Refinement
9. Aspects
10. Refactoring
11. Object-Oriented Design Concepts
12. Design Classes
13. Dependency Inversion
14. Design for Test
1. Abstraction:
• At the highest level of abstraction, a solution is stated in broad terms using
the language of the problem environment.
• At lower levels of abstraction, a more detailed description of the solution is
provided.
• Create both procedural and data abstractions.
• Procedural abstraction - a sequence of instructions that have a specific
and limited function.
• Data abstraction - a named collection of data that describes a data
object.
2. Architecture:
• Architecture is the structure or organization of program components (modules), the
manner in which these components interact, and the structure of data that are used by
the components.
• One goal of software design is to derive an architectural rendering of a system.
• A set of architectural patterns enables a software engineer to reuse design-level
concepts.
• Structural properties - “the components of a system (e.g., modules, objects, filters)
and the manner in which those components are packaged and interact with one
another.”
• Extra-functional properties - address “how the design architecture achieves
requirements for performance, capacity, reliability, security, adaptability, and other
system characteristics.
• Families of related systems - “draw upon repeatable patterns that are
commonly encountered in the design of families of similar systems.”
• Structural models - represent architecture as an organized collection of
program components.
• Framework models - increase the level of design abstraction by
attempting to identify repeatable architectural design frameworks
(patterns) that are encountered in similar types of applications.
• Dynamic models - address the behavioral aspects of the program
architecture, indicating how the structure or system configuration may
change as a function of external events.
• Process models - focus on the design of the business or technical
process that the system must accommodate.
• Functional models - used to represent the functional hierarchy of a
system.
3. Patterns:
• A named nugget of insight which conveys the essence of a proven solution to
a recurring problem within a certain context amidst competing concerns.
• Describes a design structure that solves a particular design problem within a
specific context and amid “forces” that may have an impact on the manner in
which the pattern is applied and used.
• These provide a description that enables a designer to determine:
(1) whether the pattern is applicable to the current work,
(2) whether the pattern can be reused (hence, saving design time), and
(3) whether the pattern can serve as a guide for developing a similar, but
functionally or structurally different pattern.
4. Separation of Concerns:
• Suggests that any complex problem can be more easily handled if it is
subdivided into pieces that can each be solved and/or optimized
independently.
• Concern - a feature or behavior that is specified as part of the
requirements model for the software.
• By separating concerns into smaller, and therefore more manageable
pieces, a problem takes less effort and time to solve.
5. Modularity:
• Software is divided into separately named and addressable components,
sometimes called modules, that are integrated to satisfy problem
requirements.
• Modularity - the single attribute of software that allows a program to be
intellectually manageable”.
6. Information Hiding :
• The principle of information hiding suggests that modules should be
specified and designed so that information (algorithms and data)
contained within a module is inaccessible to other modules that have no
need for such information.
• The intent of information hiding is to hide the details of data structures
and procedural processing behind a module interface. Knowledge of the
details need not be known by users of the module.
7. Functional Independence :
• Functional independence is achieved by developing modules with “ single-
minded” function and an “aversion” to excessive interaction with other
modules.
• Functional independence is a key to good design, and design is the key to
software quality.
• Independence is assessed using 2 qualitative criteria:
1. Cohesion - an indication of the relative functional strength of a module.
2. Coupling - an indication of the relative interdependence among modules.
 8. Refinement :
• Stepwise refinement is a top-down design strategy.
• It is actually a process of elaboration.
• You begin with a statement of function (or description of information) that is defined at a high level of abstraction.
• You then elaborate on the original statement, providing more and more detail as each successive refinement
(elaboration) occurs.
• Abstraction and refinement are complementary concepts. Abstraction enables you to specify procedure and
data internally but suppress the need for “outsiders” to have knowledge of low-level details. Refinement helps
you to reveal low-level details as design progresses
9. Aspects :
• As design begins, requirements are refined into a modular design
representation.
• Consider 2 requirements, A and B. Requirement A crosscuts requirement B
“if a software decomposition [refinement] has been chosen in which B
cannot be satisfied without taking A into account”.
• An aspect is a representation of a crosscutting concern.
• An aspect is implemented as a separate module (component) rather than
as software fragments.
10. Refactoring :
• A reorganization technique that simplifies the design (or code) of a
component without changing its function or behavior.
• Refactoring is the process of changing a software system in such a way that
it does not alter the external behavior of the code [design] yet improves its
internal structure.
• When software is refactored, the existing design is examined for
redundancy, unused design elements, inefficient or unnecessary
algorithms, poorly constructed or inappropriate data structures, or any
other design failure that can be corrected to yield a better design.
11. Object-Oriented Design Concepts :
• OO design concepts –
• classes and objects,
• inheritance,
• messages, and
• polymorphism.

Lakshmi M
B
12. Design Classes:
• These refine the analysis classes by providing design detail that will enable the
classes to be implemented, and implement a software infrastructure that
supports the business solution.
• 5 different types of design classes:
1. User interface classes - define all abstractions that are necessary for human-
computer interaction (HCI) and often implement the HCI in the context of a metaphor.
2. Business domain classes - identify the attributes and services (methods) that are
required to implement some element of the business domain that was defined by one
or more analysis classes.
3. Process classes - implement lower-level business abstractions required to fully
manage the business domain classes.
4. Persistent classes - represent data stores (e.g., a database) that will persist beyond
the execution of the software.
5. System classes - implement software management and control functions that enable
the system to operate and communicate within its computing environment and with the
outside world.
• 4 characteristics of a well-formed design class:
1. Complete and sufficient
2. Primitiveness
3. High cohesion
4. Low coupling
 [Link] Inversion:
• The dependency inversion principle states: High-level modules (classes)
should not depend [directly] upon low-level modules. Both should depend
on abstractions. Abstractions should not depend on details. Details should
depend on abstractions.

14. Design for Test:

• Whether to design and then test, or test before implementing a code.
THE DESIGN MODEL
• The design model can be viewed in two different dimensions:
1. Process dimension indicates the evolution of the design model as
design tasks are executed as part of the software process.
2. Abstraction dimension represents the level of detail as each element
of the analysis model is transformed into a design equivalent and then
refi ned iteratively.
• The design model has 4 major elements:
1. Data Design Elements,
2. Architectural Design Elements,
3. Interface Design Elements, and
4. Component-Level Design Elements.

Lakshmi M
B
1. Data Design Elements:
• Data design (or data architecting) creates a model of data and/or information
that
is represented at a high level of abstraction (the customer/user’s view of data).
• Then refined into progressively more implementation-specific
representations that can be processed by the computer-based system.
• At the program-component level, the design of data structures and the
associated
algorithms is essential to the creation of high- quality applications.
• At the application level, the translation of a data model (derived as part of
requirements engineering) into a database is pivotal to achieving the
business objectives of a system.
• At the business level, the collection of information stored in disparate
databases and reorganized into a “data warehouse” enables data mining or
knowledge discovery that can have an impact on the success of the business
itself.
Lakshmi M
B
2. Architectural Design
Elements:
• The architectural design for software is the equivalent to the fl oor plan of
a house.
• The architectural model is derived from 3 sources:
1. information about the application domain for the software to be built;
2. specific requirements model elements such as use cases or analysis classes, their
relationships and collaborations for the problem at hand; and
3. the availability of architectural styles and patterns.
• The architectural design element is usually depicted as a set of
interconnected subsystems, often derived from analysis packages
within the requirements model.
• Each subsystem may have its own architecture.

Lakshmi M
B
3. Interface Design
Elements:
• The interface design for software is analogous to a set of detailed
drawings (and specifications) for the doors, windows, and external
utilities of a house.
• The interface design elements for software depict information flows
into and out of a system and how it is communicated among the
components defined as part of the architecture.
• There are 3 important elements of interface design:
1. the user interface (UI),
2. external interfaces to other systems, devices, networks, or other producers
or consumers of information, and
3. internal interfaces between various design components.
• These interface design elements allow the software to communicate
externally and enable internal communication and collaboration
among the components that populate the software architecture.
Lakshmi M
B
4. Component-Level Design
Elements:
• The component-level design for software is the equivalent to a set of
detailed drawings (and specifications) for each room in a house.
• The component-level design for software fully describes the
internal detail of each software component.
• To accomplish this, the component-level design defines data
structures for all local data objects and algorithmic detail for all
processing that occurs within a component and an interface that
allows access to all component operations (behaviors).
• The design details of a component can be modeled at many
different levels of abstraction.

Lakshmi M
B
4. Development-Level Design
Elements:
• Deployment-level design elements indicate how software functionality
and subsystems will be allocated within the physical computing
environment that will support the software.

Lakshmi M
B