Sub.

Name: Software Engineering

MAHARAJA INSTITUTE OF
TECHNOLOGY MYSORE
Sub Code : 22MCA23
DEPARTMENT OF MASTER OF
COMPUTER APPLICATIONS

Software Engineering

System Modeling
Reference: Sommerville, Software Engineering, 10 ed., Chapter 5

The big picture

System modeling is the process of developing abstract models of a system, with each model presenting
a different view or perspective of that system. It is about representing a system using some kind of
graphical notation, which is now almost always based on notations in the Unified Modeling
Language (UML). Models help the analyst to understand the functionality of the system; they are used to
communicate with customers.
Models can explain the system from different perspectives:

• An external perspective, where you model the context or environment of the system.
• An interaction perspective, where you model the interactions between a system and its
environment, or between the components of a system.
• A structural perspective, where you model the organization of a system or the structure of
the data that is processed by the system.
• A behavioral perspective, where you model the dynamic behavior of the system and how it
responds to events.

Five types of UML diagrams that are the most useful for system modeling:

• Activity diagrams, which show the activities involved in a process or in data processing.
• Use case diagrams, which show the interactions between a system and its environment.
• Sequence diagrams, which show interactions between actors and the system and between
system components.
• Class diagrams, which show the object classes in the system and the associations between
these classes.
• State diagrams, which show how the system reacts to internal and external events.

Models of both new and existing system are used during requirements engineering. Models of
the existing systems help clarify what the existing system does and can be used as a basis for discussing
its strengths and weaknesses. These then lead to requirements for the new system. Models of the new
system are used during requirements engineering to help explain the proposed requirements to other
system stakeholders. Engineers use these models to discuss design proposals and to document the system
for implementation.

Context models
Context models are used to illustrate the operational context of a system - they show what lies outside
the system boundaries. Social and organizational concerns may affect the decision on where to position
system boundaries. Architectural models show the system and its relationship with other systems.

System boundaries are established to define what is inside and what is outside the system. They show
other systems that are used or depend on the system being developed. The position of the system
boundary has a profound effect on the system requirements. Defining a system boundary is a political
judgment since there may be pressures to develop system boundaries that increase/decrease the influence
or workload of different parts of an organization.

Context models simply show the other systems in the environment, not how the system being developed is
used in that environment.

The example below shows a UML activity diagram describing the process of involuntary detention and
the role of MHC-PMS (mental healthcare patient management system) in it.

Interaction models
Types of interactions that can be represented in a model:

• Modeling user interaction is important as it helps to identify user requirements.

• Modeling system-to-system interaction highlights the communication problems that may
arise.
• Modeling component interaction helps us understand if a proposed system structure is
likely to deliver the required system performance and dependability.

Use cases were developed originally to support requirements elicitation and now incorporated into the
UML. Each use case represents a discrete task that involves external interaction with a system. Actors in a
use case may be people or other systems. Use cases can be represented using a UML use case diagram
and in a more detailed textual/tabular format.

Simple use case diagram:

Use case description in a tabular format:

Use case title Transfer data

Description A receptionist may transfer data from the MHC-PMS to a general patient record database
that is maintained by a health authority. The information transferred may either be
 updated personal information (address, phone number, etc.) or a summary of the
patient's diagnosis and treatment.

Actor(s) Medical receptionist, patient records system (PRS)

Patient data has been collected (personal information, treatment summary);

Preconditions The receptionist must have appropriate security permissions to access the patient
information and the PRS.

Postconditions PRS has been updated

1. Receptionist selects the "Transfer data" option from the menu.

Main success 2. PRS verifies the security credentials of the receptionist.
scenario 3. Data is transferred.
4. PRS has been updated.

2a. The receptionist does not have the necessary security credentials.
Extensions 2a.1. An error message is displayed.
2a.2. The receptionist backs out of the use case.

UML sequence diagrams are used to model the interactions between the actors and the objects within a
system. A sequence diagram shows the sequence of interactions that take place during a particular use
case or use case instance. The objects and actors involved are listed along the top of the diagram, with a
dotted line drawn vertically from these. Interactions between objects are indicated by annotated arrows.

Structural models
Structural models of software display the organization of a system in terms of the components that
make up that system and their relationships. Structural models may be static models, which show the
structure of the system design, or dynamic models, which show the organization of the system when it is
executing. You create structural models of a system when you are discussing and designing the system
architecture.
UML class diagrams are used when developing an object-oriented system model to show the classes in a
system and the associations between these classes. An object class can be thought of as a general
definition of one kind of system object. An association is a link between classes that indicates that there is
some relationship between these classes. When you are developing models during the early stages of the
software engineering process, objects represent something in the real world, such as a patient, a
prescription, doctor, etc.

Generalization is an everyday technique that we use to manage complexity. In modeling systems, it is

often useful to examine the classes in a system to see if there is scope for generalization. In object-
oriented languages, such as Java, generalization is implemented using the class inheritance mechanisms
built into the language. In a generalization, the attributes and operations associated with higher-level
classes are also associated with the lower-level classes. The lower-level classes are subclasses inherit the
attributes and operations from their superclasses. These lower-level classes then add more specific
attributes and operations.
An aggregation model shows how classes that are collections are composed of other classes. Aggregation
models are similar to the part-of relationship in semantic data models.

Behavioral models
Behavioral models are models of the dynamic behavior of a system as it is executing. They show what
happens or what is supposed to happen when a system responds to a stimulus from its environment. Two
types of stimuli:

• Some data arrives that has to be processed by the system.

• Some event happens that triggers system processing. Events may have associated data,
although this is not always the case.

Many business systems are data-processing systems that are primarily driven by data. They are controlled
by the data input to the system, with relatively little external event processing. Data-driven
models show the sequence of actions involved in processing input data and generating an associated
output. They are particularly useful during the analysis of requirements as they can be used to show end-
to-end processing in a system. Data-driven models can be created using UML activity diagrams:

Data-driven models can also be created using UML sequence diagrams:

Real-time systems are often event-driven, with minimal data processing. For example, a landline phone
switching system responds to events such as 'receiver off hook' by generating a dial tone. Event-driven
models shows how a system responds to external and internal events. It is based on the assumption that
a system has a finite number of states and that events (stimuli) may cause a transition from one state to
another. Event-driven models can be created using UML state diagrams:
Rational Unified Process (RUP) A generic software process model that presents software
development as a four phase iterative activity, where the phases are inception, elaboration,
construction, and transition. Inception establishes a business case for the system, elaboration
defines the architecture, construction implements the system, and transition deploys the system in
the customer’s environment.

Figure 2.11 shows the phases in the RUP.

These are:

1. Inception The goal of the inception phase is to establish a business case for the system. You
should identify all external entities (people and systems) that will interact with the system and
define these interactions. You then use this information to assess the contribution that the system
makes to the business. If this contribution is minor, then the project may be cancelled after this
phase.

2. Elaboration The goals of the elaboration phase are to develop an understanding of the problem
domain, establish an architectural framework for the system, develop the project plan, and identify
key project risks. On completion of this phase you should have a requirements model for the system,
which may be a set of UML use-cases, an architectural description, and a development plan for the
software.

3. Construction The construction phase involves system design, programming, and testing. Parts of
the system are developed in parallel and integrated during this phase. On completion of this phase,
you should have a working software system and associated documentation that is ready for delivery
to users.

4. Transition The final phase of the RUP is concerned with moving the system from the development
community to the user community and making it work in a real environment. This is something that
is ignored in most software process models but is, in fact, an expensive and sometimes problematic
activity. On completion of this phase, you should have a documented software system that is
working correctly in its operational environment. Iteration within the RUP is supported in two ways.

Object-oriented design using the UML An object-oriented system is made up of interacting objects
that maintain their own local state and provide operations on that state. The representation of the
state is private and cannot be accessed directly from outside the object. Object-oriented design
processes involve designing object classes and the relationships between these classes. These classes
define the objects in the system and their interactions. When the design is realized as an executing
program, the objects are created dynamically from these class definitions. Object-oriented systems
are easier to change than systems developed using functional approaches. Objects include both data
and operations to manipulate that data. They may therefore be understood and modified as stand-
alone entities. Changing the implementation of an object or adding services should not affect other
system objects. Because objects are associated with things, there is often a clear mapping between
realworld entities (such as hardware components) and their controlling objects in the system. This
improves the understandability, and hence the maintainability, of the design. To develop a system
design from concept to detailed, object-oriented design, there are several things that you need to do:
1. Understand and define the context and the external interactions with the system.
2. Design the system architecture.
3. Identify the principal objects in the system.
4. Develop design models. 5. Specify interfaces.

Design patterns :-The pattern is a description of the problem and the essence of its solution, The
pattern is not a detailed specification. Rather, you can think of it as a description of accumulated
wisdom and experience, a well-tried solution to a common problem. Published patterns often rely on
object characteristics such as inheritance and polymorphism to provide generality. However, the
general principle of encapsulating experience.

pattern is one that is equally applicable to any kind of software design. So, you could have
configuration patterns for COTS systems. Patterns are a way of reusing the knowledge and experience
of other designers. The four essential elements of design patterns were defined by the ‘Gang of Four’
in their patterns book:

1. A name that is a meaningful reference to the pattern.

2. A description of the problem area that explains when the pattern may be applied.

3. A solution description of the parts of the design solution, their relationships, and their
responsibilities. This is not a concrete design description. It is a template for a design solution that can
be instantiated in different ways. This is often expressed graphically and shows the relationships
between the objects and object classes in the solution.
4. A statement of the consequences—the results and trade-offs—of applying the pattern. This can
help designers understand whether or not a pattern can be used in a particular situation.

Implementation issues

Software engineering includes all the activities involved in software development from the initial
requirements of the system through to maintenance and management of the deployed system. A
critical stage of this process is, of course, system implementation, where you create an executable
version of the software. Implementation may involve developing programs in high- or low-level
programming languages or tailoring and adapting generic, off-the-shelf systems to meet the specific
requirements of an organization. I assume that most readers of this book will understand
programming principles and will have some programming experience. As this chapter is intended to
offer a language-independent approach, I have not focused on issues of good programming practice
as this has to use language-specific examples. Instead, I introduce some aspects of implementation
that are particularly important to software engineering that are often not covered in programming
texts. These are:

1. Reuse Most modern software is constructed by reusing existing components or systems. When you
are developing software, you should make as much use as possible of existing code.

2. Configuration management During the development process, many different versions of each
software component are created. If you don’t keep track of these versions in a configuration
management system, you are liable to include the wrong versions of these components in your
system.

3. Host-target development Production software does not usually execute on the same computer as
the software development environment. Rather, you develop it on one computer (the host system)
and execute it on a separate computer (the target system). The host and target systems are sometimes
of the same type but, often they are completely different.

Open source development is an approach to software development in which the source code of a
software system is published and volunteers are invited to participate in the development process.

• There was an assumption that the code would be controlled and developed by a small core
group, rather than users of the code.
• Open source software extended this idea by using the Internet to recruit a much larger
population of volunteer developers.
• Many of them are also users of the code. In principle at least, any contributor to an open
source project may report and fix bugs and propose new features and functionality. However,
in practice, successful open source systems still rely on a core group of developers who
control changes to the software.
• The best-known open source product is, of course, the Linux operating system which is
widely used as a server system and, increasingly, as a desktop environment. Other important
open source products are Java, the Apache web server, and the mySQL database
management system.
• Major players in the computer industry such as IBM and Sun support the open source
movement and base their software on open source products.
• There are thousands of other, lesser known open source systems and components that may
also be used.