Software Engineering

INSTRUCTOR: MS. SONIA RAFAQAT

Software Design and Architecture
 Models in Design

Model is an entity used to represent another entity(the target) by

establishing:
 a correspondence between the elements of the target

and the elements of the model

 and also correspondence between relationship among

the elements of the target and relationships between

the elements of the model.

 Models in Design

There are also parts and relationships in the target that are not captured in the

model, and parts and relationships in the model that do not correspond to

anything in the target. This highlights the fact that models are not perfect

renditions of their targets.

(Note: Discussed this in detail in class with the help of railroad model

example)
 Models in Design

 Abstraction is essential in modeling. Models represent only some of the

parts, properties, and relationships of a target otherwise they would be

copies rather than models. The fact that models are abstractions of their

targets is the key to the greatest strengths of modeling.

 Abstraction is also the source of the greatest weakness of modeling. If

important parts or relationships are missing from a model, or if the

behaviors or properties of the model do not closely enough approximate

 Models in Design

the behaviors and properties of the target, a model can produce

misunderstandings leading to incorrect predictions, conclusions, and

solutions. Knowing how and what to abstract is a key skill in modeling. So is

the ability to use models with an understanding of what they can't do.

Modeling in Design

If design is problem solving, then one might expect modeling to be a central

tool in all design disciplines. Models are useful in design in three ways:
 Models in Design

1. Problem Understanding

Designers must understand design problems and constraints before they can

create solutions. Models can help represent and explore problems.

2. Design Creation and Investigation

Floor plans, elevations, schematics, blueprints, and diagrams of all sorts are

the mainstays of design creation and investigation in most disciplines.

 Models in Design

Mock-ups, partial implementations, and physical scale models are also

widely used and allow investigation through simulation and testing.

3. Documentation

Models developed to understand, create, and investigate are also used to

document designs for implementation and maintenance. Additional models

are sometimes made just for documentation.

 Models in Design

Most software design models are symbolic representations, though programs

that implement part of the final result (prototypes) are sometimes used.

Software design problems and solutions are often complex, and many aspects

of software systems must be modeled. Consequently, many kinds of models

are used in software design.

 Models in Design

Software design models may be divided into two broad classes:

 Static models
Software Design Model
 Dynamic models

Dynamic
Static Model
Model
 Models in Design

Static models

 A static design model represents aspects of programs that do not change

during program execution.

Dynamic model

 A dynamic design model represents what happens during program

execution.
 Modeling with UML
(Need)

 Notations enable us to articulate complex ideas briefly and precisely. In

projects involving many participants, often of different technical and

cultural backgrounds, accuracy and clarity are critical as the cost of

miscommunication increases rapidly. For a notation to enable accurate

communication, it must come with a well-defined semantics, it must be

well suited for representing a given aspect of a system, and it must be well

understood among project participants.

 UML

 We selected UML (Unified Modeling Language) as a primary notation for

this course because it provides a spectrum of notations for representing

different aspects of a system and has been accepted as a standard notation

in the industry.

 UML is a notation that resulted from the unification of OMT (Object

Modeling Technique), Booch and OOSE (Object-Oriented Software

Engineering). UML has also been influenced by other object-oriented

 UML

 The goal of UML is to provide a standard notation that can be used by all

object-oriented methods and to select and integrate the best elements of

precursor notations. For example, UML includes the use case diagrams

introduced by OOSE and uses many features of the OMT class diagrams.

UML also includes new concepts that were not present in other major

methods at the time, such as extension mechanisms and a constraint

language. UML has been designed for a broad range of applications.

 UML

 Hence, it provides constructs for a broad range of systems and activities

(e.g., distributed systems, analysis, system design, deployment).

 System development focuses on three different models of the system:

1. The functional model

2. The Object model

3. The dynamic model

 System Models

The functional Model

The functional model, represented in UML with use case diagrams, describes

the functionality of the system from the user’s point of view.

The Object model

The object model, represented in UML with class diagrams, describes the

structure of the system in terms of objects, attributes, associations, and

 System Models

The dynamic Model

The dynamic model, represented in UML with interaction diagrams, state

machine diagrams, and activity diagrams, describes the internal behavior of

the system. Interaction diagrams describe behavior as a sequence of messages

exchanged among a set of objects, whereas state machine diagrams describe

behavior in terms of states of an individual object and the possible transitions

between states. Activity diagrams describe behavior in terms control and data
 UML

We will study five UML notations:

 Use Case Diagrams

 Class Diagrams

 Interaction Diagrams

 State Machine Diagrams

 Activity Diagrams
Use Case Diagrams
 Use Case Diagrams

 Use cases are used during requirements elicitation and analysis to represent

the functionality of the system. Use cases focus on the behavior of the

system from an external point of view. A use case describes a function

provided by the system that yields a visible result for an actor.

 An actor describes any entity that interacts with the system (e.g., a user,

another system, the system’s physical environment). The identification of

actors and use cases results in the definition of the boundary of the system.
 Use Case Diagrams

 The actors are outside the boundary of the system, whereas the use cases

are inside the boundary of the system. Then we have relationships between

actors and use cases. Different type of relationships are:

 Association

 Include

 Extend

 Generalization
 Use Case Diagrams

 Take the example of a use case diagram for a simple watch. The Watch

User actor may either consult the time on their watch (with the Read Time

use case) or set the time (with the Set Time use case). However, only the

Watch Repair Person actor can change the battery of the watch (with the

Change Battery use case).

Use Case Diagram for Simple Watch

Actors are represented with stick figures, use cases with ovals, and
the boundary of the system with a box enclosing the use cases .
Straight lines show association.
Use Case Diagram for online Banking
Class Diagrams
 Class Diagrams

 The Unified Modeling Language (UML) can help you model systems in

various ways. One of the more popular types in UML is the class diagram.

Popular among software engineers to document software architecture, class

diagrams are a type of structure diagram because they describe what must

be present in the system being modeled.

 Class Diagrams

The standard class diagram is composed of three sections:

 Upper section: Contains the name of the class. This section is

always required, whether you are talking about the

classifier or an object.

 Middle section: Contains the attributes of the class. Use this section to

describe the qualities of the class. This is only required when describing a

specific instance of a class.

 Class Diagrams

 Bottom section: Includes class operations (methods). Displayed in list

format, each operation takes up its own line. All classes have different

access levels depending on the access modifier (visibility). Here are the

access levels with their corresponding symbols:

 Public (+)

 Private (-)

 Protected (#)

 Package (~)
 Class Diagrams

Relationships:

 Inheritance/Generalization

 Association

 Aggregation

 Composition

 Multiplicity
 Inheritance

 Refers to a type of relationship where in one associated class is a child of

another by virtue of assuming the same functionalities of the parent class.

In other words, the child class is a specific type of the parent class. To

show inheritance in a UML diagram, a solid line from the child class to the

parent class is drawn using an unfilled arrowhead.

 Parent class or super class also represent the abstract class. Abstraction is

used to keep the code DRY (Don’t Repeat Yourself). The example of zoo

system in the upcoming slide show the inheritance.

 Inheritance

Inheritance Inheritance Inheritance

 Association

 Association is a broad term that encompasses just about any logical

connection or relationship between classes. The up coming slide shows
association between Otter and sea Urchin.

ssociation
 Aggregation

 Aggregation refers to the formation of a particular class as a result of

one class being aggregated or built as a collection. In aggregation, the

contained classes are not strongly dependent on the lifecycle of the

container. Or in other words aggregation is that type of relationship

where part exist outside the whole.

 Aggregation is denoted by a line with an empty diamond.

 Aggregation

Aggregation
 Composition

 The composition relationship is very similar to the aggregation

relationship with the only difference being its key purpose of

emphasizing the dependence of the contained class to the life cycle of

the container class. Or that type of relationship where part can’t exist

outside the whole. Composition is denoted by a line with a filled

diamond. Lets continue with the same zoo system example and consider

another class “Visitor Center”.

Composition

Composition
 Multiplicity

 Multiplicity allows you to set numeric constraints on your relationship.

For example in the visitor center example, we want to specify that our

visitor center will have just one lobby and at least one washroom we

will simply write 1 on lobby relationship and 1..*. Other type of

multiplicity relationships are:

Multiplicity
Class diagram for online shopping cart
 Class diagram for Simple Watch

• a Simple Watch has exactly two Push Buttons, one Display, two
Batteries, and one Time. Similarly, all Push Button, Display, Time, and
Battery objects are associated with exactly one Simple Watch object.
Interaction Diagrams
 Interaction Diagrams

 Interaction diagrams are used to formalize the dynamic behavior of the

system and to visualize the communication among objects. They are

useful for identifying additional objects that participate in the use cases.

We call objects involved in a use case participating objects. An

interaction diagram represents the interactions that take place among

these objects. In the upcoming slide there is a special form of interaction

diagram, called a sequence diagram, for the Set Time use case of our
 Interaction Diagrams

simple watch. The left-most column represents the Watch User actor who

initiates the use case. Labeled arrows represent stimuli that an actor or an

object sends to other objects. In this case, the Watch User presses button 1

twice and button 2 once to set her watch a minute ahead. The Set Time use

case terminates when the Watch User presses both buttons simultaneously.
Interaction Diagram for Simple Watch
State Machine
Diagrams
 State Machine Diagrams

 State machine diagrams describe the dynamic behavior of an individual

object as a number of states and transitions between these states. A state

represents a particular set of values for an object. Given a state, a

transition represents a future state the object can move to and the

conditions associated with the change of state. In the upcoming slide

there is a state machine diagram for the Watch. A small black circle

initiates that Blink Hours is the initial state. A circle surrounding a small
 State Machine Diagrams

 black circle indicates that Stop Blinking is a final state. The diagram

represents different information than the sequence diagram. The

sequence diagram focuses on the messages exchanged between objects

as a result of external events created by actors. The state machine

diagram focuses on the transitions between states as a result of external

events for an individual object.

State Machine Diagram for Simple Watch

A UML state machine diagram for Set Time use case of

the Watch.
Activity Diagrams
 Activity Diagrams

 An activity diagram describes an activity by showing the actions into

which it is decomposed and the flow of control and data between them.

An activity in UML is a non-atomic task or procedure decomposable

into actions, where an action is a task or procedure that cannot be

broken into parts, and hence is atomic. Ultimately, all activities must be

decomposable into actions, so actions are the basic units of process

activity. Actions and activities can be anything that humans, machines,

organizations, or other entities do.

 Activity Diagrams

 An activity diagram has activity nodes representing actions or objects

and activity edges representing control or data flows. An action node is

represented by an action node symbol, which is a rounded rectangle

containing arbitrary text naming or describing some action. Activity

edges are represented by solid arrows with unfilled arrow heads. The

example on the upcoming slide shows a simple activity diagram for

laundry system with several action nodes connected by activity edges.

Activity Diagrams
 Activity Diagrams

 Activity diagrams can be regarded as specifications of virtual machines

whose basic computations are given by the diagrams' action nodes.
These virtual machines compute using tokens, which are markers (not
represented on the diagram) passed around during execution. Tokens are
produced and consumed by nodes and flow instantaneously along
edges. An action node begins executing when tokens are available on all
its incoming edges. When an action; node begins execution, it consumes
these tokens. When it completes execution, it produces new tokens and
makes them available on all its outgoing edges.
 Activity Diagrams

 Two more things are needed to produce a complete activity graph: A

way to start execution and a way to stop it. A special initial node,

represented by a small filled circle, can have only a single outgoing

edge. It produces a token and makes it available when an activity

begins. Execution stops when tokens can no longer flow through the

diagram, but the end of an activity can also be indicated explicitly (or

forced) using an ending node, represented by a small filled circle within

another circle (a bull's eye).

 Activity Diagrams

 Edges can only enter an activity final

node. When a token is available on one
of the nodes entering it, an activity final
node consumes the token and terminates
the activity (by removing all tokens from
the virtual machine).
 Activity Diagrams

 Activity diagrams also provide flow branching. Branching is based on

the value of Boolean (true or false) expressions. A Boolean expression
placed inside square brackets and used to label a control flow is called a
guard. Flow branching is shown on an activity diagram using a decision
node represented by a diamond. A decision node can have only a single
edge entering it but several edges leaving it, each labeled with a guard.
Branched flows can rejoin at a merge node, also represented by a
diamond, but with several edges entering it and only a single edge
leaving it.
Activity Diagrams
 Activity Diagrams

Two additional nodes provide more control over concurrent execution and
synchronization in activity diagrams. A fork node, represented by a thick
line, has one edge entering it and multiple edges leaving it. A token
available on the entering edge is reproduced and made available on all the
outgoing edges. This effectively starts several concurrent threads of
execution. A join node, also represented by a thick line, has multiple edges
entering it, but only one edge leaving it. Tokens must be available on all
entering edges before a token is made available on the outgoing edge. A
join node synchronizes concurrent threads of execution.
Activity Diagrams
 Activity Diagrams

 Control is not the only thing that

flows through a process: Data does
too. Data and objects are shown in
activity diagrams as object nodes
represented by rectangles containing
data or object type names. An object
node rectangle may also specify the
state of the data or object in square
brackets following the name.
 Activity Diagrams

 A pin is a square attached to an action node that serves as a terminator

for data flows into or out of the action node. Each pin must either have a

single edge entering it (an input pin) or leaving it (an output pin). The

name of the data or object type appears beside the pin, a description of

the state of the data or object can appear after the name in square

brackets, just as with an object node. Pins are simply an alternative way

to show data flows indicated by object nodes.

Activity Diagrams
 Activity Diagrams

 Processes consume input and produce output, so activity diagram need a

way to represent this. An activity parameter is an object node placed on
the boundaries of an activity symbol to represent data or object inputs or
outputs. Input activity parameters have only outgoing arrows, and
output activity parameters have only incoming arrows. It is an error to
have both incoming and outgoing edges on an activity parameter.
Parameter types are indicated by listing each parameter's name and type
just below the activity name at the top left-hand corner of the activity
symbol. The format for these specifications is:
parameter-name : parameter-type
Activity Diagrams
Activity Diagram for online
Registration

Part -1 of diagram
Food for Thought

Your Level of
Success is
Determined by
your Level of
Disciplin