1 / 45

Chapter 2. Software architecture

Chapter 2. Software architecture Architecture style OOSE review Software architecture Layered architecture Architecture style System that share a similar high-level structure are said to have a similar architecture style

Albert_Lan
Download Presentation

Chapter 2. Software architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 2. Software architecture Architecture style OOSE review Software architecture Layered architecture

  2. Architecture style • System that share a similar high-level structure are said to have a similar architecture style • Approaching reuse without understanding architecture style is like starting to construct a building without knowing if it will be a skyscraper or a garage • Software of the same architecture style can be reused easier than those of different architecture styles

  3. Architecture style • An architecture style is defined by the type of constructs that can be reused to engineer a system • Definition: the architecture style of a system is the denotation of the modeling languages used when modeling that system • Example: UML (which is a modeling language) defines an architecture style

  4. OOSE review • Software reuse in the text book is closely related to OOSE of I. Jacobson. Therefore, we review the OOSE in the following slides • Jacobson’s OOSE technique includes the following phases: analysis, construction, and testing

  5. Example

  6. Analysis phase • Purposes of analysis: • To capture requirements • To represent requirements in models • Products of the analysis phase • Requirement model: to describe system functionality • Analysis model: to describe objects that accomplish system functionality

  7. Analysis phase – requirement model • The requirement model describes system functionality • The model is composed of use case diagram, interface description, and domain objects

  8. Analysis phase – requirement model • The use case diagram is composed of: • Actors • Use cases • Relationships among use cases • The interface description describe how the user can use the system. • The domain objects are objects identified in the problem domain

  9. Use case diagram

  10. Use case description

  11. Analysis phase – analysis model • The analysis model is a robust model to adapt to change, which uses interface objects, entity objects, and control objects to describe system functionality • Creating analysis model corresponding to assigning functionality of use cases to objects (see figure in the next slide)

  12. Analysis phase – analysis model • The following functionality should be allocated to interface objects • Those present information to actors or request information from actors • Those change when actors’ behavior change • Those depend on a particular interface type, e.g., changing card types results in changing the input device of the ATM machine

  13. Interface objects

  14. Analysis phase – analysis model • Entity objects model the information that a system will handle over a long time • Possible entity objects: • Those mapped to problem domain objects • The information that should be remembered • Operations of entity objects can be identified from use case functionality

  15. Analysis phase – analysis model • Control objects are used to improve robustness of the analysis model • Behaviors that are sensitive to change can be allocated to control objects, e.g., workflow in a MIS • Behaviors that are not suitable for other objects can also be allocated to control objects

  16. Analysis phase – analysis model • Use cases can be described by analysis objects as shown in the figure of the next slide

  17. Construction phase • Two models are developed in the construction phase, namely the design model and the implementation model • The implementation model is the program code

  18. Construction phase - design model • The design model is developed based on the analysis model; implementation environment is taken into consideration • The considered environment factors includes platform, language, DBMS, constraints, reusable components, libraries, and so on

  19. Construction phase -design model • Design objects in the design model are different from analysis objects • The design model also models design object interactions, design object interface, and design object semantics (i.e., algorithms of design objects’ operations)

  20. Construction phase - design model • In the design process, the analysis model is first transferred into the initial design model (figures in the next slides). Then, implementation environment factors are incorporated. For example, the “extend” relationship should be replaced by “invoke” relationship because no OO programming language supports the former

  21. Take a deep breath and be ready for the other presentations

  22. Software architecture • Software architecture defines system structures, interfaces, and interaction patterns • Example architectures: see the next slides

  23. Call and return architecture

  24. object object object object Object-oriented architecture

  25. Software architecture • Definition: software architecture defines the static organization of software into subsystems interconnected through interfaces and defines at a significant level how nodes (sites) executing those software subsystems interact with each other.

  26. Software architecture • A good architecture facilitates controlling software complexity and allows large organizations to work on parts in parallel • An architecture should be robust. That is, it can be adapted to change (or change should be predicted) • A good architecture acts as a guide to which components should be reused during the development of application systems

  27. Layered architecture • Before discussing layered architecture, we give some definitions below: • Software workproduct: a product or sub-product produced in a software engineering phase. For example, a subsystem of a design document can be regarded as a software workproduct • Asset: high-quality software workproductsthat can be reused

  28. Layered architecture • Some definitions (cont.) • Component: an element of a development model (i.e., software) that is loosely coupled and promised to be reusable. Under this definition, all software workproducts are potentially components or sources of components. • Component system: a set of related components that accomplish some function larger than that accomplished by a single component. In other words, a component system is a larger component composed of components or component systems. Component systems thus facilitate large-scale reuse.

  29. Layered architecture • Some definitions (cont.) • Facade: an aspect of a component system a reuser needs to know when he/she reuses the component system. A facade exports only those a reuser needed and encapsulates other details of a component system. (Take facade in mind, it is the primary concept in the text book).

  30. Layered architecture • The sense behind the layered architecture: • Application systems can be built from component systems • Component systems may in turn be built from components in lower layers • The sense above results in a layered system defined by a layered architecture (see the figure in the next slide)

  31. Middleware System software

  32. Layered architecture • Definition: a layered architecture is a software architecture that organizes software in layers. Each layer is built on top of another more general layer. A layer can loosely be defined as a set of (sub)systems with the same degree of generality. Upper layers are more application specific and lower are more general

  33. Layered architecture • The number in a layered architecture may be varied from situation to situation. For example, the business-specific layer (see the figure in the slide before the previous slide) can be composed of more than one layer

  34. Layered architecture • The topmost layer (application systems layer) contains application systems offering coherent set of use cases to end users. Some application systems may possess more than one version (or variant) • The business-specific layer contains a number of component systems specific to the type of business (i.e., specific to a problem domain). Such component systems include use case and object components. This layer is the focus of my presentation.

  35. Layered architecture • The middleware layer offers components systems providing utility classes and platform-independent services such as distributed object computing in heterogeneous environments. Examples in this layer are GUI builders, DBMS interfaces, CORBA broker, and so on. This layer is the focus of your presentation

  36. Layered architecture • The system software layer contains the software for the computing and networking infrastructure, such as OS, interfaces to specific hardware (i.e., drivers), sockets, and so on. Some components in this layer are hardware (or platform) dependent

More Related