ARBAMINCH UNIVERSTY INSTITUT OF

TECHNOLOGY

INDIVIDUAL ASSIGNMENT OF SOFTWARE DESIGN NAME………………..BEREKET

AMTATAW
ID NO………………….RAMIT/1594/10
SECTION “B”
Submission Date: 16/03/2021 submitted to Birhanu
 QUESTIONS
1.Discuss on the roles and responsibilities of software
architect and software designer in software development
industry
2. Briefly explain the quality attribute scalability.
3. Describe and explain the Facade design pattern using a
class diagram.
4. Write down and discuss at least four design principles
useful in object-oriented modelling and programming
5. How software design can appear in different software
development lifecycle such as waterfall, Spiral and Agile
development?
 The role of a software architect

• A software architect needs to interact with clients, product managers, and

developers in order to envision, model and provide initial models and
designs that can be built. This role also may cover the meeting potential or
current customers.
• A software architect has to constantly review the code to ensure the quality
of the design by avoiding complexity, advocating clarity and to do this with
the team. This usually requires hands-on work in terms of developing
prototypes, contributing code or evaluating technologies.
• The role of a software architect includes collaborative working with a
degree of humility and providing mentoring as required. Such collaboration
also allows the architect to become familiar with the skills and interests in
the team and to share their knowledge with the rest of the team. Humility is
required to ensure that all the team is listened to, as they may have more
specific experience or knowledge for the problem at hand.
 Main responsibilities of a software architect

 The most important responsibility is complete technical support of the project from
the moment of inception, through product release, to development of enhancements.
The other responsibilities considered among the main ones are:
● Identifying business requirements and requirements of the stakeholders on the
project
● Designing the entire system based on the received requirements
● Choosing the system architecture and each individual component of this system at a
high level
● Choosing the technologies for the implementation of each component and
connections between the components
● Architectural review
● Code-review
● Writing project documentation and its support
● Creating unified development standards in the company
● Controlling the architecture during the next iteration of the system release
 The role of a software designer
• A software designer is responsible for problem-solving and planning for a software solution.
After the purpose and specifications of software are determined, software developers will
design or employ designers to develop a plan for a solution. It includes low-level
component and algorithm implementation issues as well as the architectural view. A
software designer is responsible for the documentation of the plan which is usually the
product of the design.
• Software design documentation may be reviewed or presented to allow constraints,
specifications and even requirements to be adjusted prior to programming. Redesign may
occur after review of a programmed simulation or prototype. It is possible to design
software in the process of programming, without a plan or requirement analysis, but for
more complex projects this would not be considered a professional approach. A separate
design prior to programming allows for multidisciplinary designers and Subject Matter
Experts to collaborate with highly-skilled programmers for software that is both useful and
technically sound.
• The software designer works closely with the software developer to ensure that the design
meets needs for the solution. It is also important to ensure that the software is able to
interact well with other applications that are currently in use.
 responsibilities of a software designer

• Design, develop and execute unit test plans, test designs, test cases and test
strategies.
• Design, develop and execute subsystem test plans, procedures and processes.
• Document all test plans, test cases and strategies procedures and issues.
• Design and implement test scripts on test tools and scripting languages.
• Coordinate and collaborate with outside test partners.
• Design, develop and implement program and process improvements.
• Design and develop coding, code reviews, unit testing and release management.
• Develop design specifications in accordance with business requirements and
issues.
• Recommend strategic improvements to optimize performances.
• Perform analyses and interpretations of strategies and software applications.
 Quality attribute scalability
• Scalability is the ability of the system to handle load increases without decreasing
performance, or the possibility to rapidly increase the load.
• There are two ways to improve scalability:
• Vertical: To increase, we add more resources, such as memory, disks, or processors
into one system.
• Horizontal: We increase the number of computing units and divide the load.
• The key indicators for measuring this attribute are:
• If the system allows for horizontal scaling.
• The time needed to increase scaling, in seconds.
• Scaling limitations: the number of servers or the network capacity.
• Possibility to scale: the increase in the number of transactions or the amount of
content.
• And this is only a small part of the indicators which you need to follow when
designing. Scalability is one of the most essential attributes, no matter what is the
project’s stage.
 Façade design pattern
• The facade pattern (also spelled façade) is a software-design pattern commonly used in 
object-oriented programming. Analogous to a facade in architecture, a facade is an object
 that serves as a front-facing interface masking more complex underlying or structural
code. A facade can:
• improve the readability and usability of a software library by masking interaction with
more complex components behind a single (and often simplified) API
• provide a context-specific interface to more generic functionality (complete with context-
specific input validation)
• serve as a launching point for a broader refactor of monolithic or tightly-coupled systems
in favor of more loosely-coupled code
• Developers often use the facade design pattern when a system is very complex or difficult
to understand because the system has many interdependent classes or because its source
code is unavailable. This pattern hides the complexities of the larger system and provides
a simpler interface to the client. It typically involves a single wrapper class that contains a
set of members required by the client. These members access the system on behalf of the
facade client and hide the implementation details.
Class diagram for façade pattern
 design principles useful in object-oriented
modelling and programming
Single Responsibility Principle (SRP)
• The SRP requires that a class should have only a single responsibility.Example: If a class SalesOrder keeps information
about a sales order, and in addition has a method saveOrder() that saves the SaleOrder in a database and a
method exportXML() that exports the SalesOrder in XML format, this design will violate the SRP because there will be
different types of users of this class and different reasons for making changes to this class. A change made for one type of
user, say change the type of database, may require the re-test, recompilation, and re-linking of the class for the other
type of users.

• A better design will be to have the SalesOrder class only keeps the information about a sales order, and have different
classes to save order and to export order, respectively. Such a design will confirm to SRP.

Open-Closed Principle (OCP)

• The OCP requires that each software entity should be open for extension, but closed for modification.
• Example: Suppose an OrderValidation class has a method validate(Order order) that is programmed to validate an order
based on a set of hard-coded rules. This design violates the OCP because if the rules change,  the OrderValidation class
has to be modified, tested, and compiled.

• A better design will be to let the OrderValidation class  contain a collection of ValidationRule objects each of which has
a validate(Order order) method (perhaps defined in a Validation interface) to validate an Order using a specific rule, and
the validate(Order order) method of OrderValidation class  can simply iterate through those ValidationRule objects to
validate the order. The new design will satisfy the OCP, because if the rules change,  we can just create a
new ValidationRule object and add it to an OrderValidation instance at run time (rather than to the class definition itself).
• This is can also be achieved by using  subclasses of a base class AbstractValidationRule that has an override-able
function validate(Order order). Subclasses can implement the method differently without changing the base class
functionality.
 continued
 Liskov Substitution Principle (LSP)
• The LSP requires that objects in a program should be replaceable with instances of their
subclasses without altering the correctness of that program.
• The users must be able to use objects of subclasses via references to base classes without
noticing any difference. When using an object through its base class interface, the object of a
subclass must not expect the user to obey preconditions that are stronger than those required
by the base class.
• Example: Suppose a Rectangle class has two instance variables height and width, and a
method setSize(int a, int b), which set height to a and width to b. Suppose Square is a subclass
of Rectangle and it overrides the inherited method by setting both height and width to a. This
design will violate LSP. To see this, consider a client uses a reference variable of
type Rectangle to call the setSize() method to assign different values of a and b, and then
immediately verify if the sizes were set correctly or the area is correctly computed. The results
will be different if the variable references to a Rectangle object than to a Square object.  

• It turns out that in OO programming, a Square is not a Rectangle at all because it behaves
differently from a Rectangle.
 continued
 Dependency Inversion Principle (DIP)
• The DIP requires that high level modules should not depend on low level
modules, both should depend on abstraction. Also, abstraction should not
depend on details, details should depend on abstractions.
• Example: Making a class Button associate to another class Lamp (because
a Lamp has a Button) is a violation of DIP. A better design will be associate an
AbstractButton with an AbstractButtonClient, and define Button as a subclass
of the AbstractButton and a Lamp a subclass of the AbstractButtonClient.
• Example: Making an EBookReader class to use PDFBook class is a violation of
DIP because it requires to change the EBookReader class to read other types of
e-books. A better design is to let EBookReader  use an interface EBook and
let PDFBook and other types of e-book classes implement EBook. Now adding
or changing e-book classes will not require any change to EBookReader class.
 How software design can appear in different
software development lifecycle
• Different software development lifecycles have been introduced including waterfall,
prototyping, iterative and incremental development, spiral development, 
rapid application development, and agile development. The traditional 
waterfall model is a sequential design process in which progress is seen as flowing
steadily downwards (like a waterfall) through the phases of Analysis, Design,
Implementation, Testing, and Maintenance. The waterfall model implies the
transition to a phase only when its preceding phase is reviewed and verified.
Typically, the waterfall model places emphasis on proper documentation of artefacts
in the life cycle activities. Advocates of agile software development paradigm argue
that for any non-trivial project finishing a phase of a software product’s life cycle
perfectly before moving to the next phases is practically impossible. A related
argument is that clients may not know exactly what requirements they need and as
such requirements need to be changed constantly.
• It is generally acknowledged that a well-defined mature process will support the
development of quality products with a substantially reduced number of defects.
 continued
 in the design phase, it might be necessary to rework some requirements. In the implementation phase, it may be
necessary to rework part of the design. This is one way of making the life cycle iterative, where a phase may be
executed several times. Feedback can also occur across the entire software development life cycle. There are two
lifecycle models which are considered iterative in nature. The first of these is the incremental model, Ketrell
characterizes this model as having overall requirements phase and initial design phase. Followed by multiple
cycles through the remainder of a lifecycle In this figure each of the three iterations begins with the detailed
design phase. Although development proceeds in increments, there is a single requirements phase for the entire
project. The advantage of this process is that there is some semblance for a product early on, which has a positive
effect on team motivation. The fact that each phase has gone through multiple times in the course of product
development means there's an opportunity for learning. The second and third times through the design
implementation phases, allow developers and managers to understand better the implications of the decisions
made early on. This feedback tends to make downstream phases more efficient. Unfortunately, the single
occurrence of the requirements phase and the lack of feed back arrows to the requirements phase mean that the
requirements must be right the first time. Fixing an incorrect or incomplete requirement constitutes a disruption
to the process. A final variation on the life cycle is the spiral model. The model is similar to the incremental model,
with the exception that there is a delivery to the customer following each verification phase. The disadvantage
Here is that the customer and the users can see early on what form the software is taking. Subsequent
requirements phases leverage customer feedback and this tends to yield a product more adapted to the users
needs. Additionally it allows the customers and users more time to understand the impact of the software on
their business processes. In this manner, the customers and the users don't have to try to imagine all of the
requirements at once.