session i: motivation and general design concepts · pdf fileü motivation for software...

Software Engineering Design: Theory and Practice by Carlos E. Otero

Slides copyright © 2012 by Carlos E. Otero For non-profit educational use only May be reproduced only for student use when used in conjunction with Software Engineering Design: Theory and Practice. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information must appear if these slides are posted on a website for student use.

CHAPTER 1: INTRODUCTION TO SOFTWARE ARCHITECTURE & DESIGN

SESSION I: MOTIVATION AND GENERAL DESIGN CONCEPTS

8/24/2012 1 Software Engineering Design: Theory and Practice

SESSION’S AGENDA

Ø  What’s it all about? ü  Motivation for software engineering design

Ø  Engineering Design ü  Let’s revisit the software engineering life-cycle ü  Context of software design

Ø  Problem-solving ü  Problem-solving process ü  Types of problems ü  Types of thinking ü  Types of solution approaches

8/24/2012 Software Engineering Design: Theory and Practice 2

MOTIVATION FOR SOFTWARE ENGINEERING DESIGN

Ø  Let’s go straight to the point, what is software engineering? ü  According to the IEEE [1], Software Engineering is:

§  (1) the application of a systematic, disciplined, and quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

§  (2) The study of approaches as in (1)

Ø  What do we mean by systematic? According to an online dictionary [2]: ü  Presented or formulated as a coherent body of ideas or principles ü  Methodical in procedure or plan

Ø  What do we mean by disciplined? (From the word discipline [2]): ü  A rule or system of rules governing conduct or activity

Ø  What do we mean by quantifiable? (From [2]) ü  To determine, express, or measure the quantity of

Ø  Given clear definition of these important terms, let’s ask ourselves, do we really need a systematic, disciplined, and quantifiable approach to developing software? Let’s look at some examples…



Ø  A software example: The Mighty Calculator ü  (1) Do we need software engineering to develop this product?

§  Do we need a systematic approach? §  Do we need a disciplined approach? §  Do we need a quantifiable approach?

Ø  Stop and think about these questions! You may be wondering, well…, it depends! ü  (2) Is this my own pet project? ü  (3) Is somebody paying me for this product? ü  (4) Will other people use this product? ü  (5) Is there a time-frame for this product’s development? ü  (6) Do I need to quantify the approach used?

Ø  Depending on (2), (3), (4), (5), and (6) the answer to (1) may be: yes, no, or maybe!!

Ø  Let’s look at another example…



Ø  Without software, the Chevy Volt is Stuck in Neutral. According to GM [3], ü  “…the Chevy Volt is as much a software engineering accomplishment as it was a mechanical

engineering challenge…” ü  “…the software coordinates the flow of energy and provides drivers feedback… Drivers can,

for example, view charge status and schedule battery charging from a smartphone…” ü  “Writing code is not really the challenge any more; it’s managing the thousands of moving

pieces in a project and using that material, such as requirements, code, and models, for future projects”

ü  “We’re now at the point where software control strategies and controls are the gating factor of the vehicles we make”

Ø  Do we need software engineering here? ü  Let’s put things into perspective to (hopefully)

understand what it takes to develop this product (see video on next slide…)



Ø  Without software, the Chevy Volt is Stuck in Neutral (cont) [4]…

§  If embedded youtube control fails, use the browser to navigate to: –  http://www.youtube.com/watch?v=CjjASGV36mw

Ø  Let’s look at one final example…



Ø  The X-47B is a smart, autonomous, computer-controlled unmanned aircraft that takes off, flies a software-controlled mission, then returns to base in response to mouse clicks from its mission operator. The mission operator monitors the X47B air vehicle’s operation, but does not actively “fly” it via remote control as is the case for other unmanned systems currently in operation [5].

Ø  Do we need software engineering here? ü  Ok, it’s becoming evident that not all software systems are equal! ü  Some are more complex than others and software failure may result in catastrophic

events, including loss of human life! Ø  From this point forward, our discussion will focus on these types of large-scale software

systems, as opposed to systems similar to the Mighty Calculator…


Ifembeddedyoutubecontrolfails,usethebrowsertonavigateto:h9p://www.youtube.com/v/kBrVRTVNph0

ENGINEERING SOFTWARE

Ø  Hopefully, by now, your are convinced that a systematic, disciplined, and quantifiable approach is needed to build certain types of software systems; that is, software engineering is necessary to build some (if not all) software products. But how do we engineer software?

Ø  Luckily, a formal process for engineering software has been known for quite some time. This process supports a systematic, disciplined, and quantifiable approach to software product development, and includes the following phases:

Ø  Of importance to this course is the design phase, where requirements are used to create a blueprint of the software to be constructed. Before delving deep into software engineering design, let’s look at the general concept of engineering design…


ENGINEERING DESIGN

Ø  Design is not a new concept conceived by software engineers. Design is used in all other engineering disciplines, e.g., electrical, mechanical, civil, etc. Dym and Little define engineering design as [6]: ü  A systematic, intelligent process in which designers generate, evaluate and specify

designs for devices, systems or processes whose form(s) and function(s) achieve clients’ objectives and users’ needs while satisfying a specified set of constraints.

Ø  Design is a lengthy and complex process which requires significant investment in time and effort. So, why conduct design in engineering disciplines? ü  Using commonsense, complex products (e.g., bridges, airplanes, watercrafts,

medical devices, safety-critical software systems, etc.) are hard to create, costly to change, and when built carelessly, can harm human life.

ü  Design allows teams to organize in disciplined manner and provides a systematic approach to carefully ensure that products are built to meet their specification.

§  Remember the definition of software engineering??


Disciplined,systemaEc…theselookfamiliar,right??

ENGINEERING PROBLEM SOLVING

Ø  In the previous slide, engineering design was defined as an intelligent process… what do we mean by intelligent process? ü  We refer to it as intelligent process because a great deal of problem-solving

occurs during design. ü  During the design process, engineers are constantly engaging in problem-

solving activities. §  Their work requires them to identify, evaluate, and proposed solutions to complex

problems. §  Some problems encountered by engineers have never been solved before!

Ø  Because of the large number of problem-solving activities present during design, a formal discussion on problem-solving is required. ü  To become a good designer, engineers must be good problem solvers. ü  To become a good problem solver… well, that requires lots of time and effort,

but we can at least set up a framework for solving problems throughout the design phase. Let’s examine the fundamentals of problem solving…


ENGINEERING PROBLEM SOLVING

Ø  In a general sense, problem-solving during design occurs in three different states: ü  Initial State ü  Operational State ü  Goal State

Ø  Initial State ü  Problems are formulated and interpreted ü  In some cases, understanding the problem is a problem

itself.

Ø  Operational State ü  Once problem is understood, operational state begins ü  Thinking about the problem and viable solutions come to light

Ø  Goal State ü  Once an appropriate solution is identified, evaluated, and validated, goal state is

reached ü  Final solution found, marking the end of the problem-solving process


OperaEonalSate

IniEalSate

GoalSate

ProblemInterpretedandFormulated

SoluEonIdenEfied,evaluated,andvalidated

ENGINEERING PROBLEM SOLVING – INITIAL STATE

Ø  Moving from state-to-state (i.e., initialàoperationalàgoal) is not as simple as it sounds. During the Initial State of problem solving, it becomes evident that not all problems are the same; they vary in size, complexity, and the amount of time required to reach the goal state. Problems can be classified as: ü  Well-defined ü  Ill-defined ü  Wicked Problem

Ø  Well-defined problems have clear defined goals and their constraints are well understood. ü  This makes scoping the problem, proposing a solution, and arriving at a the solution

easier than with other types of problems.

Ø  Ill-defined problems are ambiguous with undefined goals. ü  They require more time and effort to clarify and interpret the problem ü  Sometimes, these problems can be transformed into well-defined problems. ü  Once formulated, we can move on to propose and arrive at a solution.



Ø  Wicked-problems are problems where no single formulation exists. ü  Many acceptable formulations can take place with no definite solution ü  Solutions are not deemed correct or incorrect, but good or bad ü  They require more time and effort to propose and arrive at “some” solution ü  The problem is formulated after it has been solved!

Ø  Example of wicked problems include: ü  Healthcare ü  Global climate change ü  Border security ü  Design, more to the point, software design

§  Design a secure system §  Design a usable system §  Design a maintainable system

Ø  Design is a wicked problem, and during the design process, many well-defined, ill-defined, and wicked sub-problems are encountered!


Well-defined

Well-defined

Well-defined

Well-defined

Well-definedWell-

defined

Ill-definedWicked

Wicked

WickedWicked

Ill-defined

Ill-defined

Ill-defined

Well-defined

Design “WickedProblem”


Ø  Let’s use a bird’s eye view and tackle Design as a problem. During the Initial State, we classify it as a Wicked Problem. Why does this make sense? ü  Consider the following task: Develop a secure software system.

§  What is the goal? –  That’s easy, to design and develop a secure system!

§  What is the problem? More specifically, can we formulate this problem in a way that can be solved?

–  Stop and think about this! ü  Consider the following task: Develop a usable system.

§  What is the goal? –  Easy again, to design and develop an “easy to use” system.

§  Can we formulate this problem in a way that can be solved? –  We can certainly try, but you will find that most of the time, the problem can only be formulated after

many iterations between customer and designer and only after an acceptable solution has been found!

Ø  Designers spend a great deal of time formulating acceptable versions of these wicked problems! That is, acceptable to stakeholders, including customers, managers, etc. ü  For example, an attempt to problem formulation for developing a secure software system may

include creating an authentication (e.g., username and password) mechanism. Although this may be an acceptable problem formulation for the project’s stakeholders, it clearly does not solve the security problem!


ENGINEERING PROBLEM SOLVING – OPERATIONAL STATE

Ø  During the Operational State of problem solving, it becomes evident that not all problems can be tackled the same way. Different techniques for problem-solving can be employed, including: ü  Divide and conquer ü  Reusing solutions, e.g., patterns.

Ø  Many times, problem-solving requires a “think outside the box” mentality. What exactly does this mean? ü  In a nutshell, it means that we need to think in ways that deviate from conventional

wisdom.

Ø  For example, try solving the popular nine-dot puzzle problem using the figure to the right and the following requirements: ü  Draw four straight lines to connect all dots. ü  The pencil cannot be lifted from the paper once the

line-drawing process begins. ü  No lines can be retraced. ü  A line must pass through every dot.



Ø  During the Operational State of problem solving, it is natural to perceive and approach problems in certain ways, based on our current knowledge. ü  For example, the nine-dot problem resembles a square, therefore it is hard for

some people to operate outside of the assumption that lines should begin and end on a dot.

ü  This functional fixedness limits the ability to find solutions based on objects having a different function from their usual ones.

Ø  To increase the chance of overcoming functional fixedness, problems need to be attempted several times and considered from many different viewpoints and unusual angles. ü  Don’t forget about this… this advice will come in handy during the software

architecture activity!



Ø  During the Operational State of problem solving, different types of thinking takes place. ü  Convergent thinking ü  Divergent thinking

Ø  Convergent thinking ü  Type of thinking that seeks to find one single solution to a problem, e.g., a math

problem.

Ø  Divergent thinking ü  Type of thinking that seeks to find multiple solutions to a problem. ü  This type of thinking is associated with originality, inventiveness, and

flexibility.



Ø  During the Operational State of problem solving, different problem-solving methods take place. ü  Algorithms ü  Heuristics

Ø  Algorithm ü  Step-by-step procedure for finding the correct solution to a given problem. ü  Do not normally involve subjective decisions or rely on intuition or creativity to

find solutions. ü  Examples:

§  Bubble sort, Merge sort, etc.

Ø  Heuristic ü  Rules of thumb (or procedure) that may or may not lead to the solution of a

problem. ü  In some cases, they can lead to optimal solutions, in others, they can lead to

solutions that are far from optimal, or no solution at all! ü  Heuristics are advantageous when tackling tough problems where an efficient

algorithm may not exist.


ENGINEERING PROBLEM SOLVING – HOLISTIC APPROACH

Ø  We can use everything discussed so far to come up with a holistic problem-solving framework that can help us tackle problems of any size during the design process. The framework consists of the following tasks: ü  Interpreting the problem ü  Evaluating the constraints ü  Collaborative brainstorming ü  Synthesizing the possibilities ü  Evaluating the solution ü  Implementing the solution

Ø  In addition, we must consider: ü  Resources

§  Means by which activities are performed, e.g., people, software, hardware. ü  Activities

§  Internal tasks determined by the development organization that must be followed when solving problems, e.g., architecture, detailed design, status reports, etc..

ü  Controls §  Internal constraints set by the development organization so that problem solutions aligns

well with organizational goals and processes, e.g., processes, permitted tools, etc. 8/24/2012 Software Engineering Design: Theory and Practice 19

ENGINEERING PROBLEM SOLVING – HOLISTIC APPROACH

Ø  Interpreting the problem ü  Performed during the Initial State of problem-solving ü  Problem classification, e.g., well-defined, ill-defined, wicked.

Ø  Evaluate constraints ü  Identify external constraints to set bounds on the solution landscape.

Ø  Collaborative brainstorming ü  Performed during the Operational State of problem-solving. ü  Think about different solutions to the problem, i.e., divergent thinking.

Ø  Synthesize the possibilities ü  Performed during the Operational State of problem-solving. ü  Switch to convergent thinking to seek one acceptable solution.

Ø  Evaluate solution ü  Performed during the Operational State of problem-solving. ü  Flaws in the solution may trigger a transition back to the collaborative

brainstorming activity.


SUMMARY OF ENGINEERING DESIGN AND PROBLEM-SOLVING

Ø  We’ve provided general information about engineering design. ü  Motivation for software engineering design ü  General engineering concepts ü  General problem-solving concepts

Ø  In the next session, we will focus our efforts to explain engineering design in the software domain, i.e., software engineering design. Specifically, we will cover: ü  A focused discussion on software engineering design ü  Software design challenges ü  Software design process

§  Software architecture §  Detailed design §  Construction design §  HCI design


REFERENCES

[1] IEEE. “IEEE Standard Glossary of Software Engineering Terminology.” IEEE, 1990. http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=2238, Retrieved on August 23, 2012.

[2] http://www.merriam-webster.com/dictionary/systematic [3] http://news.cnet.com/8301-11128_3-20021346-54.html, Retrieved on August 23, 2012. [4] http://www.youtube.com/watch?v=CjjASGV36mw&feature=player_embedded,

Retrieved on August 23, 2012. [5] http://www.as.northropgrumman.com/products/nucasx47b/assets/

X-47B_Navy_UCAS_FactSheet.pdf, Retrieved on August 23, 2012. [6] Dym, Clive L., AND Patrick Little. Engineering Design: A Project-Based Introduction.

Hoboken, NJ: Wiley, 2008.





SESSION II: OVERVIEW OF SOFTWARE ENGINEERING DESIGN


SESSION’S AGENDA

Ø  Software Engineering Design ü  Why study software engineering design?

Ø  Software design challenges ü  Requirements volatility ü  Processes ü  Technology ü  Ethical and Professional issues ü  Managing design influences

Ø  Software design process ü  Software architecture ü  Detailed design ü  Construction design ü  HCI design


SOFTWARE ENGINEERING DESIGN

Ø  In the previous session, we presented a general motivation for software engineering design and important concepts for designers. These included: ü  Design for large-scale, complex, systems ü  The software engineering life-cycle ü  A micro-process for problem solving, and ü  A holistic (macro) process for problem solving

Ø  In the previous session, design was introduced as a systematic and intelligent process for generating, evaluating, and specifying designs for devices, systems, or processes.

Ø  In software engineering, design provides blueprints that capture how software systems will meet their required functions and how they will be shaped to meet their intended quality.


SOFTWARE ENGINEERING DESIGN

Ø  Formally, software engineering design is defined as: ü  (1) The process of identifying, evaluating, validating, and specifying the

architectural, detailed, and construction models required to build software that meets its intended functional and non-functional requirements; and,

ü  (2) the result of such process.

Ø  In the software industry, the term design is used interchangeably to describe both the process and product resulting from such process. ü  From the process perspective, it describes the phase, activities, tasks, and

interrelationship between them required to model software’s structure and behavior before construction. §  This is concerned mostly with the project management’s aspect of development.

ü  From the product perspective, it describes artifacts resulting from design activities, e.g., class diagram. §  This is concerned mostly with the technical aspects of development.


SOFTWARE ENGINEERING DESIGN – PRODUCT DEVELOPMENT

Ø  From the product development’s perspective, studying software design is important, mainly, because: ü  Requirements are mapped to conceptual models of software ü  Provide models that represent structure and behavior ü  Main components and interfaces are identified ü  Quality of future system is born

§  Modularization, cohesiveness, coupling, etc. §  Provide means to evaluate quality attributes, e.g., usability.

ü  Solutions can be reused in other projects

Ø  Design forms the foundation for all other development activities Ø  Construction Ø  Testing Ø  Maintenance


SOFTWARE ENGINEERING DESIGN –PROJECT MANAGEMENT

Ø  From the project management’s perspective, studying software design is important, mainly, because: ü  Good software design help minimize effects of requirements’ volatility

§  This can minimize impact on schedule and cost. ü  Increases efficiency in human resource allocation.

§  Designs decompose systems so that teams can work on different parts of the problem in parallel.

§  By decomposing system, teams can work in distributed fashion. §  These can have positive effects in schedule and cost.

ü  Shields the project from having “one guy” owning the whole system. §  Multiple personnel owns multiple components.

–  If one leaves the company, it is easier to replace… §  Documented designs can be used by new personnel to minimize

the learning curve.

Ø  Overall, design helps improve project management. ü  Planning, organization, staffing, and tracking


SOFTWARE DESIGN CHALLENGES

Ø  Today, the software design phase has evolved from an ad-hoc and sometimes overlooked phase to an essential phase of the development life-cycle.

Ø  The increasing complexity of today’s software systems has created a set of particular challenges that makes it hard for software engineers to meet the continuous customer demand for higher software quality.

Ø  These challenges have prompted software engineers to pay closer attention to the design process: ü  To better understand, apply, and promulgate well-known design principles, processes, and

professional practices.

Ø  The major design challenges include: ü  Requirements volatility ü  Inconsistent development processes ü  Fast, and ever-changing technology ü  Ethical and professional practices ü  Managing design influences

Ø  To understand these better, we need to explore them in more depth…


SOFTWARE DESIGN CHALLENGE #1 – REQUIREMENTS VOLATILITY

Ø  Requirements’ volatility is a major reason for the complexity of software projects. ü  The common view is that software can be modified “easily”

§  Requirements are not fully specified before design and construction §  Requirements are changed after design and construction

ü  Consider if we take this approach for the development of a house!


Oops…Idon’trememberseeingarequirementforthis…

ProductDevelopedDesiredProduct

ProductDevelopedCustomersnowwantabiggerhouseandmorewindowsbynextweek!

Theregoesmyjobagain!!

SOFTWARE DESIGN CHALLENGE #1 – REQUIREMENTS VOLATILITY

Ø  In software projects, although much effort is put into the requirements phase to ensure that requirements are complete and consistent, that is rarely the case. ü  This makes the software design phase the most influential one when it comes to

minimizing the effects of new or changing requirements. ü  This forces designers to create designs that provide solutions to problems at a

given state while also anticipating changes and accommodating them with minimal effort.

Ø  Because of requirements’ volatility, software engineers must have a strong understanding of the principles of software design and develop skills to manage complexity and change in software projects.


SOFTWARE DESIGN CHALLENGE #2 – THE PROCESS

Ø  Software engineering is a process-oriented field. In the design phase, processes involve a set of activities and tasks required to bridge the gap between requirements and construction. For example: ü  Architectural and detailed designs ü  Design reviews ü  Establishing quality evaluation criteria ü  Establishing design change management and version control ü  Adopting design tools ü  …

Ø  The problem is that in many cases, a company’s design process ü  is not well established, ü  is poorly understood, ü  is approached with minimalistic expectations, ü  is focused on one form of design, e.g., user interface, while ignoring others, or, ü  is simply, not done at all!


SOFTWARE DESIGN CHALLENGE #3 – THE TECHNOLOGY

Ø  The technology for designing and implementing today’ software systems continues to evolve to provide improved capabilities. For example, ü  Modeling languages and tools ü  Programming languages ü  Integrated development environments ü  Design strategies, patterns, etc. ü  …

Ø  As new technologies emerge, software designers are required to assimilate and employ them all at the same time. ü  In some cases, old and new technology needs to coexist in the same project!

Ø  This creates a demand for capable designers that can assimilate new concepts and technology quickly and effectively. ü  This is challenging because of the time required for both learning new

technology and completing a project on-time, while making sure that the new technology interoperates well with old legacy systems.


SOFTWARE DESIGN CHALLENGE #4 – ETHICAL AND PROFESSIONAL PRACTICES

Ø  Designers create blueprints that drive the construction of software. ü  Tight schedules can create external pressures to deviate from the formal design

process to get the product out the door. ü  In some cases, this can have catastrophic consequences

Ø  To correctly and responsibly execute the design phase, designers are required to exert strong leadership skills to: ü  Influence and negotiate with stakeholders ü  Motivate the development team ü  Enforcing ethical guidelines ü  Evaluate the social impacts of their designs in the public domain or in safety-

critical systems ü  Follow and enforce the ethical and professional practices

Ø  This is a challenge when attempting under numerous pressures from different stakeholders, e.g., management, customer, peers, etc.


SOFTWARE DESIGN CHALLENGE #5 – MANAGING DESIGN INFLUENCES

Ø  Besides negative pressures, designs are shaped by other influences from stakeholders, the development organization, and other factors (e.g., the designers’ own experiences).

Ø  These influences can have cyclical effects between the system and its external influences, such that external factors affect the development of the system and the system affects its external factors [1].

Ø  Managing these influences is essential for maximizing the quality of systems and their related influence on future business opportunities.

Ø  Of specific importance are design influences that come from ü  the system’s stakeholders and, ü  its developing organization


Yikes!

Iwantperformance!

IwantSecurity!

IwantUsability!



Ø  Software projects can have a multitude of stakeholders, each with specific wants and needs that influence the software design. ü  Some conflicting with each other! ü  Each stakeholder believes he/she is correct.

Ø  This requires some design trade-offs to satisfy each customer. ü  Difficult to do in large-scale systems!

Ø  This is difficult to do since design decisions need to accommodate all concerns without negatively affecting the project.


Ø  The developing organization also influences designs significantly. ü  Consider software development across site boundaries!

§  Consider coordinating design efforts §  Consider conducting peer reviews §  Consider developing code from design §  Consider managing version control

ü  In this case, design must support such development!

Ø  At the same time, designs can influence the developing organization to enter new areas of business. ü  Consider a design that supports plug-ins to enhance capabilities of the software.

Someone may realize that existing functionality can be enhanced via plug-in to solve a problem in a different domain, giving the developing organization a competitive advantage!

Ø  Managing these influences is challenging because it requires designers to span out of the technical domain to have keen interest in the organization as a whole.


SOFTWARE DESIGN PROCESS

Ø  Up until now, we have spent quite a bit of time discussing properties of software design. We have also defined software design from the process perspective, which referred to the phase, activities, tasks, and interrelationship between them required to model software’s structure and behavior before construction. ü  However, we have not formally described what goes on within the design

phase. ü  Let‘s examine in depth the software design process…

Ø  A software design process is a set of activities and controls that specify how resources work together for the production of software design artifacts. ü  Two major activities of the software design process include:

§  Software Architecture §  Detailed Design



Ø  Software Architecture ü  Corresponds to a macro design approach for creating models that depict the

quality and function of the software system. ü  Provides black-box models used to evaluate the system’s projected capabilities

as well as its expected quality. ü  Designed using multiple perspectives, therefore, allows different stakeholders

with different backgrounds to evaluate the design to ensure that it addresses their concerns.

ü  It provides the major structural components and interfaces of the system. ü  It focuses on the quality aspects of the system before detailed design or

construction can begin. ü  They serve as important communication, reasoning, and analysis tool that

supports the development and growth of the system [1] ü  Lays the foundation for all subsequent work in the software engineering life-

cycle.



Ø  Detailed Design ü  Whereas software architecture deals with the major structural components and

interfaces of the system, detailed design focuses mostly on the internals of those components and interfaces.

ü  Begins after the software architecture activity is specified, reviewed, and deemed sufficiently complete.

ü  Builds on the software architecture to provide a white-box approach to design the structure and behavior of the system.

ü  Refines the architecture to reach a point where the software design, including architecture and detailed design, is deemed sufficiently complete for the construction phase to begin.

ü  Focuses on functional requirements, whereas the architecture focuses mostly on non-functional, or quality, requirements.

ü  Two important tasks of the detailed design activity include: §  Interface Design §  Component Design



Ø  Interface design ü  Refers to the design activity that deals with specification of interfaces between

components in the design. ü  Provide a standardized way for accessing services provided by software

components. ü  Allow for multiple efforts to occur in parallel, as long as interfaces are obeyed,

therefore, it is one of the first tasks during detailed design. ü  Can be performed for both internal interfaces and external interfaces, e.g.,

XML messaging specification for communication across the network. Ø  Component design

ü  During architecture, major components are identified. During component design, the internal design of (the structure and behavior of) these components is created.

ü  In object-oriented systems, using UML, component designs are typically in the form of class diagrams, sequence diagrams, etc.

ü  When creating these designs, several design principles, heuristics, and patterns are often used in professional practice.

ü  Sometimes referred to as component-level design.



Ø  Software architecture and detailed design are well-known activities of the software design phase, however, other important activities are required for supporting the creation of architectural and detailed designs. ü  Therefore, when scoping the software design process, the effort required for these other

activities must be considered!

Ø  Other important activities that require time and effort include: ü  Design documentation ü  Management activities

Ø  An often neglected activity when scoping design efforts is the design that occurs during construction. This form of design is important to model complex functions or routines identified during detailed design. ü  Construction design is a form of detailed design that occurs mostly during the construction

phase. ü  Construction design is important to reason, communicate, and document the solution to

complex programming problems.

Ø  Another important design activity is the Human-computer interface design. ü  Design activity where general principles are applied to optimize the interface between humans

and computers.



Ø  The software design phase has several activities, each having one or more tasks. ü  Architecture

§  Identifying views §  Identifying patterns §  …

ü  Detailed Design §  Interface design §  Component design §  …

ü  Construction Design §  Flow-based design §  Table-based design §  …

ü  Human-computer Interface Design §  …

Ø  Each design activity needs to be ü  Documented, and ü  All processes need to be managed!

Ø  We will spend the rest of the semester learning how to carry out these activities (including tasks), how to document these efforts, and how to manage them!



Ø  In the previous slide, it is seen that architectural designs are elaborated through detailed design, which are further elaborated through construction design. In practice, design activities are not carried out in such orderly and controlled fashion. ü  Quite a bit of iteration occurs between these activities.

Ø  In a perfect world, all design work would take place during the design phase. In practice, the distribution of design activities varies throughout the software development life-cycle. ü  In most projects, most of the design efforts occur during the design phase, but some design

inevitably occurs in other life-cycle phases, e.g., §  Requirements §  Construction

ü  In some cases, architectural design efforts occur during the requirement’s phase. ü  In some cases, detailed design occurs during the construction phase. ü  These cases will become evident as we cover these activities during the course.


WHAT’S NEXT…

Ø  In the next session, we will continue the focused discussions on software engineering design. Specifically, ü  Roles of software designers

§  Systems Engineer §  Software architect §  Component designer §  User interface designer

ü  Design principles §  Modularization §  Abstraction §  Encapsulation §  Cohesion and coupling §  Separation of interface and implementation §  Sufficiency and completeness

ü  Design strategies §  Object-oriented vs. structured design

ü  Practical design considerations


REFERENCES

Ø  [1] Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practice, 2d ed. Boston: Addison-Wesley, 2003.





SESSION III: SOFTWARE DESIGN FUNDAMENTALS


SESSION’S AGENDA

Ø  Roles of software designers ü  Systems Engineer ü  Software architect ü  Component designer ü  User interface designer

Ø  Software design fundamentals ü  Design principles

§  Modularization §  Abstraction §  Encapsulation §  Cohesion and coupling §  Separation of interface and implementation §  Sufficiency and completeness

ü  Design strategies §  Object-oriented vs. structured design

ü  Practical design considerations


ROLES OF SOFTWARE DESIGNERS

Ø  Systems Engineer ü  Designs systems using a holistic approach, which includes designing how software,

hardware, people, etc. collaborate to achieve the system’s goal.

Ø  Software Architect ü  Design software systems using (for the most part) a black-box modeling approach;

concern is placed on the external properties of software components that determine the system’s quality and support the further design of functional requirements.

Ø  Component Designer ü  Focuses on designing the internal structure and behavior of software components

identified during the architecture phase; typically, these designers have strong programming skills, since they implement their designs in code.

Ø  User Interface Designer ü  Design the software’s user interface; skilled in determining ways that increase the

usability of the system


SOFTWARE DESIGN FUNDAMENTALS

Ø  Within the design process, many principles, strategies, and practical considerations exist to help designers execute the design process in effective and consistent manner.

Ø  General design principles ü  Refer to knowledge matter that has been found effective throughout the years in

multiple projects on different domains. ü  Serve as fundamental drivers for decision-making during the software design

process. §  They are used as basis for reasoning and serve as justification for design decisions.

ü  Provide designers a foundation from which other design methods can be applied.

ü  Are not specific to particular design strategies (e.g., object-oriented) or process. §  The are fundamental to every design effort. §  Can be employed during architecture, detailed design, construction design, etc.



Ø  Design Principle #1: Modularization ü  It is the principle that drives the continues decomposition of the software

system until fine-grained components are created. ü  One of the most important design principle, since it allows software systems to

be manageable at all phased of the development life-cycle. ü  When you modularize a design, you are also modularizing requirements,

programming, test cases, etc. ü  Plays a key role during all design activities; when applied effectively, it

provides a roadmap for software development starting from coarse-grained components that are further modularized into fine-grained components directly related to code.

ü  Leads to designs that are easy to understand, resulting in systems that are easier to develop and maintain.


SOFTWARE DESIGN FUNDAMENTALS - MODULARIZATION

Ø  Conceptual view of modularization:

Ø  Modularization is the process of continuous decomposition of the software system until fine-grained components are created. But how do we justify the “modularization engine”? ü  It turns out that two other principles can effectively guide designers during this

process §  Abstraction §  Encapsulation


MonolithicSystem

ModularizedUnits

ModularizaEonEngine


Ø  Design Principle #2: Abstraction ü  Abstraction is the principle that focuses on essential characteristics of entities—in their active

context—while deferring unnecessary details. ü  While the principle of modularization specifies what needs to be done, the principle of

abstraction provides guidance as to how it should be done. Modularizing systems in ad-hoc manner leads to designs that are incoherent, hard to understand, and hard to maintain.

ü  Abstraction can be employed to extract essential characteristics of: §  Data §  Procedures or behavior

Ø  Procedural abstraction ü  Specific type of abstraction that simplifies reasoning about behavioral operations containing a

sequence of steps. ü  We use this all the time, e.g., consider the statement “Computer 1 SENDS a message to server

computer 2” §  Image if we had to say, e.g., “Computer 1 retrieves the server’s information, opens a TCP/IP

connection, sends the message, waits for response, and closes the connection.” Luckily, the procedural abstraction SEND helps simplify the operations so that we can reason about this operations more efficiently.

Ø  Data abstraction ü  Specific type of abstraction that simplifies reasoning about structural composition of data

objects. §  In the previous example, MESSAGE is an example of the data abstraction; the details of a

MESSAGE can be deferred to later stages of the design phase.



Ø  Design Principle #3: Encapsulation ü  Principle that deals with providing access to the services of abstracted entities by exposing

only the information that is essential to carry out such services while hiding details of how the services are carried out.

ü  When applied to data, encapsulation provides access only to the necessary data of abstracted entities, no more, no less.

ü  Encapsulation and abstraction go hand in hand. §  When we do abstraction, we hide details… §  When we do encapsulation, we revise our abstractions to enforce that abstracted entities only

expose essential information, no more, no less. §  Encapsulation forces us to create good abstractions!

Ø  The principles of modularization, abstraction, and encapsulation can be summarized below.


Focusonessen)alcharacteris)csofen))es Enforcethatweonlyexposeessen)alinforma)on


Ø  Design Principle #4: Coupling ü  Refers to the manner and degree of interdependence between software

modules. ü  Measurement of dependency between units. The higher the coupling, the

higher the dependency and vice versa.


M1

Module1(M1)withhighercoupling

M1

Module1(M1)withlowercoupling


Ø  Important types of coupling include: ü  Content coupling

§  The most severe type, since it refers to modules that modify and rely on internal information of other modules.

ü  Common coupling §  Refers to dependencies based on common access areas, e.g., global variables. §  When this occurs, changes to the global area causes changes in all dependent modules. §  Lesser severity than content coupling.

ü  Data coupling §  Dependency through data passed between modules, e.g., through function parameters. §  Does not depend on other modules’ internals or globally accessible data, therefore, design

units are shielded from changes in other places.

Ø  In all cases, a high degree of coupling gives rise to negative side effects. ü  Quality, in terms of reusability and maintainability, decrease. ü  When coupling increase, so does complexity of managing and maintaining design

units.



Ø  Design Principle #5: Cohesion ü  The manner and degree to which the tasks performed by a single software module are

related to one another. ü  Measures how well design units are put together for achieving a particular tasks.

Ø  Cohesion can be classified as: ü  Functional cohesion ü  Procedural (or sequential) cohesion ü  Temporal cohesion ü  Communication cohesion

Ø  High cohesion good, low cohesion bad…



Ø  Design Principle #6: Separation of Interface and Implementation ü  Deals with creating modules in such way that a stable interface is identified and

separated from its implementation. ü  Not the same thing as encapsulation! ü  While encapsulation dictates hiding the details of implementation, this

principle dictates their separation, so that different implementations of the same interface can be swapped to provide modified or new behavior.



Ø  Design Principle #7: Sufficiency ü  Deals with capturing enough characteristics of the abstraction to permit

meaningful interaction ü  Must provide a full set of operations to allow a client proper interaction with

the abstraction. ü  Implies minimal interface

Ø  Design Principle #8: Completeness ü  Deals with interface capturing all the essential characteristics of the abstraction. ü  Implies an interface general enough for any prospective client ü  Completeness is subjective, and carried too far can have unwanted results.


SOFTWARE DESIGN STRATEGIES

Ø  Object-oriented design strategy ü  Design strategy in which a system or component is expressed in terms of

objects and connections between those objects. ü  Focuses on object decomposition.

§  Objects have state §  Objects have well-defined behavior §  Objects have unique identity

ü  Supports inheritance and polymorphism

Ø  Structured (or Functional) design strategy ü  Design strategy in which a system or component is decomposed into single-

purpose, independent modules, using an iterative top-down approach. ü  Focuses on

§  Functions that the system needs to provide, §  the decomposition of these functions, and §  The creation of modules that incorporate these functions.

ü  Largely inappropriate for use with object-oriented programming languages.


PRACTICAL SOFTWARE DESIGN CONSIDERATIONS

Ø  Design for minimizing complexity ü  Design is about minimizing complexity. ü  Every decision that is made during design must take into account reducing

complexity [1]. ü  When faced with competing design option, always choose the one that

minimizes complexity

Ø  Design for change ü  Software will change, design with extension in mind. ü  A variety of techniques can be employed through the design phase to achieve

this.


WHAT’S NEXT…

Ø  On the next session, we will explore a popular design language, the Unified Modeling Language, specifically, ü  What is UML? ü  UML Fundamentals ü  Structural Modeling ü  Behavioral Modeling ü  …

Ø  UML will be heavily used to explain design concepts throughout the course.


REFERENCES

Ø  [1] McConnell, Steve. Code Complete, 2d ed. Redmond, WA: Microsoft Press, 2004.


session i: motivation and general design concepts · pdf fileü motivation for software...

Documents