Unit 3 (SE)
Unit 3 (SE)
Unit 3 (SE)
6. Accommodate change –
The software should be designed in such a way that it accommodates
the change implying that the software should adjust to the change that
is required to be done as per the user’s need.
7. Degrade gently –
The software should be designed in such a way that it degrades
gracefully which means it should work properly even if an error occurs
during the execution.
8. Assessed or quality –
The design should be assessed or evaluated for the quality meaning
that during the evaluation, the quality of the design needs to be
checked and focused on.
UML:-
Unified Modeling Language (UML) is a general-purpose modeling
language. The main aim of UML is to define a standard way to visualize the
way a system has been designed. It is quite similar to blueprints used in
other fields of engineering. UML is not a programming language, it is
rather a visual language.
1.Class Diagram:-
Class diagrams are a type of UML (Unified Modeling Language) diagram
used in software engineering to visually represent the structure and
relationships of classes in a system. UML is a standardized modeling
language that helps in designing and documenting software systems.
2. Class Diagram:-
An Object Diagram can be referred to as a screenshot of the instances in a
system and the relationship that exists between them. Since object diagrams
depict behaviour when objects have been instantiated, we are able to study
the behaviour of the system at a particular instant.
3. Component Diagram:-
Component diagrams are used to represent how the physical components in
a system have been organized. We use them for modelling implementation
details.
4. Deployment Diagram
Deployment Diagrams are used to represent system hardware and its
software.It tells us what hardware components exist and what software
components run on them.
ARCHITECTURAL DESIGN:
Establishing the overall structure of a software system.
Objectives:
1. To introduce architectural design and to discuss its importance
2. To explain why multiple models are required to document software architecture
to describe types of
3. architectural model that may be used.
4. A high-level model of a thing: -
5. Describes critical aspects of the thing Understandable to many stakeholders
6. Provides well understood tools and techniques for constructing the thing from its
blueprint.
The commonly used architectural styles are:
Data-centered Architectures: A data store (e.g., a file or database) resides at the center
of this architecture and is accessed frequently by other components that update, add,
delete, or otherwise modify data within the store. A typical Data-centered style. Clients of
the are accesses a central repository.
Call and return Architectures: The program structure can be easily modified or scaled. The
program structure is organized into modules within the program. In this architecture how
modules call each other. The program structure decomposes the function into control hierarchy
where a main program invokes number of program components.
Layered Architectures: A number of different layers are defined, each accomplishing
operation that progressively become closer to the machine instruction set. At the outer layer,
components service.
Logical view: The logical view is concerned with the functionality that the system provides to end-
users. UML diagrams are used to represent the logical view,
Process view: The process view deals with the dynamic aspects of the system, explains the system
processes and how they communicate, and focuses on the run time behavior of the system.
Development view: The development view (aka the implementation view) illustrates a system from
a programmer's perspective and is concerned with software management.
Views:-
views are used to describe the system from the viewpoint of different stakeholders, such as end-
users, developers, system engineers, and project managers. The four views of the model are logical,
development, process and physical view.
Physical view: The physical view (aka the deployment view) depicts the system from a system
engineer's point of view. It is concerned with the topology of software components on the physical
layer as well as the physical connections between these components.
Scenarios: The description of an architecture is illustrated using a small set of use cases, or
scenarios, which become a fifth view. The scenarios describe sequences of interactions between
objects and between processes.
Goals of SASD
Improve Quality and reduce the risk of system failure
Establish concrete requirements specifications and complete requirements documentation
Focus on Reliability, Flexibility, and Maintainability of system
Component Based Design:
Component-based architecture focuses on the decomposition of the design into individual
functional or logical components that represent well-defined communication interfaces
containing methods, events, and properties. It provides a higher level of abstraction and divides
the problem into sub-problems, each associated with component partitions.