Decomposition into Parts. Software Engineering, Lecture 4. Data and Function Cohesion. Allocation of Functions and Data. Component Interfaces

Transcription

1 Software Engineering, Lecture 4 Decomposition into suitable parts Cross cutting concerns Design patterns I will also give an example scenario that you are supposed to analyse and make synthesis from The problem is divided in tasks corresponding to tasks in a design process and you will work concurrently Software Engineering , Tony Larsson, Halmstad University 1 Decomposition into Parts Assuming that we have a picture of the functions and the data to handle and an idea about overall architecture principles: Do a decomposition of the system into parts (subsystems or components) Identify a how these parts should interwork Software Engineering , Tony Larsson, Halmstad University 2 Allocation of Functions and Data Whether a specific function or data should belong to one part or to another is difficult to decide and the decision may change when more information is known You can t design a competitive and needed product without knowledge and there is a lot that you must get knowledge about Data and Function Cohesion By analysis of the relationships between data instances we can often identify clusters of closely related data Functions associated with and applicable to the data clusters can then be identified Software Engineering , Tony Larsson, Halmstad University 3 Software Engineering , Tony Larsson, Halmstad University 4 Data and Function Decoupling Look for boarders where the coupling between the clusters are small A decoupled cluster of related data and functions (use cases) is a good candidate or base for a component Such components with low coupling can be distributed without too negative effects on the communication costs Component Interfaces Having identified potential components we should now think about the interfaces between these The interface should decouple the internals of the component and other components Software Engineering , Tony Larsson, Halmstad University 5 Software Engineering , Tony Larsson, Halmstad University 6 1

2 Interfaces An interface only should give access to the services or functions that the component provide Interfaces should be designed with the future in mind and for backwards compatibility etc. Suitable interfaces is key to long term success A component: 1. Is a part designed to be replaceable and useful in several system contexts 2. Have (or can access) knowledge about other component types and services 3. Lack knowledge about component instances and connections at design time 4. Provides a service interface and uses such interfaces 5. Is adapted to its environment by passing parameters via input ports at compile, linking, load or run time 6. Communicate its data via output ports (or is directed via name servers) to other components input ports Software Engineering , Tony Larsson, Halmstad University 7 Software Engineering , Tony Larsson, Halmstad University 8 HW and SW dependencies Make a careful analysis of the physical world where the system is intended to work Get to know the HW that the system is based on It is also important to identify relationships to the OS and other SW components (to be used) HW and SW dependencies, cont. Some applications work at a high less HW dependent levels Other applications work at lower more HW specific and HW dependent levels HW and SW components can in a sense be regarded as actors related to a specific kind of use cases Software Engineering , Tony Larsson, Halmstad University 9 Software Engineering , Tony Larsson, Halmstad University 10 HW and SW dependencies, cont. Lower level SW deal with issues such as interrupts; memory management and addressing issues; and also cooperate with HW units via drivers and communication buffers In early phases of a development project we should identify the dependencies between SW and HW (but save the solution to later phases) For embedded SW components surrounding HW and SW are the main actors that we can identify and will interact with Development effort estimation Make an early estimate the size of the project required to finish a first version of the product you aim for If we estimate the effort it takes to develop each part it is easier to extrapolate a cost for the whole Partitioning into reasonably sized parts or work packages simplifies this Software Engineering , Tony Larsson, Halmstad University 11 Software Engineering , Tony Larsson, Halmstad University 12 2

3 Development effort estimation For a large system we do the partitioning in several steps This until we understand the complexity of what we do We must also estimate remaining uncertainties and risks Design Patterns Documented problem-solution pairs that can be reused in different contexts where similar (matching) problems exist Patterns are guidelines that simplifies to assign responsibilities to objects Design patterns can use architecture concepts such as separation of concerns using modularization and/or layering Software Engineering , Tony Larsson, Halmstad University 13 Software Engineering , Tony Larsson, Halmstad University 14 Regularity and repetition Design patterns make it easier to see and talk about commonly occurring problems and their solutions By using patterns repeatedly, simple regular structures can be designed Such regular structures are easy to maintain Examples of design patterns Client-Server Presentation - Application Logic Data Store (3-tier, client-server-db) Module (cohesive loosely coupled) Layer (above layer) Command handler Resource handler Software Engineering , Tony Larsson, Halmstad University 15 Software Engineering , Tony Larsson, Halmstad University 16 Examples of design patterns, cont. Information handler Low coupling High cohesion Creators and factories Controllers and coordinators Interface, adapter, facade and proxy Cross cutting concern There are several problems that influence a whole system Such problems are called cross cutting concerns Software Engineering , Tony Larsson, Halmstad University 17 Software Engineering , Tony Larsson, Halmstad University 18 3

4 Cross cutting security concerns Security concerns cut across application module boundaries Security related code must be scattered into other application code Changing the security code becomes hard, because it has to be changed in many places This spreading of the security code also compromise maintainability and reuse Major and Minor Concerns Code for some aspects or concerns has a tendency to be spread across the system over many of its components Security Maintenance Software Engineering , Tony Larsson, Halmstad University 19 Software Engineering , Tony Larsson, Halmstad University 20 Modularized Concerns Ideally we want the concern specific code gather in a module Security Aspect Oriented Programming AOP develops cross cutting concerns, or aspects, as isolated issues AOP combines solutions to these issues with application modules at build or run time using a technique called weaving Maintenance Software Engineering , Tony Larsson, Halmstad University 21 Software Engineering , Tony Larsson, Halmstad University 22 Weaving Traditional code linking can resolve and connect method and variable names Weaving adds the ability to: replace method bodies with new implementations, insert code before and after method calls, instrument variable reads and writes, and modify class structures by adding new methods, fields, parent classes and interfaces SW product sharing SW component products must be possible to be added and removed as wanted This requires that the SW products are designed for this Many SW techniques requires that we package (bundle) and load all code related to a component Software Engineering , Tony Larsson, Halmstad University 23 Software Engineering , Tony Larsson, Halmstad University 24 4

5 SW product sharing, cont. A smart loader will only load code that is not already installed, enforcing code sharing between components To support updates of such SW components the loader and upgrading technique must be able to distinguish between different versions of shared code Packaging To package software as products or components in a proper way we must know what the programming language or platform technique supports We don t want to change the name of a function (method) just because we make an update or error correction It is practical if the technique supports that a loader can distinguish between versions of the same function (for example by use of identities hidden to the programmer) Software Engineering , Tony Larsson, Halmstad University 25 Software Engineering , Tony Larsson, Halmstad University 26 Code sharing between packets Deployment Diagram C1 f(1) f(2) f(3) Application C2 f(1) f(4) f(5) C3 f(4) f(6) f(7) C1 Application C2 C3 f(2) f(3) f(1) f(5) f(4) f(6) f(7) browser.exe Java VM OS app_logic.exe Linux database.exe Oracle DBMS Node 1 Node 2 Node 3 Static view of the run-time configuration of physical (processing) nodes and allocated SW components Software Engineering , Tony Larsson, Halmstad University 27 Software Engineering , Tony Larsson, Halmstad University 28 UML diagram types Structural Capturing the static properties of classes, objects, interfaces and physical components and their relationships and dependencies Behavioral Capturing the dynamic message interaction and state changes within and between modelled items UML 2.0 Two links describing UML 2.0 diagrams: iagrams.htm Rhapsody UML tool, see: Software Engineering , Tony Larsson, Halmstad University 29 Software Engineering , Tony Larsson, Halmstad University 30 5

6 Structural Modelling Package diagrams Class or Structural diagrams Object diagrams Composite Structure Component diagrams Deployment diagrams Behavioural Modelling Use Case diagrams Activity diagrams State Machine diagrams Communication diagrams Sequence diagrams Timing diagrams Overview diagrams Software Engineering , Tony Larsson, Halmstad University 31 Software Engineering , Tony Larsson, Halmstad University 32 Training Exercise Design an automated bank transaction system based on the fact that each user has a bank card, a pin code and an account (possibly shared with other persons). Identify and describe: Requirements and reference model Actors and use cases Data model (class or object or both) Interaction sequences State transition behaviour Work in Parallel Since we have very limited time during the lecture we should distribute the work among you Work in 5 concurrent teams that each present their contributions to solving the problem to the rest of us Each team work in 45 minutes with their task and then we spend 15 minutes to present the different results and to do adjustments and conclusions Software Engineering , Tony Larsson, Halmstad University 33 Software Engineering , Tony Larsson, Halmstad University 34 Concurrent Engineering Requirements & ref. model Actors & use cases Data model Interaction sequences State transition behaviour Integration 45 minutes 15 minutes Software Engineering , Tony Larsson, Halmstad University 35 Presentation of Results Each team should present their results such that we all can discuss what you contribute with Write and illustrate your team results in a clear and readable way so that we can make copies of the results and distribute to the other teams Each team should finally discuss what improvements they like to make based on the results from the other teams The idea is that you should get a feeling for concurrent and time limited team work Software Engineering , Tony Larsson, Halmstad University 36 6