Eng. Mohammed Timraz Electronics & Communication Engineer University of Palestine Faculty of Engineering and Urban planning Software Engineering Department Software Modeling SWE5441 Lecture 2

Introduction Software Engineer Software Design Software Design Activities

Hacking vs. Software Engineering Hacking  Writing code without thought or plan.  Hacking is often marked by unbridled optimism (without clearly control).  Writing lots of code before testing any of it  Keeping all the details in your head, assuming you’ll remember forever.  Assuming that bugs will be nonexistent, or else easy to find and fix.

Software engineering is not hacking  Think first, then code.  You need tools for thinking, such as models and notations for expressing design problems.  Engineers are pessimists  Write a little bit at a time, testing as you go.  Document the assumptions that the code depends on.  Defend your code against stupidity, especially your own. Hacking vs. Software Engineering

A Larger View of Good Software  Correct Gets the right answers.  Economical Runs fast, uses minimal resources, doesn’t cost much to produce.  Dependable Safe from bug.  Maintainable Easy to understand and ready for change.  Usable Has an effective user interface.  Secure Safe from malicious attacks. Note: all these properties matter in practice sometimes supporting each other, sometimes in conflict

What Makes “Good” Software Easy to understand,  Simple, short methods.  Well chosen, descriptive names.  Clear, accurate documentation.  Indentation. Ready for change,  No redundant: complex code or important design decisions appear in only one place (Use common tools).  “Decoupled”: changeable parts are isolated from each other. (Use separable frameworks). safe from bugs,  Static typing helps find bugs before you run.  Assertions and runtime checking catch bugs quickly at runtime.  Testable in small parts.  No hidden assumptions waiting to trap you or another programmer later.

Software Design Activities  Architectural design Structure system into components Define the interfaces between components  Detailed design of each component Define internal logic Define internal data structures  Data design Define file structures Logical database design

Problem

Component 1 Component 3 Component 4 Component 2 Component 5 Classes Objects Attributes Classes Objects Attributes Classes Objects Attributes Classes Objects Attributes Classes Objects Attributes

Software Design

Important “End-Results” of Design “Well-Designed” software results in solution that is: Easy to learn. Easy to use. Easy to code. Easy to maintain. Affordable (economical). Dependable. Valuable (increase productivity, life saving, etc. – meets customer requirements ) Which ones do the users care? Any other property that you may want to add --- easy to integrate or test.

Design of Software Product Designers are interested not only in the code, but the complete product which includes:  Documentation and User Instructions.  Code (functionality, data, security, reliability, etc.).  Interfaces (including user).  Packaging Scheme.  Installation.  Service (including maintenance). This seems like a lot of topics that software designers must cover !! So, there are specializations within the field of software design.

 Software “Product” Design is the activity of specifying the nature and composition of software products that satisfy the clients’ needs and desires subject to certain set of constraints Design as an “Activity” (verb)

Understanding the Problem Design occurs “after” requirements (which identifies the “problems”) –“after” is fuzzy time boundary – there is no clean boundary. Think of Design as both: a) understanding & b) solving “problems” 1.Customer (user) identification of problem (requirements) sometimes borders on solution --- but is really a constraint. Thus we should thoroughly “understand” problems. 2.For each problem there may be several solutions or designs that apply. 3. Use some “time-honored” problem solving techniques Modifying the problem slightly to a) facilitate easier/cheaper solution. b) Match previously solved problem. Trial and error (e.g. iterative prototyping is the fancy term). Group brainstorming (I do not recommend this for design).

Two Basic Design Techniques  Abstraction Focusing on the “relevant” properties of an entity by suppressing and ignoring some other properties and the details trick is deciding on the “relevant.”  Modeling Constructing a model “entity” to represent the real entity of interest through: o Associating: parts of the model to the parts of the real entity o Associating: the relationships among parts of the model to the relationships among parts of the entity of interest.

2 aspects of Abstraction 1) Problem/Solution “Simplification”: concentrating on only the key property (For example): In drawing a figure, we choose to first focus on shape of the figure (e.g. circle, oval, rectangle, diamond, etc.) before worrying about the color, the line width, solid/dotted line, etc. 2) Problem/Solution “Refinement: simplify first and then enhance the solution with more details  Top-down refinement (Decomposition): partition the problem into several key components first and then solve the details of each component  Bottom-up aggregation : solving pieces of a complex problem and then aggregate the solutions Note: Bottom-up solution usually requires a top-down framework of key components.

Modeling  Modeling is based on problem/solution “simplification” part of Abstraction. –Decide on the key components (abstraction) of the entity of interest. –Decide on the key relationships that exist among the components of the entity of interest. –Construct the components of the model to represent the components of the entity of interest. –Construct the relationships among the components of the model to reflect the relationships among the components of the original entity of interest.  In doing so: –There may be parts in the model that do not match the original entity –There may be relationships in the model that do not match that in the original entity Note: If everything matched, then the model would just be a “copy,” not an abstraction of the original entity.

Modeling: “components” and “relations” “Thing” that Needs modeling Part C Part D Part B Part A Part F modeling

Another Definition of Design (from K. Lano)  Design is the activity of (i) “Constructing” components. (ii) “Organizing” their interactions in order to achieve the system that will satisfy the requirements. Components: o Identifying the components. o Specifying their functionalities. o Specifying any constraints (performance, security, etc.) Interactions: Identify and Specify Component relations (inheritance, aggregation, etc.) Identify and Specify Component dependencies (interfaces, joint responsibilities, sequences of interactions, etc.)

Advantages of modeling  Allows us to understand the problem or requirements better (model of the problem).  Allows us to create an “initial rough design”. “Model” of problem develops into “Model” of solution.  Allows us to investigate and study both the problem and the solution in more detail.  Allows us to have a documentation of the problem/solution descriptions (models).