SOFTWARE ENGINEERING

UNIT-III
School of CSA
DESIGN CONCEPTS
DESIGN CONCEPTS :

1. Software design is a mechanism to transform user requirements into some

suitable form, which helps the programmer in software coding and
implementation.
2. It deals with representing the client's requirement, as described in SRS (Software
Requirement Specification) document, into a form, i.e., easily implementable
using programming language.
3. The software design phase is the first step in SDLC (Software Design Life
Cycle), which moves the concentration from the problem domain to the solution
domain.
4. In software design, we consider the system to be a set of components or modules
with clearly defined behaviors & boundaries.

3
Objectives of software design
 Software Design Principles
• Software design principles are concerned with providing means to handle the
complexity of the design process effectively.
• Effectively managing the complexity will not only reduce the effort needed for
design ,
• But can also reduce the scope of introducing errors during design.
Problem Partitioning
For small problem, we can handle the entire problem at once ,but for the significant problem,
divide the problems and conquer the problem.
• It means to divide the problem into smaller pieces so that each piece can be captured separately.
• For software design, the goal is to divide the problem into manageable pieces.
Benefits of Problem Partitioning

1.Software is easy to understand

2.Software becomes simple
3.Software is easy to test
4.Software is easy to modify
5.Software is easy to maintain
6.Software is easy to expand
• These pieces cannot be entirely independent of each other as they
together form the system.
• They have to cooperate and communicate to solve the problem. This
communication adds complexity.
 Software Design Principles
• Software design principles are concerned with providing means to handle the
complexity of the design process effectively.
• Effectively managing the complexity will not only reduce the effort needed for
design ,
• But can also reduce the scope of introducing errors during design.
Problem Partitioning
For small problem, we can handle the entire problem at once ,but for the significant problem,
divide the problems and conquer the problem.
• It means to divide the problem into smaller pieces so that each piece can be captured separately.
• For software design, the goal is to divide the problem into manageable pieces.
ABSTRACTION
1.An abstraction is a tool that enables a designer to consider a component at an abstract level
without bothering about the internal details of the implementation.
2.Abstraction can be used for existing element as well as the component being designed.
There are two common abstraction mechanisms
3.Functional Abstraction
4.Data Abstraction
Functional Abstraction
i.A module is specified by the method it performs.
ii.The details of the algorithm to accomplish the functions are not visible to the user of the
function.
1.Functional abstraction forms the basis for Function oriented design approaches.
Data Abstraction
1.Details of the data elements are not visible to the users of data. Data Abstraction forms the
basis for Object Oriented design approaches.
MODULARITY
1. Modularity specifies to the division of software into separate modules,which are
differently named and addressed and are integrated later on to obtain the
completely functional software.
2. It is the only property that allows a program to be intellectually manageable.
3. Single large programs are difficult to understand and read due to a large number of
reference variables, control paths, global variables, etc.
CONTID….

The desirable properties of a modular system are:

• Each module is a well-defined system that can be used with other applications.
• Modules can be separately compiled and saved in the library.
• Modules should be easier to use than to build
REQUIREMENTS MODELLING

1. Scenario based
2. Class based
3. Flow oriented behavioral elements
4. Behavioral elements
REQUIREMENTS MODELLING
Benefits of Problem Partitioning

1.Software is easy to understand

2.Software becomes simple
3.Software is easy to test
4.Software is easy to modify
5.Software is easy to maintain
6.Software is easy to expand
• These pieces cannot be entirely independent of each other as they
together form the system.
• They have to cooperate and communicate to solve the problem.
User Interface Design
• The visual part of a computer application or operating system through which a client interacts with a computer
or software.
• It determines how commands are given to the computer or the program and how data is displayed on the screen.
Types of User Interface
• There are two main types of User Interface:
• Text-Based User Interface or Command Line Interface
• Graphical User Interface (GUI)
Text-Based User Interface: This method relies primarily on the keyboard.
• A typical example of this is UNIX.
Advantages
• Many and easier to customizations options.
• Typically capable of more important tasks.
Disadvantages
• Relies heavily on recall rather than recognition.
• Navigation is often more difficult.
GRAPHICAL USER
INTERFACE (GUI)

1. A computer program that enables a person to communicate with a

computer through the use of symbols, visual metaphors, and pointing
devices.
2. It includes Graphical representation like buttons and icons, and
communication can be performed by interacting with these icons rather
than the usual text-based or command-based communication,
Understanding.
Example:For a GUI is Microsoft operating systems.
3. Adavantages:User Friendly, Attractiveness, Shortcut Keys
4. Disadvantages:Time Consumption, Memory Usage
QUALITY GUIDELINES.

1. In order to evaluate the quality of a design representation, you and other members
of the software team must establish technical criteria for good design.
Consider the following guidelines:
2. A design should exhibit an architecture that has been created using recognizable
architectural styles or patterns, 2)It is composed of components that exhibit good
design characteristics ,3) implemented in an evolutionary fashion,to thereby
facilitating implementation and testing.
2. A design should be modular; that is, 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. Hewlett-Packard developed a set of software quality attributes that has been given
the acronym
2. FURPS—functionality, usability, reliability, performance, and supportability.
The FURPS quality attributes represent a target for all software design: Functionality
is 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.
1. Usability is assessed by considering (human factors )overall aesthetics,
consistency, and documentation.
2. Reliability is 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.
3. Performance is measured by considering processing speed, response time, resource
consumption, throughput, and efficiency.
4. Supportability combines the ability to extend the program (extensibility),
adaptability, serviceability—these three attributes represent a more common term,
maintainability—and in addition, testability, compatibility, configurability
User Interface Design Patterns
User interface is the front-end application view to which user interacts in order to use the software.
The software becomes more popular if its user interface is:
• Attractive
• Simple to use
• Responsive in short time
• Clear to understand
• Consistent on all interface screen
User Interface Design- The Golden Rules

• Theo Mandel coins three golden rules:

1. Place the user in control.

2. Reduce the user’s memory load.

3. Make the interface consistent.

1.)PLACE THE USER IN CONTROL

Define interaction modes in a way that does not force a user into
unnecessary or undesired actions.- An interaction mode is the current state of the
interface.
• Provide for flexible interaction,Because different users have different interaction
preferences, choices should be provided.
• Allow user interaction to be interruptible and undoable. Even when involved in a
sequence of actions, the user should be able to interrupt the sequence to do something else
(without losing the work that had been done).
2.)REDUCE THE USER’S MEMORY LOAD
• Reduce demand on short-term memory. The interface should be designed to
reduce the requirement to remember past actions, inputs, and results.

• Establish meaningful defaults. The initial set of defaults should make sense
for the average user, but a user should be able to specify individual
preferences.
• Define shortcuts that are intuitive. When mnemonics are used to accomplish
a system function (e.g., alt-P to invoke the print function), the mnemonic
should be tied to the action in a way that is easy to remember (e.g., first letter
of the task to be invoked)
3.) MAKE THE INTERFACE CONSISTENT
The interface should present and acquire information in a consistent fashion. This implies that
1. All visual information is organized according to design rules that are maintained
throughout all screen displays,
2. Input mechanisms are constrained to a limited set that is used consistently throughout the
application, and
3. Mechanisms for navigating from task to task are consistently defined and implemented.
Allow the user to put the current task into a meaningful context. Many interfaces
implement complex layers of interactions with dozens of screen images.
It is important to provide indicators (e.g., window titles, graphical icons, consistent color
coding) that enable the user to know the context of the work at hand. In
addition, the user should be able to determine where he has come from and what
alternatives exist for a transition to a new task
Interface Design

1. Easy to learn ?
2. Easy to use ?
3. Easy to understand ?
-------------------------------------
Typical Design Errors
4. Lack of Consistency
5. Too Much Memorization
6. No proper guidance /help
7. Poor Response
8. Arcane /unfriendly
USER INTERFACE DESIGN
MODELS

1. User model : a profile of all the end user of the system

2. Design model: design realization of the user model
3. Mental model(System Perception): the user image of what interface
4. Implemenation model: interface look and feel coupled with supporting information that describe
the syntax and symantics .
USER INTERFACE DESIGN
PROCESS
Video
ACTIVITY DIAGRAM
1. Activity diagram is another important diagram in UML to describe the
dynamic aspects of the system.
2. Activity diagram is basically a flowchart to represent the flow from one
activity to another activity.
3. The activity can be described as an operation of the system.
4. The control flow is drawn from one operation to another. 
5. This flow can be sequential, branched, or concurrent.
6. Basic purposes of activity diagrams is similar to other four diagrams. It
captures the dynamic behavior of the system. 
ACTIVITY DIAGRAM

1. Activity is a particular operation of the system.

2. It does not show any message flow from one activity to another. Activity diagram is
sometimes considered as the flowchart, look like a flowchart, they are not.
How to Draw an Activity Diagram?
Activity diagrams are mainly used as a flowchart that consists of activities performed by
the system.
These additional capabilities include branching, parallel flow, swimlane, etc.
Before drawing an activity diagram, we must have a clear understanding about the
elements used in activity diagram.
The main element of an activity diagram is the activity itself.
An activity is a function performed by the system. After identifying the activities, we need
to understand how they are associated with constraints and conditions.
• Before drawing an activity diagram, we should identify the following elements
• Activities
• Association
• Conditions
• Constraints
1.  In the diagram, four activities are identified which are associated with conditions. 
2. Following diagram is drawn with the four main activities −
• Send order by the customer
• Receipt of the order
• Confirm the order
• Dispatch the order
ACTIVITY DIAGRAM
ACTIVITY DIAGRAM
ORDERING SYSTEM
FOR RAILWAY RESERVATION
SYSTEM
WHERE TO USE DIAGRAMS?

1. This diagram is used to model the activities which are nothing but business
requirements.
2. The diagram has more impact on business understanding rather than on
implementation details.
Activity diagram can be used for −
• Modeling work flow by using activities.
• Modeling business requirements.
• High level understanding of the system's functionalities.
• Investigating business requirements at a later stage.
NOTATION OF ACITIVITY DIAGRAM

Activity diagram constitutes following

notations:
1. Initial State: It depicts the initial stage
or beginning of the set of actions.
2. Final State: It is the stage where all the
control flows and object flows end.
3. Decision Box: It makes sure that the
control flow or object flow will follow
only one path.
4. Action Box: It represents the set of
actions that are to be performed
 COMPONENTS OF ACTIVITY
DIAGRAM
1. The control flow of activity is represented by control nodes and object nodes that
illustrates the objects used within an activity.
2. The activities are initiated at the initial node and are terminated at the final node

Activity partition /swimlane

3. The swimlane is used to cluster all the related activities in one column or one row.
4. It can be either vertical or horizontal.
5. It used to add modularity to the activity diagram. It is not necessary to incorporate
swimlane in the activity diagram. But it is used to add more transparency to the activity
diagram.
1. Swimlane

Forks
2. Forks and join nodes generate the concurrent flow inside the activity.
3. A fork node consists of one inward edge and several outward edges.
4. It is the same as that of various decision parameters.
5. Whenever a data is received at an inward edge, it gets copied and split crossways various
outward edges.
6. It split a single inward flow into multiple parallel flows.
INTERACTION DIAGRAM 
1. Used in UML to establish communication between objects.
2. It does not manipulate the data associated with the particular communication path.
3. Interaction diagrams mostly focus on message passing and how these messages
make up one functionality of a system.
4. Interaction diagrams are designed to display how the objects will realize the
particular requirements of a system.
5. The critical component in an interaction diagram is lifeline and messages.
6. Interaction can be shown using several notations such as sequence diagram, timing
diagram, communication/collaboration diagram. Interaction diagrams capture the
dynamic behavior of any system.
TYPES OF INTERACTION
DIAGRAMS DEFINED IN UML

SEQUENCE DIAGRAM

COLLABORTATION DIAGRAM

TIMING DIAGRAM
SEQUENCE DIAGRAM

1. Purpose of a sequence diagram in UML is to visualize the sequence of a message

flow in the system.
2. The sequence diagram shows the interaction between two lifelines as a time-ordered
sequence of events.
Collaboration diagram is also called as a communication diagram.
2. The purpose of a collaboration diagram is to emphasize structural aspects of a
system, i.e., how various lifelines in the system connects.
Timing diagrams focus on the instance at which a message is sent from one object to
another object.
SEQUENCE DIAGRAM 

•  Sequence diagram shows an implementation of a scenario in the system. Lifelines

in the system take part during the execution of a system.
• In a sequence diagram, a lifeline is represented by a vertical bar.
• A message flow between two or more objects is represented using a vertical dotted
line which extends across the bottom of the page.
• In a sequence diagram, different types of messages and operators are used which
are described above.
NOTATIONS OF A SEQUENCE
DIAGRAM
1. Lifeline
An individual participant in the sequence diagram is represented by a lifeline. It is
positioned at the top of the diagram.
ACTOR
1. A role played by an entity that interacts with the subject is called as an actor.
2. It is out of the scope of the system.
3. It represents the role, which involves human users and external hardware or
subjects.
4. An actor may or may not represent a physical entity, but it purely depicts the role
of an entity.
5. Several distinct roles can be played by an actor or vice versa.
ACTIVATION

1. It is represented by a thin rectangle on the lifeline.

2. It describes that time period in which an operation is performed by an element,
such that the top and the bottom of the rectangle is associated with the initiation
and the completion time, each respectively.
 MESSAGES

1. The messages depict the interaction between the objects and are represented by
arrows.
2. They are in the sequential order on the lifeline. The core of the sequence diagram
is formed by messages and lifelines.
Tyes of messages enlisted below:
• Call Message: It defines a particular communication between the lifelines of an
interaction, which represents that the target lifeline has invoked an operation.
1. Return Message: It defines a particular communication between the lifelines of
interaction that represent the flow of information from the receiver of the
corresponding caller message
1. Self Message: It describes a communication, particularly between the lifelines of
an interaction that represents a message of the same lifeline, has been I
2. Recursive Message: A self message sent for recursive purpose is called a
recursive message.
3. In other words, it can be said that the recursive message is a special case of the self
message as it represents the recursive calls invoked.
4. Create Message: It describes a communication, particularly between the lifelines
of an interaction describing that the target (lifeline) has been instantiated.
1. Destroy Message: It describes a communication, particularly between the lifelines
of an interaction that depicts a request to destroy the lifecycle of the target.
2. Duration Message: It describes a communication particularly between the
lifelines of an interaction, which portrays the time passage of the message while
modeling a system.
1. sequence diagram contains lifeline notations and notation of various messages used
in a sequence diagram such as a create, reply, asynchronous message, etc.
1. following sequence diagram example represents McDonald's ordering system:
ORDERED SEQUENCE OF EVENTS

1. Place an order.
2. Pay money to the cash counter.
3. Order Confirmation.
4. Order preparation.
5. Order serving.
6. If one changes the order of the operations, then it may result in crashing the
program.
7. It can also lead to generating incorrect or buggy results. Each sequence in the
above-given sequence diagram is denoted using a different type of message.
BENEFITS OF A SEQUENCE
DIAGRAM

• Sequence diagrams are used to explore any real application or a system.

• Sequence diagrams are used to represent message flow from one object to another
object.
• Sequence diagrams are easier to maintain.
• Sequence diagrams are easier to generate.
Drawbacks of a sequence diagram
• Sequence diagrams can become complex when too many lifelines are involved in the
system.
• If the order of message sequence is changed, then incorrect results are produced. Each
sequence needs to be represented using different message notation, which can be a little
complex.
COLLABORATION DIAGRAM
1. The relationships and interactions among software objects. They are used to
understand the object architecture within a system rather than the flow of a
message as in a sequence diagram. They are also known as “Communication
Diagrams.”
TIMING DIAGRAM
FOR EXAMPLE

1. For example, the SafeHome security function makes use of a control panel that allows a homeowner to control
certain aspects of the security function.
2. In an advanced version of the system, control panel functions may be implemented via a wireless PDA or
mobile phone.
3. The ControlPanel class provides the behavior associated with a keypad, and therefore, it must implement the
operations
4. readKeyStroke () and decodeKey ().
5. If these operations are to be provided to other classes, it is useful to define an interface as shown in the figure.
6. The interface, named KeyPad, is shown as an <> stereotype or as a small, labeled circle connected to the class
with a line.
7. The interface is defined with no attributes and the set of operations that are necessary to achieve the behavior of
a keypad.
8. The dashed line with an open triangle at its end indicates that the ControlPanel class provides KeyPad
operations as part of its behavior., this
DESIGN
SAMPLES
USER ANALYSIS

1. Spend some time understanding the user before worrying about technical matters
2. In addition, the user’s mental image may be vastly different from the software
engineer’s design model.
3. The only way that you can get the mental image and the design model to converge
is to work to understand the users themselves as well as how these people will use
the system.
1. User Interviews. The most direct approach, members of the software team meet with
end users to better understand their needs, motivations, work culture, and a issues
2. Sales input: Sales people meet with users on a regular basis and can gather information
that will help the software team to categorize users and better understand their
requirements.
3. Marketing input: Market analysis can be invaluable in the definition of market
segments
4. Understanding of how each segment might use the software in subtly different ways.
5. Support input: Support staff talks with users on a daily basis.
6. They are the most likely source of information on what works and what doesn’t,
7. what users like and what they dislike, what features generate questions and what
features are easy to use.
WHAT IS ARCHITECTURE?
1. When you consider the architecture of a building, many different attributes come
to mind.
2. At the most simple level, you think about the overall shape of the physical
structure.
3. But in reality, architecture is much more. It is the manner in which the various
components of the building are integrated to form a cohesive whole.
4. It is the degree to which the building meets its stated purpose and satisfies the
needs of its owner.
5. It is the aesthetic feel of the structure—the visual impact of the building—and the
way textures, colors, and materials are combined to create the external facade and
the internal “living environment.”
IS IT SOFTWARE???

1. The architecture is not the operational software.

2. Rather, it is a representation that enables you to
(1) analyze the effectiveness of the design in meeting its stated requirements,
(2) consider architectural alternatives at a stage when making design changes is still
relatively easy, and
(3) reduce the risks associated with the construction of the software
WHY IS ARCHITECTURE
IMPORTANT?

1. Representations of software architecture are an enabler for communication

between all parties (stakeholders) interested in the development of a computer-
based system.
2. The architecture highlights early design decisions that will have a profound
impact on all software engineering work that follows and, as important, on the
ultimate success of the system as an operational entity.
3. Architecture “constitutes a relatively small, intellectually graspable model of how
the system is structured and how its components work together”
A DESIGN PYRAMID FOR WEBAPP

• The creation of an effective design will

typically require a diverse set of skills.
• Sometimes, for small projects, a single
developer may need to be multi-skilled. 
• For larger projects, it may be advisable
and/or feasible to draw on the expertise of
specialists:
• Web engineers,
• Graphic designers,
• Content developers,
• Programmers,
• Database specialists,

70
Interface Design Workflow for WebApps
• Information contained within the requirements model forms the basis for ,
• creation of a screen layout that depicts graphical design and placement of icons, definition of
descriptive screen text, specification and titling for windows, and specification of major and minor
menu items.

Tools are used to prototype and ultimately implement the interface design model.

1.Review information contained in the requirements model and refine as required.

2. Develop a rough sketch of the WebApp interface layout
MAPPING ACCORDING TO USER
OBJECTIVES
CONTIND….

3. Map user objectives into specific interface actions.

4. Define a set of user tasks that are associated with each action.
5. Storyboard screen images for each interface action
6. Refine interface layout and storyboards using input from aesthetic design.
7. Identify user interface objects that are required to implement the interface
8. Develop a procedural representation of the user’s interaction with the interface.
9. Develop a behavioral representation of the interface
10. Describe the interface layout for each state
11. Refine and review the interface design model
DIFFERENCES
DESIGN PATTERNS

1. A design pattern can be characterized as “a three-part rule which expresses a

relation between a certain context, a problem, and a solution.
2. It solves a problem: Patterns capture solutions, not just abstract principles or
strategies.
3. It is a proven concept: Patterns capture solutions with a track record, not theories.
DESIGN PATTERNS & TYPES
PATTERN CONTIND…
PATTERN-BASED
DESIGN IN
CONTEXT
• A software designer begins with a
requirements model (either explicit
or implied) that presents an
abstract representation of the
system.
• It may imply the design in an
abstract manner, but the
requirements model does little to
represent the design explicitly.
INTERFACE DESIGN CYCLE
1. The length and complexity of the requirements model or written specification of
the system and its interface provide an indication of the amount of learning
required by users of the system.
2. The number of user tasks specified and the average number of actions per task
provide an indication of interaction time and the overall efficiency of the system.
3. The number of actions, tasks, and system states indicated by the design model
imply the memory load on users of the system.
4. Interface style, help facilities, and error handling protocol provide a general
indication of the complexity of the interface and the degree to which it will be
accepted by the user
1. Architecture design is tied to the goals established for a WebApp, the content to be
presented, the users who will visit, and the navigation philosophy that has been
established.
2. As an architectural designer, you must identify content architecture and WebApp
architecture.
3. Content Architecture The design of content architecture focuses on the definition
of the overall hypermedia structure of the WebApp.
4. Although custom architectures are sometimes created, you always have the option
of choosing from four different content structures
LINEAR STRUCTURES
1. Linear structures are encountered when a predictable sequence of interactions is
common.
EX:A classic example might be a tutorial presentation in which pages of information
along with related graphics, short videos, or audio are presented only after prerequisite
information has been presented.
GRID STRUCTURES
1. Are an architectural option that you can apply when WebApp content can be
organized categorically in two (or more) dimensions.
2. For example, consider a situation in which an e-commerce site sells golf clubs.
The horizontal dimension of the grid represents the type of club to be sold (e.g.,
woods, irons, wedges, putters). The vertical dimension represents the offerings
provided by various golf club manufacturers
HIERARCHICAL STRUCTURES

1. Hierarchical structures are undoubtedly the most common WebApp architecture.

That encourage flow of control only along vertical branches of the hierarchy, a
WebApp hierarchical structure can be designed in a manner that enables (via
hypertext branching) flow of control horizontally across vertical branches of the
structure
NAVIGATION DESIGN

1. Navigation design begins with a consideration of the user hierarchy and related use
cases developed for each category of user (actor).
2. Each actor may use the WebApp somewhat differently and therefore have different
navigation requirements.
3. In addition, the use cases developed for each actor will define a set of classes that
encompass one or more content objects or WebApp functions.
NAVIGATION SYNTAX

1. As design proceeds, your next task is to define the mechanics of navigation.

2. A number of options are available as you develop an approach for implementing
each ND:
3. Individual navigation link—includes text-based links, icons, buttons and switches,
and graphical metaphors.
4. You must choose navigation links that are appropriate for the content and
consistent with the heuristics that lead to high-quality interface design.
5. Horizontal navigation bar—lists major content or functional categories in a bar
containing appropriate links. In general, between four and seven categories are
listed.
1. Vertical navigation column—(1) lists major content or functional categories, (2)
lists virtually all major content objects within the WebApp. If you choose the
second option, such navigation columns can “expand” to present content objects as
part of a hierarchy.
2. Tabs—a metaphor that is nothing more than a variation of the navigation bar or
column, representing content or functional categories as tab sheets that are
selected when a link is required.
3. Site maps—provide an all-inclusive table of contents for navigation to all content
objects and functionality contained within the WebApp.
VERTICAL NAVIGATON
WITH PRIMARY MENU ICONS
WITHOUT PRIMARY MENU ICONS
BREAD CRUMBS
BREADCRUMBS

1. Breadcrumbs display a users location within an application hierarchy. They

act as a resource to help users navigate more efficiently and provide
additional context.
2. Breadcrumbs do not replace the back button for web applications and
should not be used to display how a user navigated. These are location
breadcrumbs that help expose the hierarchy, not the particular clicks of a
user.
3. Breadcrumbs are recommended when the primary and secondary navigation
items are not always exposed. For example, breadcrumbs will enhance an
application that uses vertical navigation or one that uses horizontal
navigation where secondary menus are hidden. When using breadcrumbs,
be sure to include them on every page throughout the application.
PROGRESS INDICATOR

1. Provides an indication of progress when an operation takes longer than n seconds.

2. ShoppingCart:Provides a list of items selected for purchase, Lists item, quantity,
product code, availability (in stock, out of stock), price, delivery information,
shipping costs, and other relevant purchase information. Also provides ability to
edit.
3. Wizard:Takes the user through a complex task one step at a time, providing
guidance for the completion of the task through a series of simple window displays
QUALITY REQUIREMENT TREE
OBJECT ORIENTED DESIGN HYPERMEDIA DESIGN METHOD
(OOHDM)

1. Daniel Schwabe and his colleagues] originally proposed the Object-Oriented

Hypermedia Design Method (OOHDM), which is composed of four different
design activities: conceptual design, navigational design, abstract interface design,
and implementationdesign activities
2. OOHDM conceptual design creates a representation of the subsystems, classes,
and relationships that define the application domain for the WebApp.
3. The class diagrams, aggregations, and related information developed as part of
WebApp analysis are reused during conceptual design to represent relationships
between classes
UML CONITND……

1. Relationships in UML diagram are used to represent a connection between various

thingFollowing are the different types of standard relationships in UML,
• Association
• Dependency
• Generalization
• Realization
1. It is a structural relationship that represents objects can be connected or associated with
another object inside the system. Following constraints can be applied to the UML
Association relationship.
• implicit – Implicit constraints specify that the relationship is not manifest; it is based
upon a concept.
• ordered – Ordered constraints specify that the set of objects at one end of an association
are in a specific way.
• changeable – Changeable constraint specifies that the connection between various
objects in the system can be added, removed, and modified as per the requirement.
• addOnly– It specifies that the new connections can be added from an object which is
situated at the other end an association.
EXAMPLE:

1. Let us consider an example of a class fruit.

2. The fruit class has two instances, such as mango and apple. Reflexive association
states that a link between mango and apple can be present as they are instances of
the same class, such as fruit
3. The directed association is related to the direction of flow within association
classes.In a directed association, the flow is directed
1.  The association from one class to another class flows in a single direction only.
2. It is denoted using a solid line with an arrowhead.
Composition
3. It is not a standard UML Relationship, but it is still used in various applications.
4. Composite aggregation is a subtype of aggregation relation with characteristics as:
• It is a two-way association between the objects.
• It is a whole/part relationship.
• If a composite is deleted, all other parts associated with it are deleted.
1. Composite aggregation is described as a binary association decorated with a filled
black diamond at the aggregate (whole) end.
2. The folder could contain many files, while each File has exactly one Folder parent.
If a folder is deleted, all contained files are removed as well
1.  In a windowing system, a Frame belongs to precisely one Window. In a composite
aggregation, the whole system is responsible for the disposition of its parts.which
means that the composite must manage the creation and destruction of its parts
Aggregation
2. An aggregation is a subtype of an association relationship in UML. 
3. Aggregation and composition are both the types of association relationship in
UML. 
4. Aggregation relationship can be described in simple words as "an object of one
class can own or access the objects of another class."
1.  car needs a wheel to function correctly, but a wheel doesn't always need a car. It
can also be used with the bike, bicycle, or any other vehicles.
2. But not a particular car. Here, the wheel object is meaningful even without the car
object. Such type of relationship is called UML Aggregation relation.
UML CLASS DIAGRAM