‫و ازرة التعليم العالي والبحث العلمي‬

‫كلية شط العرب الجامعة االهلية‬

‫قسم علوم الحاسبات‬

‫آليات تصميم البرامجية‪designing‬‬

‫تقرير مقدم الى كلية شط العرب الجامعة االهلية _قسم علوم الحاسبات‬
‫المرحلة(الثالثة)كأحد‬
‫متطلبات االمتحان النهائي لمادة(هندسة البرمجيات)للعام الدراسي‬
‫‪.9191_9102‬‬

‫اعداد الطالب‪:‬‬
‫سيف سعد جابر‬

‫اشــــــــراف‪:‬‬
‫د‪ .‬باسم سهر ياسين‬
 ‫بس ـ ـ ـ ـ ـ ـ ـ ـ ـ ـم هللا الرحمن الرحيم‬

‫عبَا ِد ِه ْال ُعلَمَا ُء إِ َّ‬

‫ن‬ ‫شى َّ َ‬
‫َّللا ِم ْ‬
‫ه ِ‬ ‫♦﴿ إِوَّمَا ي ْ‬
‫َخ َ‬
‫َّ َ‬
‫َّللا َع ِزي ٌز َغ ُفو ٌر ﴾ ]فاطر‪[82 :‬‬

‫| ‪2Page‬‬
 Indexing

Software design …………………………………………………4

Design Concepts…………………………………………………4

Design considerations……………………………………………5

Cohesion…………………………………………………………6

What is the difference between designing and coding?................7

References……………………………………………………….8

3Page |
Software design
is the process by which an agent creates a specification of a software
artifact, intended to accomplish goals, using a set of primitive
components and subject to constraints.[1] Software design may refer to
either "all the activity involved in conceptualizing, framing,
implementing, commissioning, and ultimately modifying complex
systems" or "the activity following requirements specification and
before programming, as ... [in] a stylized software engineering process."[2]

Design Concepts
The design concepts provide the software designer with a foundation
from which more sophisticated methods can be applied. A set of
fundamental design concepts has evolved. They are as follows:

1. Abstraction - Abstraction is the process or result of generalization

by reducing the information content of a concept or an observable
phenomenon, typically in order to retain only information which is
relevant for a particular purpose. It is an act of Representing
essential features without including the background details or
explanations.
2. Refinement - It is the process of elaboration. A hierarchy is
developed by decomposing a macroscopic statement of function in
a step-wise fashion until programming language statements are
reached. In each step, one or several instructions of a given
program are decomposed into more detailed instructions.
Abstraction and Refinement are complementary concepts.
3. Modularity - Software architecture is divided into components
called modules.
4. Software Architecture - It refers to the overall structure of the
software and the ways in which that structure provides conceptual
integrity for a system. Good software architecture will yield a good
return on investment with respect to the desired outcome of the
project, e.g. in terms of performance, quality, schedule and cost.
5. Control Hierarchy - A program structure that represents the
organization of a program component and implies a hierarchy of
control.
6. Structural Partitioning - The program structure can be divided into
both horizontally and vertically. Horizontal partitions define
separate branches of modular hierarchy for each major program

4Page |
 function. Vertical partitioning suggests that control and work
should be distributed top down in the program structure.
7. Data Structure - It is a representation of the logical relationship
among individual elements of data.
8. Software Procedure - It focuses on the processing of each module
individually.
9. Information Hiding - Modules should be specified and designed so
that information contained within a module is inaccessible to other
modules that have no need for such information.
In his object model, Grady Booch mentions Abstraction, Encapsulation,
Modularisation, and Hierarchy as fundamental software design
principles.[4] The acronym PHAME (Principles of Hierarchy, Abstraction,
Modularisation, and Encapsulation) is sometimes used to refer to these
four fundamental principles.[5]

Design considerations
There are many aspects to consider in the design of a piece of software.
The importance of each consideration should reflect the goals and
expectations that the software is being created to meet. Some of these
aspects are:

 Compatibility - The software is able to operate with other products

that are designed for interoperability with another product. For
example, a piece of software may be backward-compatible with an
older version of itself.
 Extensibility - New capabilities can be added to the software without
major changes to the underlying architecture.
 Modularity - the resulting software comprises well defined,
independent components which leads to better maintainability. The
components could be then implemented and tested in isolation before
being integrated to form a desired software system. This allows
division of work in a software development project.
 Fault-tolerance - The software is resistant to and able to recover from
component failure.
 Maintainability - A measure of how easily bug fixes or functional
modifications can be accomplished. High maintainability can be the
product of modularity and extensibility.
 Reliability (Software durability) - The software is able to perform a
required function under stated conditions for a specified period of
time.

5Page |
 Reusability - The ability to use some or all of the aspects of the
preexisting software in other projects with little to no modification.
 Robustness - The software is able to operate under stress or tolerate
unpredictable or invalid input. For example, it can be designed with
resilience to low memory conditions.
 Security - The software is able to withstand and resist hostile acts and
influences.
 Usability - The software user interface must be usable for its target
user/audience. Default values for the parameters must be chosen so
that they are a good choice for the majority of the users. [6]
 Performance - The software performs its tasks within a time-frame
that is acceptable for the user, and does not require too much memory.
 Portability - The software should be usable across a number of
different conditions and environments.
 Scalability - The software adapts well to increasing data or added
features or number of users.

Cohesion
Cohesion is a measure that defines the degree of intra-dependability
within elements of a module. The greater the cohesion, the better is the
program design.
There are seven types of cohesion, namely –

 Co-incidental cohesion - It is unplanned and random cohesion,

which might be the result of breaking the program into smaller
modules for the sake of modularization. Because it is unplanned, it
may serve confusion to the programmers and is generally not-
accepted.
 Logical cohesion - When logically categorized elements are put
together into a module, it is called logical cohesion.
 Temporal Cohesion - When elements of module are organized
such that they are processed at a similar point in time, it is called
temporal cohesion.
 Procedural cohesion - When elements of module are grouped
together, which are executed sequentially in order to perform a
task, it is called procedural cohesion.
 Communicational cohesion - When elements of module are
grouped together, which are executed sequentially and work on
same data (information), it is called communicational cohesion.

6Page |
  Sequential cohesion - When elements of module are grouped
because the output of one element serves as input to another and so
on, it is called sequential cohesion.
 Functional cohesion - It is considered to be the highest degree of
cohesion, and it is highly expected. Elements of module in
functional cohesion are grouped because they all contribute to a
single well-defined function. It can also be reused.

What is the difference between designing and coding?

There is no difference between designing a program on paper

and coding it, but code tends to be harder to understand and
change. So the goal of the paper planning phase is to invent a
pattern that helps you understand the code and isolate it from
changes made in other parts of the program. In fact, most of
your time will be spent creating ways to isolate code from
changes made to other code, and most of this tutorial will be
about how you can do this one thing.

A popular metaphor for design versus coding is the architect

who gives blueprints to the builder, and the builder represents
the programmer. But it's an imperfect metaphor because it
forgets the compiler, which does the same thing as the builder in
the architect metaphor. If we revised the metaphor then the
architect would have to go through three phases to design a
bridge: come up with a way to organize the blueprints, then
come up with a way to prevent changes in the design of the bolts
or girders from forcing a redesign of the entire bridge,
and then design the bridge.
In real life construction projects the builders also co-design the
bridge along with the architect because they discover problems
that the architect missed, even offering solutions for them based
on their expertise as builders. Not just problems with the
measurements and materials either, but problems with the
7Page |
landscape, weather and budget. With programming the compiler
will be a co-designer because it'll also tell you about problems
you missed. Not just problems with the syntax, but problems
with the way you use types. Many modern compilers will go as
far as to suggest ways to fix those problems based on the
expertise of the programmers who made it. This is why the
choice of language has a big impact on how much design work
you'll do on paper before you begin coding. The more type
checking and static analysis the compiler does and the more
expressive the language is then the easier it is to organize and
isolate code. Imagine that languages could be placed on a graph
like the one below. Here we see that assembly languages require
the most planning in advance of coding, but DSLs (Domain
Specific Languages) can be so specialized for their task that you
can jump into coding almost right away

References

1. Ralph, P. and Wand, Y. (2009). A proposal for a formal definition

of the design concept. In Lyytinen, K., Loucopoulos,
P., Mylopoulos, J., and Robinson, W., editors, Design
Requirements Workshop (LNBIP 14), pp. 103–136. Springer-
Verlag, p. 109 doi:10.1007/978-3-540-92966-6_6.
2. ^ Freeman, Peter; David Hart (2004). "A Science of design for
software-intensive systems". Communications of the ACM. 47 (8):
19–21 [20]. doi:10.1145/1012037.1012054. S2CID 14331332.
3. ^ Davis, A:"201 Principles of Software Development", McGraw
Hill, 1995.
4. ^ Booch, Grady; et al. (2004). Object-Oriented Analysis and
Design with Applications (3rd ed.). MA, USA: Addison
Wesley. ISBN 0-201-89551-X. Retrieved 30 January 2015.
5. ^ Suryanarayana, Girish (November 2014). Refactoring for
Software Design Smells. Morgan Kaufmann. p. 258. ISBN 978-
0128013977.
6. http://www.yacoset.com/Home/how-to-design-a-computer-
program

8Page |