Designer engineering on the Data Science student

Designer engineering

1. Design Engineering Unit 3

2. Design Design is the place where creativity rules—where stakeholder requirements, business needs, and technical considerations all come together in the formulation of a product or system. Design creates a representation or model of the software, but unlike the requirements model (that focuses on describing required data, function, and behavior), the design model provides detail about software architecture, data structures, interfaces, and components that are necessary to implement the system.

3. The Roman architecture critic Vitruvius advanced the notion that well-designed building were those which exhibited firmness, commodity, and delight . The same might be said of good software. Firmness : A program should not have any bugs that inhibit its function. Commodity : A program should be suitable for the purposes for which it was intended. Delight : The experience of using the program should be a pleasurable one. The goal of design is to produce a model or representation that exhibits firmness, commodity, and delight.

4. Design Process and Design Quality Software design is an iterative process through which requirements are translated into a “blueprint” for constructing the software. The software design process involves transforming customer requirements (as described in SRS documents) into an implementable form using a programming language. It encompasses three levels or phases of design: Interface Design Architectural Design Detailed Design

5. Interface Design The interface design describes how the software communicates with systems that interoperate with it, and with humans who use it. An interface implies a flow of information (e.g., data and/or control) and a specific type of behavior. Architectural Design The architectural design representation—the framework of a computer-based system—is derived from the requirements model. Detailed Design The data/class design transforms class models into design class realizations and the requisite data structures required to implement the software.

6. The importance of software design can be stated with a single word—quality. Design is the place where quality is fostered in software engineering. Design provides you with representations of software that can be assessed for quality. Design is the only way that you can accurately translate stakeholder’s requirements into a finished software product or system.

7. Quality Guidelines and Attributes Three characteristics that serve as a guide for the evaluation of a good design: The design must implement all of the explicit requirements contained in the requirements model, and it must accommodate all of the implicit requirements desired by stakeholders. The design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software. The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.

8. Quality Guidelines In order to evaluate the quality of a design representation , the software team must establish technical criteria for good design. Consider the following guidelines: A design should exhibit an architecture that (1) has been created using recognizable architectural styles or patterns, (2) is composed of components that exhibit good design characteristics and (3) can be implemented in an evolutionary fashion, thereby facilitating implementation and testing. A design should be modular; that is, the software should be logically partitioned into elements or subsystems.

9. A design should contain distinct representations of data, architecture, interfaces, and components. A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns. A design should lead to components that exhibit independent functional characteristics. A design should lead to interfaces that reduce the complexity of connections between components and with the external environment. Throughout the design process, the quality of the evolving design is assessed with a series of technical reviews.

10. Assessing Design Quality—The Technical Review During design, quality is assessed by conducting a series of technical reviews (TRs). A technical review is a meeting conducted by members of the software team. Usually two, three, or four people participate depending on the scope of the design information to be reviewed. Each person plays a role: the review leader plans the meeting, sets an agenda, and runs the meeting; the recorder takes notes so that nothing is missed; the producer is the person whose work product (e.g., the design of a software component) is being reviewed.

11. Prior to the meeting, each person on the review team is given a copy of the design work product and is asked to read it, looking for errors, omissions, or ambiguity. When the meeting commences, the intent is to note all problems with the work product so that they can be corrected before implementation begins. The TR lasts between 90 minutes and 2 hours. At the conclusion of the TR, the review team determines whether further actions are required on the part of the producer before the design work product can be approved as part of the final design model.

12. Quality Attributes There are set of software quality attributes that has been given the acronym FURPS—functionality, usability, reliability, performance, and supportability. Functionality is assessed by evaluating the feature set and capabilities of the program, the generality of the functions that are delivered, and the security of the overall system. Usability is assessed by considering human factors, overall aesthetics, consistency, and documentation. Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of output results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the predictability of the program.

13. Performance is measured by considering processing speed, response time, resource consumption, throughput, and efficiency. Supportability combines the ability to extend the program (extensibility), adaptability, serviceability—these three attributes represent a more common term, maintainability—and in addition, testability, compatibility, configurability (the ability to organize and control elements of the software configuration), the ease with which a system can be installed, and the ease with which problems can be localized.

14. Design Concepts A set of fundamental software design concepts has evolved over the history of software engineering. Each helps you answer the following questions: What criteria can be used to partition software into individual components? How is function or data structure detail separated from a conceptual representation of the software? What uniform criteria define the technical quality of a software design? Fundamental software design concepts provide the necessary framework for “getting it right.”

15. Abstraction Architecture Patterns Modularity Information Hiding Functional Independence Refinement Re-factoring Design Classes

16. Abstraction : Abstraction involves hiding irrelevant details to reduce complexity and improve efficiency or quality. It allows software engineers to focus on essential aspects while ignoring unnecessary specifics When you consider a modular solution to any problem, many levels of abstraction can be posed. At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At lower levels of abstraction, a more detailed description of the solution is provided. Different levels of abstraction : procedural abstraction, data abstraction .

17. A procedural abstraction refers to a sequence of instructions that have a specific and limited function. An example of a procedural abstraction would be the word open for a door . Open implies a long sequence of procedural steps (e.g., walk to the door, reach out and grasp knob, turn knob and pull door, step away from moving door, etc.). The name of a procedural abstraction implies these functions, but specific details are suppressed.

18. A data abstraction is a named collection of data that describes a data object . In the context of the procedural abstraction open , we can define a data abstraction called door . Like any data object, the data abstraction for door would encompass a set of attributes that describe the door (e.g., door type, swing direction, opening mechanism, weight, dimensions).

19. Architecture : Software architecture is the structure or organization of program components (modules), the manner in which these components interact, and the structure of data that are used by the components. One goal of software design is to derive an architectural rendering of a system. This rendering serves as a framework from which more detailed design activities are conducted. set of properties that should be specified as part of an architectural design: Structural properties Extra-functional properties Families of related systems

20. Structural properties : This aspect of the architectural design representation defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another. Extra-functional properties : The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability Families of related systems : The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability to reuse architectural building blocks.

21. The architectural design can be represented using one or more of a number of different models. Structural models represent architecture as an organized collection of program components. Framework models increase the level of design abstraction by attempting to identify repeatable architectural design frameworks that are encountered in similar types of applications. Dynamic models address the behavioral aspects of the program architecture, indicating how the structure or system configuration may change. Process models focus on the design of the business or technical process that the system must accommodate. Functional models can be used to represent the functional hierarchy of a system.

22. Patterns : A pattern conveys the essence of a proven solution to a recurring problem. Stated in another way, a design pattern describes a design structure that solves a particular design problem within a specific context and amid “forces” that may have an impact on the manner in which the pattern is applied and used. The intent of each design pattern is to provide a description that enables a designer to determine (1) whether the pattern is applicable to the current work, (2) whether the pattern can be reused (hence, saving design time), and (3) whether the pattern can serve as a guide for developing a similar, but functionally or structurally different pattern.

23. Modularity : Software is divided into separately named and addressable components, sometimes called modules, that are integrated to satisfy problem requirements. It has been stated that “modularity is the single attribute of software that allows a program to be intellectually manageable” . Monolithic software (i.e., a large program composed of a single module) cannot be easily grasped by a software engineer.

24. The number of control paths, span of reference, number of variables, and overall complexity would make understanding close to impossible. In almost all instances, you should break the design into many modules, hoping to make understanding easier and, as a consequence, reduce the cost required to build the software. We modularize a design (and the resulting program) so that development can be more easily planned; changes can be more easily accommodated; testing and debugging can be conducted more efficiently, and long-term maintenance can be conducted without serious side effects.

25. Information Hiding : The concept of modularity leads you to a fundamental question: “How do I decompose a software solution to obtain the best set of modules?” The principle of information hiding suggests that modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information. Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary to achieve software function. The use of information hiding as a design criterion for modular systems provides the greatest benefits when modifications are required during testing and later during software maintenance.

26. Functional Independence : Functional independence is achieved by developing modules with “single minded” function and an “aversion” to excessive interaction with other modules. Stated another way, you should design software so that each module addresses a specific subset of requirements and has a simple interface when viewed from other parts of the program structure. Software with effective modularity, that is, independent modules, is easier to develop because function can be compartmentalized and interfaces are simplified.

27. Independent modules are easier to maintain (and test) because secondary effects caused by design or code modification are limited, error propagation is reduced, and reusable modules are possible. To summarize, functional independence is a key to good design, and design is the key to software quality. Independence is assessed using two qualitative criteria: cohesion and coupling. Cohesion is an indication of the relative functional strength of a module. Coupling is an indication of the relative interdependence among modules.

28. Refinement : Refinement is actually a process of elaboration. You begin with a statement of function (or description of information) that is defined at a high level of abstraction. That is, the statement describes function or information conceptually but provides no information about the internal workings of the function or the internal structure of the information. Abstraction and refinement are complementary concepts. Abstraction enables you to specify procedure and data internally but suppress the need for “outsiders” to have knowledge of low-level details. Refinement helps you to reveal low-level details as design progresses. Both concepts allow you to create a complete design model as the design evolves.

29. Refactoring : Refactoring is a reorganization technique that simplifies the design (or code) of a component without changing its function or behavior. “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.” When software is refactored, the existing design is examined for redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures, or any other design failure that can be corrected to yield a better design.

30. Design Classes : As the design model evolves, you will define a set of design classes that refine the analysis classes by providing design detail that will enable the classes to be implemented, and implement a software infrastructure that supports the business solution. Five different types of design classes User interface classes Business domain classes Process classes Persistent classes System classes

31. User interface classes define all abstractions that are necessary for human computer interaction (HCI). In many cases, HCI occurs within the context of a metaphor (e.g., a checkbook, an order form, a fax machine), and the design classes for the interface may be visual representations of the elements of the metaphor. Business domain classes are often refinements of the analysis classes defined earlier. The classes identify the attributes and services (methods) that are required to implement some element of the business domain.

32. Process classes implement lower-level business abstractions required to fully manage the business domain classes. Persistent classes represent data stores (e.g., a database) that will persist beyond the execution of the software. System classes implement software management and control functions that enable the system to operate and communicate within its computing environment and with the outside world.

33. Four characteristics of a well-formed design class: Complete and sufficient : A design class should be the complete encapsulation of all attributes and methods that can reasonably be expected (based on a knowledgeable interpretation of the class name) to exist for the class. Sufficiency ensures that the design class contains only those methods that are sufficient to achieve the intent of the class, no more and no less. High cohesion : A cohesive design class has a small, focused set of responsibilities and single-mindedly applies attributes and methods to implement those responsibilities.

34. Primitiveness : Methods associated with a design class should be focused on accomplishing one service for the class. Once the service has been implemented with a method, the class should not provide another way to accomplish the same thing. Low coupling : Within the design model, it is necessary for design classes to collaborate with one another and collaboration should be kept to an acceptable minimum. If a design model is highly coupled (all design classes collaborate with all other design classes), the system is difficult to implement, to test, and to maintain over time.

35. Design Model The design model can be viewed in two different dimensions. The process dimension indicates the evolution of the design model as design tasks are executed as part of the software process. The abstraction dimension represents the level of detail as each element of the analysis model is transformed into a design equivalent and then refined iteratively.

36. Data Design Elements Data design (sometimes referred to as data architecting) creates a model of data and/or information that is represented at a high level of abstraction (the customer/user’s view of data). In many software applications, the architecture of the data will have a profound influence on the architecture of the software that must process it. The structure of data has always been an important part of software design. At the program component level , the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications.

37. At the application level , the translation of a data model (derived as part of requirements engineering) into a database is pivotal to achieving the business objectives of a system. At the business level , the collection of information stored in disparate databases and reorganized into a “data warehouse” enables data mining or knowledge discovery that can have an impact on the success of the business itself.

38. Architectural Design Elements The architectural design for software is the equivalent to the floor plan of a house. The floor plan depicts the overall layout of the rooms; their size, shape, and relationship to one another; and the doors and windows that allow movement into and out of the rooms. The floor plan gives us an overall view of the house. Architectural design elements give us an overall view of the software.

39. The architectural model is derived from three sources: information about the application domain for the software to be built; specific requirements model elements such as data flow diagrams or analysis classes, their relationships and collaborations for the problem at hand; and the availability of architectural styles and patterns.

40. Interface Design Elements The interface design for software is analogous to a set of detailed drawings (and specifications) for the doors, windows, and external utilities of a house. These drawings depict the size and shape of doors and windows, the manner in which they operate, the way in which utility connections (e.g., water, electrical, gas, telephone) come into the house and are distributed among the rooms depicted in the floor plan. In essence, the detailed drawings (and specifications) for the doors, windows, and external utilities tell us how things and information flow into and out of the house and within the rooms that are part of the floor plan.

41. The interface design elements for software depict information flows into and out of the system and how it is communicated among the components defined as part of the architecture. There are three important elements of interface design: (1) the user interface (UI); (2) external interfaces to other systems, devices, networks, or other producers or consumers of information; and (3) internal interfaces between various design components. These interface design elements allow the software to communicate externally and enable internal communication and collaboration among the components that populate the software architecture.

42. UI design (increasingly called usability design) incorporates aesthetic elements (e.g., layout, color , graphics, interaction mechanisms), ergonomic elements (e.g., information layout and placement, metaphors, UI navigation), and technical elements (e.g., UI patterns, reusable components). In general, the UI is a unique subsystem within the overall application architecture.

43. The design of external interfaces requires definitive information about the entity to which information is sent or received. In every case, this information should be collected during requirements engineering and verified once the interface design commences. The design of external interfaces should incorporate error checking and (when necessary) appropriate security features.

44. Component-Level Design Elements The component-level design for software is the equivalent to a set of detailed drawings (and specifications) for each room in a house. These drawings depict wiring and plumbing within each room, the location of electrical receptacles and wall switches, sinks, showers, tubs, drains, cabinets, and closets. The component-level design for software fully describes the internal detail of each software component. To accomplish this, the component-level design defines data structures for all local data objects and algorithmic detail for all processing that occurs within a component and an interface that allows access to all component operations (behaviors).

45. Deployment-Level Design Elements Deployment-level design elements indicate how software functionality and subsystems will be allocated within the physical computing environment that will support the software. For example, the elements of the SafeHome product are configured to operate within three primary computing environments—a home-based PC , the SafeHome control panel , and a server housed at CPI Corp. (providing Internet-based access to the system).

46. In the figure, three computing environments are shown (in actuality, there would be more including sensors, cameras, and others). The subsystems (functionality) housed within each computing element are indicated. For example, the personal computer houses subsystems that implement security, surveillance, home management, and communications features. The deployment diagram shows the computing environment but does not explicitly indicate configuration details.

47. For example, the “personal computer” is not further identified. It could be a Mac or a Windows-based PC, a Sun workstation, or a Linux-box. These details are provided when the deployment diagram is revisited in instance form during the latter stages of design or as construction begins.

48. Creating an architectural design: Software architecture Architectural design represents the structure of data and program components that are required to build a computer-based system. It considers the architectural style that the system will take, the structure and properties of the components that constitute the system, and the interrelationships that occur among all architectural components of a system. The “ system architect ” selects an appropriate architectural style from the requirements derived during software requirements analysis.

49. Architectural design begins with data design and then proceeds to the derivation of one or more representations of the architectural structure of the system. Alternative architectural styles or patterns are analyzed to derive the structure that is best suited to customer requirements and quality attributes. Once an alternative has been selected, the architecture is elaborated using an architectural design method.

50. Software Architecture Software Architecture refers to the fundamental structures of a software system and the discipline of creating these structures. It serves as the blueprint for the entire system, defining how its components interact. Software Architecture defines the fundamental organization of a system. It answers questions like: How are components assembled? What are the relationships between components? How do they communicate with each other?

51. Think of it as the high-level design that guides the development process. Architects create and document the software architecture during the design phase of the Software Development Life Cycle (SDLC).

52. Characteristics of Software Architecture Operational Characteristics : Availability : Ensures the system is accessible when needed. Performance : Focuses on system responsiveness and efficiency. Reliability : Aims for consistent behavior and minimal failures. Scalability : Addresses the system’s ability to handle increased load.

53. Structural Characteristics : Configurability : Allows easy adjustments without code changes. Extensibility : Supports adding new features or components. Supportability : Facilitates maintenance and troubleshooting. Portability : Enables deployment across different environments. Maintainability : Ensures ease of maintenance.

54. Cross-Cutting Characteristics: Accessibility: Addresses user accessibility needs. Security: Protects against unauthorized access. Usability: Focuses on user experience. Privacy: Safeguards sensitive data. Feasibility: Considers technical and economic feasibility.

55. SOLID principles of Software architecture : Each character of the word SOLID defines one principle of software architecture. This SOLID principle is followed to avoid product strategy mistakes. A software architecture must adhere to SOLID principle to avoid any architectural or developmental failure.

56. Single Responsibility – Each services should have a single objective. Open-Closed Principle – Software modules should be independent and expandable. Liskov Substitution Principle – Independent services should be able to communicate and substitute each other. Interface Segregation Principle – Software should be divided into such microservices there should not be any redundancies. Dependency Inversion Principle – Higher-levels modules should not be depending on low-lower-level modules and changes in higher level will not affect to lower level.

57. Importance of Software Architecture : Software architecture comes under design phase of software development life cycle. It is one of initial step of whole software development process. Without software architecture proceeding to software development is like building a house without designing architecture of house. So software architecture is one of important part of software application development. In technical and developmental point of view below are reasons software architecture is important. Selects quality attributes to be optimized for a system. Facilitates early prototyping. Allows to be built a system in component wise. Helps in managing the changes in System.

58. Data Design Data design is a crucial step in the software development process. It involves transforming the information domain model (developed during the analysis phase) into efficient data structures needed for implementing the software. Principles of Data Design: Identify Data Structures and Operations Develop a Data Dictionary Stepwise Refinement Modularity Abstract Data Types (ADTs) Levels of Data Design

59. Identify Data Structures and Operations: Identify the data structures required for implementing the software. Define the operations that can be applied to these data structures. Develop a Data Dictionary: Create a data dictionary that depicts how different data objects interact with each other. Specify constraints to be imposed on the elements of data structures. Stepwise Refinement: Use stepwise refinement during the data design process. Make detailed design decisions later in the process.

60. Modularity: Only modules that need to access data stored in a data structure directly should be aware of its representation. Abstract Data Types (ADTs): Use a programming language that supports abstract data types. ADTs allow encapsulation and hide implementation details.

61. Levels of Data Design: Program Component Level: Design data structures and algorithms for manipulating them. Application Level: Convert the data model into a database to achieve specific business objectives. Business Level: Reorganize information stored in different databases into a data warehouse for data mining and business impact .

62. Why Data Design Matters Reducing Complexity : Data design simplifies the program structure, making it modular and efficient. Understanding Data Relationships : Data modeling helps stakeholders understand data relationships within a system. Effective Communication : A well-designed data model facilitates communication among team members. Achieving Business Goals : Proper data design enables achieving specific business objectives, such as data mining from a data warehouse

63. Architectural styles and patterns The software that is built for computer-based systems exhibits many architectural styles. Each style describes a system category that encompasses (1) a set of components (e.g., a database, computational modules) that perform a function required by a system; (2) a set of connectors that enable “communication, coordination and cooperation” among components; (3) constraints that define how components can be integrated to form the system;

64. An architectural style is a transformation that is imposed on the design of an entire system. The intent is to establish a structure for all components of the system. Categories of architectural styles: Data- centered architectures Data-flow architectures Call and return architectures Object-oriented architectures Layered architectures

65. Data-centered architectures : A data store (e.g., a file or database) resides at the center of this architecture and is accessed frequently by other components that update, add, delete, or otherwise modify data within the store. Client software accesses a central repository. In some cases the data repository is passive. That is, client software accesses the data independent of any changes to the data or the actions of other client software. A variation on this approach transforms the repository into a “blackboard” that sends notifications to client software when data of interest to the client changes.

66. Data-centered architectures promote integrability. That is, existing components can be changed and new client components added to the architecture without concern about other clients (because the client components operate independently). In addition, data can be passed among clients using the blackboard mechanism (i.e., the blackboard component serves to coordinate the transfer of information between clients).

67. Data- centered architecture

68. Data-flow architectures : This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data. A pipe-and-filter pattern has a set of components, called filters, connected by pipes that transmit data from one component to the next. Each filter works independently of those components upstream and downstream, is designed to expect data input of a certain form, and produces data output (to the next filter) of a specified form. However, the filter does not require knowledge of the workings of its neighboring filters.

69. Data-flow architecture

70. Call and return architectures . This architectural style enables you to achieve a program structure that is relatively easy to modify and scale. A number of substyles exist within this category: Main program/subprogram architectures: This classic program structure decomposes function into a control hierarchy where a “main” program invokes a number of program components that in turn may invoke still other components. Remote procedure call architectures: The components of a main program/subprogram architecture are distributed across multiple computers on a network.

71. Main program/subprogram architecture

72. Object-oriented architectures : The components of a system encapsulate data and the operations that must be applied to manipulate the data. Communication and coordination between components are accomplished via message passing. Layered architectures : A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set. At the outer layer, components service user interface operations. At the inner layer, components perform operating system interfacing. Intermediate layers provide utility services and application software functions.

73. Layered architecture

74. Once requirements engineering uncovers the characteristics and constraints of the system to be built, the architectural style and/or combination of patterns that best fits those characteristics and constraints can be chosen. In many cases, more than one pattern might be appropriate and alternative architectural styles can be designed and evaluated. For example, a layered style (appropriate for most systems) can be combined with a data-centered architecture in many database applications.

75. Architectural Patterns An architectural pattern, like an architectural style, imposes a transformation on the design of an architecture. A pattern differs from a style in a number of fundamental ways: (1) the scope of a pattern is less broad, focusing on one aspect of the architecture rather than the architecture in its entirety; (2) a pattern imposes a rule on the architecture, describing how the software will handle its functionality at the infrastructure level; (3) architectural patterns tend to address specific behavioral issues within the context of the architecture

76. For example, the requirements model for virtually every e-commerce application is faced with the following problem: How do we offer a broad array of goods to a broad array of customers and allow those customers to purchase our goods online? The requirements model defines a context in which this question must be answered. For example, an e-commerce business that sells golf equipment to consumers will operate in a different context than an e-commerce business that sells high-priced industrial equipment to medium and large corporations.

77. Architectural patterns address an application-specific problem within a specific context and under a set of limitations and constraints. The pattern proposes an architectural solution that can serve as the basis for architectural design.

78. Architectural Design As architectural design begins, the software to be developed must be put into context—that is, the design should define the external entities (other systems, devices, people) that the software interacts with and the nature of the interaction. This information can generally be acquired from the requirements model and all other information gathered during requirements engineering. Once context is modeled and all external software interfaces have been described, you can identify a set of architectural archetypes.

79. An archetype is an abstraction (similar to a class) that represents one element of system behavior. The set of archetypes provides a collection of abstractions that must be modeled architecturally if the system is to be constructed.

80. Representing the System in Context At the architectural design level, a software architect uses an architectural context diagram (ACD) to model the manner in which software interacts with external entities. Architectural context diagram

81. Systems that interoperate with the target system (the system for which an architectural design is to be developed) are represented as Superordinate systems —those systems that use the target system as part of some higher-level processing scheme. Subordinate systems —those systems that are used by the target system and provide data or processing that are necessary to complete target system functionality. Peer-level systems —those systems that interact on a peer-to-peer basis i.e., information is either produced or consumed by the peers and the target system. Actors —entities (people, devices) that interact with the target system by producing or consuming information that is necessary for requisite processing.

82. Defining Archetypes : An archetype is a class or pattern that represents a core abstraction that is critical to the design of an architecture for the target system. In general, a relatively small set of archetypes is required to design relatively complex systems. The target system architecture is composed of these archetypes, which represent stable elements of the architecture. Archetypes can be derived by examining the analysis classes defined as part of the requirements model.

83. For SafeHome home security function, you might define the following archetypes: Node: Represents a cohesive collection of input and output elements of the home security function. For example a node might be comprised of (1) various sensors and (2) a variety of alarm (output) indicators. Detector: An abstraction that encompasses all sensing equipment that feeds information into the target system. Indicator: An abstraction that represents all mechanisms (e.g., alarm siren, flashing lights, bell) for indicating that an alarm condition is occurring. Controller: An abstraction that depicts the mechanism that allows the arming or disarming of a node. If controllers reside on a network, they have the ability to communicate with one another.

84. UML relationships for SafeHome security function archetypes

85. Refining the Architecture into Components : As the software architecture is refined into components, the structure of the system begins to emerge. SafeHome home security function example, you might define the set of top-level components that address the following functionality: External communication management —coordinates communication of the security function with external entities such as other Internet-based systems and external alarm notification. Control panel processing —manages all control panel functionality. Detector management —coordinates access to all detectors attached to the system. Alarm processing —verifies and acts on all alarm conditions.

86. Overall architectural structure for SafeHome with top-level components

87. Describing Instantiations of the System : The architectural design that has been modeled to this point is still relatively high level. The context of the system has been represented, archetypes that indicate the important abstractions have been defined, and the major software components have been identified. However, further refinement (recall that all design is iterative) is still necessary. To accomplish this, an actual instantiation of the architecture is to be developed . It means that the architecture is applied to a specific problem with the intent of demonstrating that the structure and components are appropriate.

88. An instantiation of the security function with component elaboration

89. Conceptual Model of UML The Unified Modeling Language (UML) is a standardized visual language used for describing and modeling software blueprints. key aspects of UML: Language Aspect: The language aspect enables communication about a subject, including system requirements and design. Without a common language, it would be challenging for a team to successfully develop a system. UML provides a vocabulary for expressing concepts related to software systems.

90. Model Aspect: A model is a representation of a subject. It captures a set of ideas (abstractions) about the system. UML models help us understand, visualize, and document software systems. Unified Aspect: The goal of unification is to bring together the best engineering practices from the information systems and technology industry. UML promotes techniques that lead to successful system development.

91. Modeling is a tested and well-known technique that helps build a model. Model is a blueprint of the real system that needs to be built. UML (Unified Modeling Language) is a standard modeling language, and it is different from the other programming languages such as C++, Java. It is a pictorial language used to build models for software systems. UML is used to design models for large, medium as well as small applications. UML was created by the Object Management Group (OMG). Many tools like StarUML , ArgoUML , EclipseUML and so on, are used for UML diagram design/drawing.

92. There are three types of modeling in UML such as Structural modeling , Behavioral modeling and Architectural modeling . The Structural modeling describes the static features of a system. The behavioral modeling defines the interaction within the system. The architectural modeling represents the complete framework of the system; it means that it contains both structural and behavioral elements of the system. Architectural model can be expressed as the blueprint of the entire system.

93. Basic Structural Modeling The structural modeling gives a structural view of a system that highlights the structure of the objects including their classifiers, relationships, attributes and operations. These elements form the vocabulary of the system you are modeling. For example, if you are going to buy a car, things like wheels, frame size, color, lights, and engine are properties of the car. In UML, all of these things are modelled as classes. Cars have external and internal structure, only important properties of car are visible and the rest are hidden. This feature is called abstraction. A class is an abstraction of the things that are a part of your vocabulary.

94. The core elements of the structural modeling are class, interface, component, node and constraints.

95. Classes A class describes a group of objects which have common attributes or properties, operations or behavior, relationships and semantics. A class describes only important attributes to an application and ignores the rest ; it is known as an abstraction, an important feature of object-oriented concepts.

96. A class is graphically designed as a rectangle with three sections that comprises its name, attributes and operations. For example, Car class contains attributes (maker name, wheel size, gears, frame size and color) and operations (repair, move).

97. We can also define the visibility of class members (attributes and operations) by using plus sign (+) for public, negative sign (-) for private, hash sign (#) for protected and tilde (~) for the package.

98. Relationships Relationships define how classes communicate with each other. There are three basic types of relationships in UML- Dependencies, Generalization and Associations for connecting or communicating classes to each other. Graphically, a relationship is shown as a path with different types of lines used to differentiate the categories of relationships between classes.

99. Dependency describes the relationships among classes in which one class is dependent on another class. It means that if you make changes in one class, it will affect the other class. For example, class Vehicle uses the properties and operations of another class (say Bodyshop) but not necessarily the reverse. You can show dependency as a dashed directed line, directed to the class being dependent upon the class.

100. Generalization is a “a-kind-of” relationship. It creates relationships between superclass(base class) and subclass, enabling inheritance of attributes and operations. Example : Vehicle class is super class or base or parent class and Car, Bus are child class or sub class. The generalization is depicted as a solid line with a hollow arrow pointing to the superclass.

101. Association is “a-part-of” relationships between classes. It refers to relationships between classes in which objects of one class are connected to other class objects for communicating data. When you connect just two classes is called a binary association. Each association can have a name, role and multiplicity. You can use a name for an association that describes the relationship's nature. You can also define role names and multiplicity for an association. Multiplicity states how many instances of one class may communicate to a single instance of other class. You can display a multiplicity of exactly one (1), zero or one (0..1), many (0..*), or one or more (1..*).

102. Class Diagram The class diagram depicts a static view of an application. It represents the types of objects residing in the system and the relationships between them. A class consists of its objects, and also it may inherit from other classes. A class diagram is used to visualize, describe, document various different aspects of the system, and also construct executable software code. It shows the attributes, classes, functions, and relationships to give an overview of the software system. It constitutes class names, attributes, and functions in a separate compartment that helps in software development. Since it is a collection of classes, interfaces, associations, collaborations, and constraints, it is termed as a structural diagram.

103. Vital components of a Class Diagram The class diagram is made up of three sections:

104. How to draw a Class Diagram? The class diagram is used most widely to construct software applications. It not only represents a static view of the system but also all the major aspects of an application. A collection of class diagrams as a whole represents a system. Some key points that are needed to keep in mind while drawing a class diagram are given below: To describe a complete aspect of the system, it is suggested to give a meaningful name to the class diagram. The objects and their relationships should be acknowledged in advance. The attributes and methods (responsibilities) of each class must be known. A minimum number of desired properties should be specified as more number of the unwanted property will lead to a complex diagram. Notes can be used as and when required by the developer to describe the aspects of a diagram. The diagrams should be redrawn and reworked as many times to make it correct before producing its final version.

105. A class diagram describing the sales order system is given below

106. Sequence Diagram Sequence Diagrams are interaction diagrams that detail how operations are carried out. They capture the interaction between objects in the context of a collaboration. Sequence Diagrams are time focus and they show the order of the interaction visually by using the vertical axis of the diagram to represent time what messages are sent and when. Sequence Diagrams show elements as they interact over time and they are organized according to object (horizontally) and time (vertically).

107. Object Dimension The horizontal axis shows the elements that are involved in the interaction Conventionally, the objects involved in the operation are listed from left to right according to when they take part in the message sequence. However, the elements on the horizontal axis may appear in any order. Time Dimension The vertical axis represents time proceedings (or progressing) down the page. Note : Time in a sequence diagram is all a about ordering, not duration. The vertical space in an interaction diagram is not relevant for the duration of the interaction.

108. Sequence Diagram Notation Actor a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data) external to the subject. represent roles played by human users, external hardware, or other subjects.

109. Lifeline A lifeline represents an individual participant in the Interaction. Activations A thin rectangle on a lifeline represents the period during which an element is performing an operation. The top and the bottom of the of the rectangle are aligned with the initiation and the completion time respectively

110. Call Message Call message is a kind of message that represents an invocation of operation of target lifeline. Return Message Return message is a kind of message that represents the pass of information back to the caller of a corresponded former message.

111. Self Message Self message is a kind of message that represents the invocation of message of the same lifeline. Recursive Message Recursive message is a kind of message that represents the invocation of message of the same lifeline. It's target points to an activation on top of the activation where the message was invoked from.

112. Create Message Create message is a kind of message that represents the instantiation of (target) lifeline. Destroy Message Destroy message is a kind of message that represents the request of destroying the lifecycle of target lifeline.

113. Duration Message Duration message shows the distance between two time instants for a message invocation. Note A note (comment) gives the ability to attach various remarks to elements. A comment contain information that is useful to a modeler.

114. Sequence Fragments A sequence fragment is represented as a box, called a combined fragment, which encloses a portion of the interactions within a sequence diagram The fragment operator (in the top left corner) indicates the type of fragment.

115. Combined Fragment Example

116. Use Case Diagrams A Use Case Diagram is a Unified Modeling Language (UML) diagram that represents the interaction between actors (users or external systems) and a system under consideration to accomplish specific goals. A Use Case Diagram provides a visual representation of how users interact with a system. It serves as a blueprint for understanding the functional requirements of a system from a user’s perspective.

117. Use Case Diagram Notations

118. Actors are external entities that interact with the system. These can include users, other systems, or hardware devices. Proper identification and understanding of actors are crucial for accurately modeling system behavior. Use cases are like scenes in the play. They represent specific things your system can do. In the online shopping system, examples of use cases could be “Place Order,” “Track Delivery,” or “Update Product Information”. Use cases are represented by ovals.

119. The system boundary is a visual representation of the scope or limits of the system you are modeling. It defines what is inside the system and what is outside. The boundary helps to establish a clear distinction between the elements that are part of the system and those that are external to it. The system boundary is typically represented by a rectangular box that surrounds all the use cases of the system.

120. Use Case Diagram Relationships : Relationships play a crucial role in depicting the interactions between actors and use cases. Association Relationship The Association Relationship represents a communication or interaction between an actor and a use case. It is depicted by a line connecting the actor to the use case. Example: Online Banking System Actor : Customer Use Case : Transfer Funds Association : A line connecting the “Customer” actor to the “Transfer Funds” use case, indicating the customer’s involvement in the funds transfer process.

121. Include Relationship: The Include Relationship indicates that a use case includes the functionality of another use case. It is denoted by a dashed arrow pointing from the including use case to the included use case. Example: Social Media Posting Use Cases : Compose Post, Add Image Include Relationship : The “Compose Post” use case includes the functionality of “Add Image.” Therefore, composing a post includes the action of adding an image.

122. Extend Relationship: The Extend Relationship illustrates that a use case can be extended by another use case under specific conditions. It is represented by a dashed arrow with the keyword “extend.” Example: Flight Booking System Use Cases : Book Flight, Select Seat Extend Relationship : The “Select Seat” use case may extend the “Book Flight” use case when the user wants to choose a specific seat, but it is an optional step.

123. How to draw a Use Case diagram ? Identify Actors Determine who or what interacts with the system. These are your actors. They can be users, other systems, or external entities. Identify Use Cases Identify the main functionalities or actions the system must perform. These are your use cases. Each use case should represent a specific piece of functionality. Connect Actors and Use Cases Draw lines (associations) between actors and the use cases they are involved in. This represents the interactions between actors and the system.

124. Add System Boundary Draw a box around the actors and use cases to represent the system boundary. This defines the scope of your system. Define Relationships If certain use cases are related or if one use case is an extension of another, you can indicate these relationships with appropriate notations. Review and Refine Step back and review your diagram. Ensure that it accurately represents the interactions and relationships in your system. Refine as needed.

125. Example : Online Shopping System Actors: Customer Admin Use Cases: Browse Products Add to Cart Checkout Manage Inventory (Admin) Relations: The Customer can browse products, add to the cart, and complete the checkout. The Admin can manage the inventory.

126. Bank ATM

127. e-Library Online Public Access Catalog

128. Collaboration Diagrams A collaboration diagram is a behavioral diagram which is also referred to as a communication diagram, it illustrates how objects or components interact with each other to achieve specific tasks or scenarios within a system. In simpler terms, they visually represents the interactions between objects or components in a system, showing how they collaborate to accomplish tasks or scenarios and depicts the interconnections among multiple objects within a system, illustrating the system’s object architecture.

129. Components and their Notations in Collaboration Diagrams Objects/Participants Objects are represented by rectangles with the object’s name at the top. Each object participating in the interaction is shown as a separate rectangle in the diagram. Objects are connected by lines to indicate messages being passed between them.

130. Multiple Objects Multiple objects are represented by rectangles, each with the object’s name inside, and interactions between them are shown using arrows to indicate message flows. Actors They are usually depicted at the top or side of the diagram, indicating their involvement in the interactions with the system’s objects or components. They are connected to objects through messages, showing the communication with the system.

131. Messages Messages represent communication between objects. Messages are shown as arrows between objects, indicating the flow of communication. Self Message This is a message that an object sends to itself. It represents an action or behavior that the object performs internally, without involving any other objects.

132. Links Links represent associations or relationships between objects. Links are shown as lines connecting objects, with optional labels to indicate the nature of the relationship. Return Messages Return messages represent the return value of a message. They are shown as dashed arrows with a label indicating the return value. Return messages are used to indicate that a message has been processed and a response is being sent back to the calling object.

133. How to draw Collaboration Diagrams ? Identify Objects/Participants: Begin by identifying the objects or participants involved in the system. These can be classes, modules, actors, or any other relevant entities. Define Interactions: Determine how these objects interact with each other to accomplish tasks or scenarios within the system. Identify the messages exchanged between objects during these interactions. Add Messages: Draw arrows between lifelines to represent the messages exchanged between objects. Label each arrow with the name of the message

134. Consider Relationships: If there are associations or dependencies between objects, represent them using appropriate notations, such as dashed lines or arrows. Documentation: Once finalized, document the collaboration diagram along with any relevant explanations or annotations. Ensure that the diagram effectively communicates the system’s interactions to stakeholders.

135. Example: Job Recruitment System The recruiter object interacts with the database object to verify the login, check the jobs, select a talented applicant, and send interview details. The applicant object interacts with the database object to provide details and attend the test.

136. Applicant This object represents the job candidate who applies for a job position. The Applicant object interacts with the Recruiter object to provide personal and professional details and attend the interview. After the interview, the Recruiter object selects the talented applicant and sends a joining letter to the Applicant object.

137. Recruiter This object represents the person or system responsible for hiring new employees. The Recruiter object interacts with the Applicant object to verify the login, check the job positions, select the talented applicant, send interview details, and send the joining letter. The Recruiter object also interacts with the Database object to retrieve and update the necessary information.

138. Database This object represents the system or component that stores the necessary information for the recruitment process. The Database object interacts with the Recruiter object to provide the job positions, verify the login, and send the necessary details about the applicants. The Database object also interacts with the Applicant object to store and retrieve the necessary details about the applicants.

139. Train Reservation

140. online bookshop

141. Component Diagrams Component Diagrams are used to show code modules of a system in Unified Modeling Language (UML). They are generally used for modeling subsystems. It represents how each and every component (module) acts during execution and running of a system program. They are also used to show and represent structure and organization of all components. These code modules include application program, Java Beans, backend databases, or some ASP programs. The component diagrams are for representing interfaces and dependencies among software architecture.

142. The component diagram is used to explain working and behavior of various components of a system and is static diagrams of UML. The main purpose of component diagram is simply to show relationship among various components of a system.

143. component and interface

144. Example : On-line Course Registration This diagram shows conceptual view of server-side components.

145. A component diagram for an online shopping system