Eng. Mohammed Timraz Electronics & Communication Engineer

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

2. Introduction • Software Engineer • Software Design • Software Design Activities

3. 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.

4. Hacking vs. Software Engineering 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.

5. 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

6. 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.

7. 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

8. Problem

9. Component 4 • Classes • Objects • Attributes Component 1 • Classes • Objects • Attributes Data Base Component 3 • Classes • Objects • Attributes Component 2 • Classes • Objects • Attributes Component 5 • Classes • Objects • Attributes

10. Software Design

11. 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.

12. 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.

13. Design as an “Activity” (verb) • 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

14. 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” • Customer (user) identification of problem (requirements) sometimes borders on solution --- but is really a constraint. Thus we should thoroughly “understand” problems. • For each problem there may be several solutions or designs that apply. 3. Use some “time-honored” problem solving techniques • Modifyingthe 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).

15. 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: • Associating:parts of the model to the parts of the real entity • Associating: the relationships among parts of the model to the relationships among parts of the entity of interest.

16. 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.

17. Modeling • Modeling is based on problem/solution “simplification” part ofAbstraction. • 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 matchthat in the original entity Note: If everything matched, then the model would just be a “copy,” not an abstraction of the original entity.

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

19. Another Definition of Design (from K. Lano) • Designis the activity of (i) “Constructing” components. (ii) “Organizing” their interactions in order to achieve the system that will satisfy the requirements. • Components: • Identifying the components. • Specifying their functionalities. • 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.)

20. 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).