Software Engineering

DESIGN AND IMPLEMENTATION

Object-oriented design using the UML

Note:

The Unified Modelling Language (UML) is a graphical language for Object-oriented

analysis and design (OOAD) that gives a standard way to write a software system's
blueprint. It helps to visualize, specify, construct, and document the artifacts of an
object-oriented system.

 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.
 The Unified Modelling Language (UML) is inherently object-oriented modelling language
and was designed for use in object-oriented software applications.
 The applications could be based on the object-oriented technologies recommended by
the Object Management Group (OMG), which owns the UML.
 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.
 To develop a system design from concept to detailed, object-oriented design,
there are several things that you need to do
 Understand and define the context and the external interactions with the system.
 Design the system architecture.
 Identify the principal objects in the system.
 Develop design models.
 Specify interfaces.

System context and interactions

 System context models and interaction models present complementary views of

the relationships between a system and its environment.
 A system context model is a structural model that demonstrates the other systems
in the environment of the system being developed.
 An interaction model is a dynamic model that shows how the system interacts
with its environment as it is used.

 The context model of a system may be represented using associations. Associations

simply show that there are some relationships between the entities involved in the
association and associations are as shown in below figure 1 and 2, which shows that the
systems in the environment of each weather station are a weather information system,
an onboard satellite system, and a control system.
 Figure_1 shows System context for the weather station.
 Software Engineering

 Figure_2 shows Weather Control station use cases.

 Software Engineering

Architectural design

 Once the interactions between the software system and the system’s environment
have been defined, we use this information as a basis for designing the system.
 Architecture along with the use of general knowledge of the principles of architectural
design and with more detailed domain knowledge.
 Next phase identify the major components that make up the system and their
interactions, and then may organize the components using an architectural pattern such
as a layered or client–server model.
 The high-level architectural design for the weather station software is shown in
below figure. The weather station is composed of independent subsystems that
communicate by broadcasting messages on a common infrastructure, shown as the
Communication link in below figure. Each subsystem listens for messages on that
infrastructure and picks up the messages that are intended for them.

Object class identification

 Object class identification is the act of identifying the attributes of entities and
discovery of the functionalities associated with the entity and defining the
relationship between different entities of the system and represent them in the
form of classes and creating the objects of the respective classes.
 There have been various proposals made about how to identify object classes in
object-oriented systems

 Use a grammatical analysis of a natural language description of the system to be

constructed. Objects and attributes are nouns; operations or services are verbs.
 Use tangible entities (things) in the application domain such as aircraft, roles
such as manager or doctor, events such as requests, interactions such as
meetings, locations such as offices, organizational units such as companies, and
so on.
 Use a scenario-based analysis where various scenarios of system use are
identified and analysed in turn. As each scenario is analysed, the team
responsible for the analysis must identify the required objects, attributes, and
operations.
 Software Engineering

 In the wilderness weather station, object identification is based on the tangible hardware
in the system is shown in below figure.

Design models

 Design or system models show the objects or object classes in a system. They
also show the associations and relationships between these entities.
 These models are the bridge between the system requirements and the implementation
of a system. They have to be abstract so that unnecessary detail doesn’t hide the
relationships between them and the system requirements. However, they also have to
include enough detail for programmers to make implementation decisions.
 When you use the UML to develop a design, you will normally develop two kinds
of design model.
 Structural models, which describe the static structure of the system using object
classes and their relationships. Important relationships that may be documented
at this stage are generalization (inheritance) relationships, uses/used-by
relationships, and composition relationships.
 Dynamic models, which describe the dynamic structure of the system and show
the interactions between the system objects. Interactions that may be documented
include the sequence of service requests made by objects and the state
changes that are triggered by these object interactions.
 In the early stages of the design process, I think there are three models that are
particularly useful for adding detail to use case and architectural models:
 Subsystem models, which that show logical groupings of objects into coherent
subsystems. These are represented using a form of class diagram with each
subsystem shown as a package with enclosed objects. Subsystem models are static
(structural) models.
 Sequence models, which show the sequence of object interactions. These are
represented using a UML sequence or a collaboration diagram. Sequence
models are dynamic models.
 State machine model, which show how individual objects change their state in
 Software Engineering

response to events. These are represented in the UML using state diagrams.
State machine models are dynamic models.

Interface specification

 An important part of any design process is the specification of the interfaces between
the components in the design.
 We need to specify interfaces so that objects and subsystems can be designed in
parallel. Once an interface has been specified, the developers of other objects may
assume that interface will be implemented.
 Interface design is concerned with specifying the detail of the interface to an object or to
a group of objects. This means defining the signatures and semantics of the
services that are provided by the object or by a group of objects.
 Interfaces can be specified in the UML using the same notation as a class diagram.
However, there is no attribute section and the UML stereotype ‹‹interface›› should be
included in the name part. The semantics of the interface may be defined using the
object constraint language (OCL).
 Below figure shows two interfaces that may be defined for the weather station. The
left-hand interface is a reporting interface that defines the operation names that are
used to generate weather and status reports.

 We should not include details of the data representation in an interface design,

as attributes are not defined in an interface specification.
 However, we should include operations to access and update data. As the data
representation is hidden, it can be easily changed without affecting the objects that use
that data.

Design patterns

 Patterns and Pattern Languages are ways to describe best practices, good
designs, and capture experience in a way that it is possible for others to reuse
this experience.
 To use patterns in our design, we need to recognize that any design problem we are
facing may have an associated pattern that can be applied. Examples of such
problems, documented in the ‘Gang of Four’s original patterns book, include
 Tell several objects that the state of some other object has changed (Observer
pattern).
 Tidy up the interfaces to several related objects that have often been developed
incrementally (Façade pattern).
 Provide a standard way of accessing the elements in a collection, irrespective of
how that collection is implemented (Iterator pattern).
 Software Engineering

 Allow for the possibility of extending the functionality of an existing class atrun-
time (Decorator pattern).

Note: Software architecture focuses more on the abstract view of idea while Design pattern
focuses on the implementation view of idea.

Implementation issues

Some of the pointes we need to consider during implementation is as follows.

 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.
 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.
 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.